Bug 55471 – Form field focus is "lost" when said field has been modified

• Component: Forms
• Status: RESOLVED CONFIGURATION CHANGED

[André Dion]

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

[Daniel Bates]

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/>.

[Daniel Bates]

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.

[Daniel Bates]

Created attachment 86895 [details]
DRT Layout Test

DRT layout test that can also be run by hand.

[Daniel Bates]

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).

[Ahmad Saleem]

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!