Select selectedIndex updated before select focus/change fires

NEW
Unassigned

Status

()

P5
major
13 years ago
4 months ago

People

(Reporter: mikecaines, Unassigned)

Tracking

({compat, helpwanted})

Trunk
x86
Windows XP
compat, helpwanted
Points:
---
Bug Flags:
blocking1.8b4 -
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
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)
(Reporter)

Comment 1

13 years ago
Created attachment 195137 [details]
Testcase
(Reporter)

Updated

13 years ago
Flags: blocking1.8b4?
(Reporter)

Comment 2

13 years ago
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

13 years ago
can you confirm that this just broke recently and wasn't in deer park alpha 2 or
1.0?
(Reporter)

Comment 4

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

Comment 5

13 years ago
not a blocker. looks like we 
Flags: blocking1.8b4? → blocking1.8b4-

Comment 6

13 years ago
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
(Reporter)

Comment 7

13 years ago
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).
Keywords: helpwanted
Flags: blocking1.9a1?
Keywords: compat

Comment 8

13 years ago
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

13 years ago
(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.
Flags: blocking1.9a1? → blocking1.9-

Comment 10

12 years ago
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

12 years ago
Created attachment 241652 [details]
Simple example how this behavior breaks polling
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.
I filed bug 393494 which covers comment 10/11
Assignee: events → nobody
QA Contact: ian → events
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.