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

RESOLVED FIXED

Status

()

RESOLVED FIXED
14 years ago
4 years ago

People

(Reporter: jdiazper, Assigned: mats)

Tracking

({testcase})

Trunk
testcase
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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.

Comment 1

14 years ago
Created attachment 162677 [details]
Testcase

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
(Reporter)

Comment 3

14 years ago
(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
(Assignee)

Comment 5

12 years ago
Created attachment 247611 [details]
Testcase #2
(Assignee)

Updated

12 years ago
Assignee: events → mats.palmgren
(Assignee)

Comment 6

12 years ago
Created attachment 247612 [details] [diff] [review]
Patch rev. 1

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+
(Assignee)

Comment 9

12 years ago
Renamed UserValueMode to FireChangeEventState and updated the comment.

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

-> FIXED
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Attachment #162677 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
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.

Updated

7 years ago
Depends on: 743618

Comment 12

4 years ago
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>
You need to log in before you can comment on or make changes to this bug.