Closed Bug 303896 Opened 19 years ago Closed 11 years ago

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

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla25

People

(Reporter: han44solo, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: testcase)

Attachments

(3 files, 1 obsolete file)

example code
841 bytes, text/html
Details
fix+test
3.39 KB, patch
ehsan.akhgari
: 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.akhgari
: 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.
Attached file example code — 

  

  


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.

  

  



    
    

    
  
ccing some folks familiar with focus stuff...

  

  


Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
Assignee: selection → nobody
QA Contact: selection

    
    

    
  
Those bugs seem to duplicate each other:
#396403, #648791, #752987

So it's an old known bug, please fix

  

  



    
    

    
  
Bug 648791 seems different from this one.

Olli, Mounir, does select() depend on style information but not flush it?

  

  


Flags: needinfo?(bugs)

    
    

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

  

  



    
    

    
  
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)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        wip (obsolete)
        — 
          — Splinter Review
      

    


  

  

  


Assignee: nobody → matspal
Flags: needinfo?(matspal)

    
  
Severity: normal → minor
Keywords: helpwanted
OS: Windows XP → All
Hardware: x86 → All

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix+test
        — 
          — Splinter Review
      

    


  

  

  



        Attachment #779563 -
        Attachment is obsolete: true

        Attachment #780015 -
        Flags: review?(ehsan)

    
  

        Attachment #780015 -
        Flags: review?(ehsan) → review+

    
    

    
  
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+

    
    

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

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/1ceb563e5fcd
https://hg.mozilla.org/mozilla-central/rev/b0590e3d0c4d

  

  


Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: