Closed
Bug 112025
Opened 23 years ago
Closed 18 years ago
Calling blur() within an onfocus event of a text field incorrectly fires the onchange event.
Categories
(Core :: DOM: Events, defect, P3)
Core
DOM: Events
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: gbarrett, Assigned: joki)
References
Details
(Keywords: embed, topembed-)
Attachments
(1 file)
(deleted),
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
BuildID: 20011120
If a text field's blur() method is called from the field's onfocus event, then
the onchange event is incorrectly fired. This only occurs the first time the
field is focused. Subsequent focusing works fine. Also, IE 6.0 and NN 4.77
work fine.
Reproducible: Always
Steps to Reproduce:
1. Click on the good field.
2. Click on the bad field. Change event is incorrectly fired.
3. Click on the good field again.
4. Click on the bad field again. Change event is not fired.
Actual Results: The change event is incorrectly fired the first time you click
on the bad field. The order of clicking is irrelevent to this result.
Expected Results: The change event should not be fired unless the field value
is actually changed.
The only difference between the "Good" field and the "Bad" field is that the
"Bad" field calls blur() in it's onfocus event.
Comment 1•23 years ago
|
||
Confirmed on mozilla0.9.6 win2k. Nice testcase :-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•23 years ago
|
||
I'd guess the problem is that we don't set the internal initial value (which we
use for comparison to determine when to fire change events) until the first
focus event finishes firing. This may be fixed by the event grouping rewrite
going on for 0.9.9. Marking into that milestone for later testing.
Target Milestone: --- → mozilla0.9.9
Assignee | ||
Comment 4•23 years ago
|
||
124990 and its associated bugs is not quite ready for checkin for 0.9.9.
Maintaining high priority and moving to 1.0 for completion and further testing.
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 5•23 years ago
|
||
topembed- per EDT triage.
Joki, please let us know current status.
Updated•22 years ago
|
Priority: -- → P3
Updated•22 years ago
|
Target Milestone: mozilla1.0 → ---
Comment 6•21 years ago
|
||
Greg, is this still an issue?
Updated•19 years ago
|
I couldn't reproduce this, using the test case I uploaded, which presumes the "good" field is the one that has a change handler and a focus handler that calls blur(), and the "bad" field is the one with no handlers.
Running on Mozilla:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.12) Gecko/20050915
works as expected. The change handler is never fired.
Running on Firefox:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
throws this exception:
[Exception... "'Permission denied to set property XULElement.selectedIndex' when calling method:
[nsIAutoCompletePopup::selectedIndex]"
nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"
location: "JS frame ::
file:///C:/var/clients/Bug112025-testcase.html :: anonymous :: line 12" data: no]
on the line of code where blur() is called.
This is a different bug than originally described, and hopefully reported elsewhere.
wfm. mats.palmgren@bredband.net, it's your duplicate?!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070107 Minefield/3.0a2pre
Comment 10•18 years ago
|
||
WFM, Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a2pre)
Gecko/20070107 SeaMonkey/1.5a
It also works in Firefox 1.5.0.9 and 2.0.0.1 on Linux so it was fixed
earlier than bug 265047.
-> WORKSFORME
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•