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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jdiazper, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: testcase)

Attachments

(2 files, 1 obsolete file)

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. 1Splinter 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: