User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050906 Firefox/1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050906 Firefox/1.4 The selectedIndex property of an HTML select element is updated before the focus event fires on the select. Since there is no way for the *user* to modify a select's selection without focus, this should be impossible. Please see the attached test case and compare with Internet Explorer on Windows. Reproducible: Always Steps to Reproduce: 1. Please see the attached test case Actual Results: (after following test case example) input: focus input: blur input: change select: selectedIndex = 1 (option with index 1 gets new text) select: focus select: change Expected Results: input: focus input: blur input: change select: selectedIndex = 0 (option with index 0 gets new text) select: focus select: change (now the selectedIndex = 1)
Safari 1.4 (v312) on OSX 10.3.9 also says the select's selectedIndex is 0 when the input's change event fires. This bug may be related to bug 306437 and bug 260850
can you confirm that this just broke recently and wasn't in deer park alpha 2 or 1.0?
This behaviour is reproducible in both Firefox 1.04 and Deer Park alpha 2 on Mac OSX.
not a blocker. looks like we
Flags: blocking1.8b4? → blocking1.8b4-
I can reproduce this bug in 1.0.6 so this is nothing new. Tested on windows 2000 with the official 1.0.6 release.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 197027 [details] Bug Example I'd really like to see this fixed before 1.5 final since it is of critical importance in the attached example (see: Bug Example). Note this is not a testcase per se, but rather an example of how this bug breaks our web application in Mozilla (but not IE or Safari).
Has this always worked this way? I mean what does Netscape 3/4 do? There is a bit similar strange behaviour with checkbox/radiobutton http://lxr.mozilla.org/seamonkey/source/content/html/content/src/nsHTMLInputElement.cpp#1265
(In reply to comment #8) >Has this always worked this way? By my reading of the code, I can't see how it would ever not have worked this way; the series of events is as follows: 1) the list box frame sees the mouse down event, and starts drag-tracking the selection 2) the esm sees the mouse down event and focuses the select 3) the input frame sees the blur event and fires a change event As a workaround, the reporter could use <select onmousedown="this.focus();"> however I guess that someone needs to make a decision as to the point of event processing at which form controls take focus.
Confirmed here on all Gecko builds on OS X, including latest. This actually leads to a nasty situation. When using polling to determine if the value of the form element has changed, the select box reports it's new value when the user is actually hovering above the select and hasn't made a selection. This manifests here for example http://dev.rubyonrails.org/ticket/6326 In this case using polling is more efficient because the values have to be pulled from the entire form, and onChange on form elements is substandard. Both IE and WebKit change the selectedIndex _after_ the item has been selected by the user, and it's more user- (and developer-)friendly than what Gecko adopts. Simple testcase included. This severly breaks AJAXified multiselects as a matter of fact.
Comment 10 and comment 11 are probably a separate bug from this one (and should be filed as such). Please cc me on that bug when you file it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.