Bug 55471 - Form field focus is "lost" when said field has been modified
Summary: Form field focus is "lost" when said field has been modified
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All OS X 10.6
: P2 Normal
Assignee: Nobody
URL: http://jsfiddle.net/keeto/tqSyy/4/
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-01 08:10 PST by André Dion
Modified: 2022-12-27 07:28 PST (History)
4 users (show)

See Also:


Attachments
Test case derived from http://jsfiddle.net/keeto/tqSyy/4/ (491 bytes, text/html)
2011-03-23 14:42 PDT, Daniel Bates
no flags Details
Work-in-progress layout test (927 bytes, text/html)
2011-03-23 15:18 PDT, Daniel Bates
no flags Details
DRT Layout Test (3.21 KB, patch)
2011-03-24 23:42 PDT, Daniel Bates
no flags Details | Formatted Diff | Diff
Self-contained Layout Test (10.80 KB, text/html)
2011-03-24 23:47 PDT, Daniel Bates
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description André Dion 2011-03-01 08:10:23 PST
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
Comment 1 Daniel Bates 2011-03-23 14:42:47 PDT
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/>.
Comment 2 Daniel Bates 2011-03-23 15:18:12 PDT
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.
Comment 3 Daniel Bates 2011-03-24 23:42:20 PDT
Created attachment 86895 [details]
DRT Layout Test

DRT layout test that can also be run by hand.
Comment 4 Daniel Bates 2011-03-24 23:47:09 PDT
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).
Comment 5 Ahmad Saleem 2022-12-27 07:28:18 PST
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!