Closed
Bug 303896
Opened 16 years ago
Closed 8 years ago
input focus not painted after enabling/disabling input field using setTimeout callback
Categories
(Core :: DOM: Selection, defect)
Core
DOM: Selection
Tracking
()
RESOLVED
FIXED
mozilla25
People
(Reporter: han44solo, Assigned: mats)
References
Details
(Keywords: testcase)
Attachments
(3 files, 1 obsolete file)
841 bytes,
text/html
|
Details | |
3.39 KB,
patch
|
ehsan
:
review+
|
Details | Diff | Splinter Review |
5.12 KB,
patch
|
ehsan
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 I've encountered a strange problem with the selected focus of an input field not being painted after using a Javascript callback (setTimeout). My original code was a bit more complicated (doing some AJAX stuff), but I've simplified it down to the example code below. Basically what I'm doing is once the correct number of characters are typed in a field (4 in the example), the field is disabled to prevent any further typing. Then I do some asynchronous processing that may take a few seconds - in my complicated case, this was doing some AJAX calls, but in the example below, it's easy to simulate with a javascript setTimeout. In the example, after 2 seconds the callback() function is called. The callback function will change something on the page (indicating it's finished), then re-enable the input field, and call select() to focus on the field and highlight all the text. The problem is: that higlighted focus is not painted. The field is actually focused with the text higlighted, because if you start typing it will register as expected. But it's disconcerting not to have the visual feedback of the field text being selected and painted appropriately. When the callback completes, if you obscure the window (either by switching to a new tab or a different application), then switch back - the highlighted text appears painted appropriately. And I almost hate to say it... but IE does not appear to exhibit this painting problem. The text appears highlighted immediately when the callback returns, without having to do the "obscure the window" trick. The example will work fine if you comment out the enable/disable calls on the field. So it must have something to do with painting the highlight after a field is renabled. Perhaps something to do with the default "disabled look" in Firefox which gives the field a gray backroung (vs. just graying the text in IE)? Example page code: <html> <head> <script type="text/javascript"> function doCall() { if (document.getElementById("field").value.length == 4) { startCall(); setTimeout("callback()", 2000); } else { document.getElementById("text").innerHTML = ""; } } function callback() { document.getElementById("text").innerHTML = "finished call"; endCall(); } function startCall() { document.getElementById("field").disabled = true; } function endCall() { document.getElementById("field").disabled = false; document.getElementById("field").select(); } </script> </head> <body> <input id="field" type="text" onkeyup="doCall();" maxlength="4"/> <div id="text"></div> </body> </html> Reproducible: Always Steps to Reproduce: (see details) Actual Results: (see details) Expected Results: Field should be painted with highlighted text focus as soon as javascript callback completes.
Updated•16 years ago
|
Assignee: nobody → selection
Component: General → Selection
Keywords: testcase
Product: Firefox → Core
QA Contact: general
Version: unspecified → Trunk
Reproducible with Mozilla 1.8b1, Deer Park a2 and SeaMonkey/20050807, the highlight becomes only visible after switching back from another window.
I found a workaround that produces the desired effect... if the startCall() function is modified to: function startCall() { document.getElementById("field").disabled = true; document.getElementById("field").blur(); } The addition of the blur() call will result in the field being highlighted as expected when the call returns and select() is called.
![]() |
||
Comment 4•15 years ago
|
||
ccing some folks familiar with focus stuff...
Updated•12 years ago
|
Assignee: selection → nobody
QA Contact: selection
Comment 5•8 years ago
|
||
Those bugs seem to duplicate each other: #396403, #648791, #752987 So it's an old known bug, please fix
![]() |
||
Comment 7•8 years ago
|
||
Bug 648791 seems different from this one. Olli, Mounir, does select() depend on style information but not flush it?
Flags: needinfo?(bugs)
Comment 8•8 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #7) > Bug 648791 seems different from this one. Personally, I can't reproduce bug 648791. Keyboard shortcuts work, but cursor and selection rectangle are invisible. Other than that, affected input field works just fine.
Comment 9•8 years ago
|
||
If I read the code correctly, the layout stuff just doesn't invalidate the frame properly. Mats is more familiar with selection handling.
Flags: needinfo?(bugs) → needinfo?(matspal)
Assignee | ||
Comment 10•8 years ago
|
||
Assignee: nobody → matspal
Flags: needinfo?(matspal)
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Comment 11•8 years ago
|
||
Attachment #779563 -
Attachment is obsolete: true
Attachment #780015 -
Flags: review?(ehsan)
Assignee | ||
Comment 12•8 years ago
|
||
Try run: https://tbpl.mozilla.org/?tree=Try&rev=af042e73ee4f
Attachment #780016 -
Flags: review?(ehsan)
Updated•8 years ago
|
Attachment #780015 -
Flags: review?(ehsan) → review+
Comment 13•8 years ago
|
||
Comment on attachment 780016 [details] [diff] [review] Refactor AttributeChanged() to follow code style and make it easier to read (no functional change). Review of attachment 780016 [details] [diff] [review]: ----------------------------------------------------------------- ::: layout/forms/nsTextControlFrame.cpp @@ +1172,5 @@ > + return NS_OK; > + } > + > + // Allow the base class to handle common attributes supported by all form > + // elements... Trailing whitespace! :)
Attachment #780016 -
Flags: review?(ehsan) → review+
Assignee | ||
Comment 14•8 years ago
|
||
> Trailing whitespace! :) Thanks, fixed. https://hg.mozilla.org/integration/mozilla-inbound/rev/1ceb563e5fcd https://hg.mozilla.org/integration/mozilla-inbound/rev/b0590e3d0c4d
Flags: in-testsuite+
Comment 15•8 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1ceb563e5fcd https://hg.mozilla.org/mozilla-central/rev/b0590e3d0c4d
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in
before you can comment on or make changes to this bug.
Description
•