Closed Bug 265047 Opened 20 years ago Closed 18 years ago

onChange event triggered before onFocus at first time focused (without any change, of course)

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jdiazper, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: testcase)

Attachments

(2 files, 1 obsolete file)

Testcase #2
1.81 KB, text/html
Details
Patch rev. 1
7.57 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

The code is so simple that we've chosen to write it down here:
<HTML><HEAD></HEAD>
<BODY>
<FORM NAME="fooForm">
<input type="text" name="fooField" value="2" onFocus="alert('Focused');" 
onChange="alert('Changed');">
<SCRIPT>
 //just to ensure the field has a value so it cannot change.
 alert (document.fooForm.fooField.value) ;
</SCRIPT>
</FORM></BODY></HTML>

First time you focus the input, it triggers a onChange event before onFocus.
You can Blur the input then. Next time the onChange event isn't triggered.

Reproducible: Always
Steps to Reproduce:
1. Load the page.
2. Focus the input.


Actual Results:  
a onChange event is triggered before the onFocus event, despite the unchanged 
value.

Expected Results:  
It should have triggered the onFocus event first.

We've tried the same code in Internet Explorer 6.x and it worked fine.
We've tried the same code in Netscape 7.x and it failed exactly as in Firefox.
Attached file Testcase (obsolete) — 
Maybe it is related to <input onfocus="">, see testcase and bug 102005 comment
9.
I can see the bug, using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041018
Firefox/0.9.1+
Keywords: testcase
(In reply to comment #1)
> Created an attachment (id=162677)
> Testcase
> Maybe it is related to <input onfocus="">, see testcase and bug 102005 comment
> 9.

I suppose it's related to it, but I couldn't find the original code, so 
couldn't test it.

We've been reading that bug but seeing it was old and unsolved, and not sure of 
being the same problem, we decided to report our own fail anyway.

Please, see that the bug is at least as simple as the code we wrote: two main 
events on an input are not compatible.

By this moment we also discovered onFocus vs onBlur worked exactly (wrong) as 
onFocus vs onChange. The fact is we've choosen IExplore for our users but we 
would like keeping mozilla-compliant our applications.

We've got a handicap with this two events mixed in an input.

I wonder whether this has to do with the fact that the focus handler causes the
node to lose focus (which, if it happens before the text control has had a
chance to init the focused value, would trigger onchange).

Happens on Linux too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Attached file Testcase #2 — 

    
  
Assignee: events → mats.palmgren

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch rev. 1
        — 
          — Splinter Review
      

    


  
I don't think focus is related to whether a SetValue call should be
considered a user change or not. It should never be consider a
user change, except for the "special" calls from nsFileControl.
Bug 313337 introduced this code. It does not regress it AFAICT.

        Attachment #247612 -
        Flags: superreview?(bzbarsky)

        Attachment #247612 -
        Flags: review?(jst)

    
    

    
  
I don't know whether I'll get to this before January.  I also think jst doing r+sr on this is just fine if he's ok with it.

    
    

    
  
Comment on attachment 247612 [details] [diff] [review]
Patch rev. 1

r+sr=jst, but I really would like to see this new "mode" named something else. The naming should ideally explain what it means os that you'd have some idea w/o having to look up the comment by the member variable declaration. How about something like "FireChangeEventState"?

       // Tell mTextFrame that it doesn't have focus while we're setting the
       // value.  Otherwise it'll think that the value is being set by a script
       // while it has focus and not fire onchange when it should.
-      PRBool hasFocus = mTextFrame->GetHasFocus();
-      mTextFrame->SetHasFocus(PR_FALSE);
+      PRBool oldMode = mTextFrame->GetUserValueMode();
+      mTextFrame->SetUserValueMode(PR_TRUE);

The above comment should be updated too.

        Attachment #247612 -
        Flags: superreview?(bzbarsky)

        Attachment #247612 -
        Flags: superreview+

        Attachment #247612 -
        Flags: review?(jst)

        Attachment #247612 -
        Flags: review+

    
    

    
  
Renamed UserValueMode to FireChangeEventState and updated the comment.

Checked in to trunk at 2007-01-05 08:31 PST

-> FIXED
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED

    
  

        Attachment #162677 -
        Attachment is obsolete: true

    
  
Flags: in-testsuite?

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070105 Minefield/3.0a2pre ID:2007010512 [cairo]

verified/fixed on win32

    
    

    
  
The tests for this should check that user-triggered changes _do_ fire onchange.

    
  
Depends on: 743618

    
    

    
  
This bug still exist in Firefox 31.6.0. Onchange event fires automatically for the first time even if there is no changes occur. It does not occur if there is no initial value.

<HTML><HEAD></HEAD>
<BODY>
<FORM NAME="testForm">
<input type="text" name="testField" value="100"
onFocus="alert('focused');" 
onChange="alert('Changed');">
</FORM></BODY></HTML>
Component: Event Handling → User events and focus handling

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: