307339 - Select selectedIndex updated before select focus/change fires

Status: NEW

(Core :: DOM: Events, defect, P3)

Description

[Mike Caines]

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)

Comment 1

[Mike Caines]

Attachment: Testcase

Comment 2

[Mike Caines]

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

Comment 3

[Scott MacGregor]

can you confirm that this just broke recently and wasn't in deer park alpha 2 or
1.0?

Comment 4

[Mike Caines]

This behaviour is reproducible in both Firefox 1.04 and Deer Park alpha 2 on Mac
OSX.

Comment 5

[Asa Dotzler [:asa]]

not a blocker. looks like we 

Comment 6

[Asa Dotzler [:asa]]

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.

Comment 7

[Mike Caines]

Attachment: 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).

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 9

[[e-mail]]

(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.

Comment 10

[Julik Tarkhanov]

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 11

[Julik Tarkhanov]

Attachment: Simple example how this behavior breaks polling

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Mats Palmgren (inactive)]

I filed bug 393494 which covers comment 10/11

Comment 14

[Firefox Bug Husbandry Bot]

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.

Comment 15

[Andrei Purice]

Still reproducible on the latest versions of Firefox Nightly 95.0a1 (2021-10-21), beta 94.0b8 and release 93.0 on Windows 10.

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 17

[Henri Sivonen (:hsivonen)]

We still differ from Chrome here. (Also setting the parity-safari keyword based on earlier comments.)