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)
Core
DOM: UI Events & Focus Handling
Tracking
()
RESOLVED
FIXED
People
(Reporter: jdiazper, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: testcase)
Attachments
(2 files, 1 obsolete file)
|
(deleted),
text/html
|
Details | |
|
(deleted),
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.
Maybe it is related to <input onfocus="">, see testcase and bug 102005 comment
9.
|
||
Comment 2•20 years ago
|
||
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•20 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.
|
||
Comment 4•20 years ago
|
||
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•18 years ago
|
||
|
|
Assignee | |
Updated•18 years ago
|
Assignee: events → mats.palmgren
|
|
Assignee | |
Comment 6•18 years ago
|
||
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)
|
|
||
Comment 7•18 years ago
|
||
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 8•18 years ago
|
||
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•18 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
Closed: 18 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Updated•18 years ago
|
Attachment #162677 -
Attachment is obsolete: true
|
|
Assignee | |
Updated•18 years ago
|
Flags: in-testsuite?
|
||
Comment 10•18 years ago
|
||
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
|
|
||
Comment 11•17 years ago
|
||
The tests for this should check that user-triggered changes _do_ fire onchange.
|
||
Comment 12•10 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>
|
||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•