Using the test case here: http://jsfiddle.net/keeto/tqSyy/4/ When the field gets focus, an element is inserted into the DOM before it which causes the field to be pushed down, which in turn causes the field to "lose" focus. No blur event is fired, no typed text shows up in the field, and the field still appears to be in focus (the outline is drawn). Calling .focus() on the text field again has no result. The only way to re-establish focus is for the end-user to manually select the field again. This bug may be related to https://bugs.webkit.org/show_bug.cgi?id=14366
Created attachment 86689 [details] Test case derived from http://jsfiddle.net/keeto/tqSyy/4/ For historical preservation, I've created a stand-alone version of the test case <http://jsfiddle.net/keeto/tqSyy/4/>.
Created attachment 86706 [details] Work-in-progress layout test Work in progress DRT/manual layout test. I suspect that this bug is a duplicate of bug #14366. I will take a look later today unless someone confirms it before me.
Created attachment 86895 [details] DRT Layout Test DRT layout test that can also be run by hand.
Created attachment 86897 [details] Self-contained Layout Test For convenience, a self-contained version of the DRT layout test included in the patch "DRT Layout Test" (https://bugs.webkit.org/attachment.cgi?id=86895).
Using "self-container" test, I am not able to reproduce this bug and I can type "p" in Safari 16.2 and it shows "PASS document.getElementById("field").value is "p"", marking this as "RESOLVED CONFIGURATION CHANGED" and tagging few others to confirm. Thanks!