Created attachment 58194 [details] test case It's hard to write a testcase for this, but here's what I came up with. Basically, it's possible to have a focused, but visibility:hidden element. In Gecko, that element still receives key events and allows text input. In WebKit, it receives key events, but only does one text insertion. My opinion is that text insertion (include line-breaks) should work. If the element is receiving key events, it should also allow text insertion. I can also think of valid use-cases enabled by allowing text insertion in this case. Related: bug 30116 and bug 40338.
I am able to reproduce this bug in Safari Technology Preview 160 and via monitoring console, I noticed that Safari still accept keypresses but does not update them and the text will remain same after accepting first keypress like 'The quick brown fox jumps over the lazy dog' will be maximum 'Dogg' even though you keep on pressing 'g'. In case of Chrome Canary 110 and Firefox Nightly 110, they don't accept any keyboard events and I think we should also follow it and disable the keypress to be accepted. Just wanted to share updated testing result. Thanks!