387406 - Form -> Select -> Jump-Menus, selectedIndex can be set to a disabled option

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Rob]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.30)
Build Identifier: Firefox 2.0.0.4

An item in the drop-down menu is hovered over, then moused-out over the general body area of the page. Click anywhere. When I click to activate another drop-down menu the first drop-down menu is reading the previous hovered over area as an actively selected item, registering a change, then performing a jump. This does not happen in IE 7 or Opera.

Reproducible: Always

Steps to Reproduce:
1. Activate a category at www.gjumper.com
2. Open up a options drop-down menu, hover over any item.
3. Then mouse-out of the drop-down and click anywhere in the body area of the page.
4. Click on the categories drop-down menu, you will notice the options drop-down performs a jump. This is incorrect as technically nothing was ever selected.


Expected Results:  
The categories menu should never initiate the jump. That is incorrect.

Comment 1

[Adam Guthrie]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007070904 Minefield/3.0a7pre

The form is using some JavaScript which uses the "selected" attribute of the form elements. I'm guessing there is a difference between our and IE's behavior for this that's causing the bug.

Comment 2

[Martijn Wargers (dead)]

Attachment: testcase

This is basically what's going on on that page.
When you click on the select, the selectedIndex is set to 0.
However, the first option is disabled. This is not supported in IE, so there is no problem for IE.
However, Mozilla does support the disabled attribute.
But when the selectedIndex is set to 0, the first option is suddenly selected. I guess that should not be happening, since a disabled option should not be selectable in general.

Comment 3

[Martijn Wargers (dead)]

Confirming, I couldn't find a related bug and I think that Mozilla does it wrong here, although I'm not sure what the correct behavior is.
Opera9.20 selects the disabled option. I guess that might be a solution, but it seems like a wrong solution to me, since a disabled option shouldn't be selectable.
So I guess it would be best to do nothing when a disabled option is selected with .selectedIndex.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 5

[Mats Palmgren (inactive)]

Comment on attachment 277993 [details]
Testcase #2

Sorry, attached this to the wrong bug.

Comment 9

[Sam Beard]

From previous comments it seems to me that there is some confusion about what the disabled attribute does.

Per http://www.w3.org/TR/html4/interact/forms.html#adef-disabled the disabled attribute disables a control for user input.  It also causes a control not to receive focus, be skipped in tabbing and to be unsuccessful.

Therefor changes to selectedIndex from javascript should be able to select a disabled option of a select.  Also, an option should be creatable either via the DOM or HTML that is selected and disabled.  These are not user input.

If no option is selected when the select list is created it is up to the browser what to make selected as this is an undefined situation.  It seems that most select the first option but I would not argue with skipping disabled options unless all are disabled.

One thing that is not clear from the above reference in regards to select options is if a disabled option is selected should that make the control unsuccessful?

My main concern from my original bug report (451200) is that the selected option is being changed without the user or javascript selecting a new option and that change is not rendered until a new control is selected.

Comment 10

[Martijn Wargers (dead)]

Sam, thanks for you comment, I think you are correct.

(In reply to Sam Beard from comment #9)
> One thing that is not clear from the above reference in regards to select
> options is if a disabled option is selected should that make the control
> unsuccessful?
I guess that is covered here:
http://dev.w3.org/html5/spec/association-of-controls-and-forms.html#enabling-and-disabling-form-controls
"Constraint validation: If an element is disabled, it is barred from constraint validation."

Comment 11

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