input focus not painted after enabling/disabling input field using setTimeout callback

RESOLVED FIXED in mozilla25

Status

()

Product:
Core
Component:
Selection
Importance:
--
minor
Status:
RESOLVED FIXED
Reported:
14 years ago
Modified:
5 years ago

People

(Reporter: han44solo, Assigned: mats)

Tracking

({testcase})

Version:
Trunk
Target:
mozilla25
Keywords:
testcase
Points:
---
Duplicates:
752987
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

example code
841 bytes, text/html
Details
fix+test
3.39 KB, patch
Ehsan
: review+
Details | Diff | Splinter Review
Refactor AttributeChanged() to follow code style and make it easier to read (no functional change).
5.12 KB, patch
Ehsan
: review+
Details | Diff | Splinter Review
(Reporter)

Description

•
14 years ago 
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.
(Reporter)

Comment 1

•
14 years ago 
Created attachment 191965 [details]
example code
Assignee: nobody → selection
Component: General → Selection
Keywords: testcase
Product: Firefox → Core
QA Contact: general
Version: unspecified → Trunk

Comment 2

•
14 years ago 
Reproducible with Mozilla 1.8b1, Deer Park a2 and SeaMonkey/20050807, the
highlight becomes only visible after switching back from another window.
 (Reporter)

Comment 3

•
13 years ago 
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

•
13 years ago 
ccing some folks familiar with focus stuff...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Assignee: selection → nobody
QA Contact: selection

Comment 5

•
6 years ago 
Those bugs seem to duplicate each other:
#396403, #648791, #752987

So it's an old known bug, please fix
Duplicate of this bug: 752987

Comment 7

•
6 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

•
6 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

•
5 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

•
5 years ago 
Created attachment 779563 [details] [diff] [review]
wip
Assignee: nobody → matspal
Flags: needinfo?(matspal)
 (Assignee)

Updated

•
5 years ago
Severity: normal → minor
Keywords: helpwanted
OS: Windows XP → All
Hardware: x86 → All
 (Assignee)

Comment 11

•
5 years ago 
Created attachment 780015 [details] [diff] [review]
fix+test
Attachment #779563 - Attachment is obsolete: true
Attachment #780015 - Flags: review?(ehsan)
 (Assignee)

Comment 12

•
5 years ago 
Created attachment 780016 [details] [diff] [review]
Refactor AttributeChanged() to follow code style and make it easier to read (no functional change).

Try run:
https://tbpl.mozilla.org/?tree=Try&rev=af042e73ee4f
Attachment #780016 - Flags: review?(ehsan)

Updated

•
5 years ago
Attachment #780015 - Flags: review?(ehsan) → review+

Comment 13

•
5 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+

Comment 15

•
5 years ago 
https://hg.mozilla.org/mozilla-central/rev/1ceb563e5fcd
https://hg.mozilla.org/mozilla-central/rev/b0590e3d0c4d
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.