Open
Bug 387406
Opened 17 years ago
Updated 2 years ago
Form -> Select -> Jump-Menus, selectedIndex can be set to a disabled option
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
NEW
People
(Reporter: robert.caretta, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(1 file, 1 obsolete file)
475 bytes,
text/html
|
Details |
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•17 years ago
|
||
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.
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Comment 2•17 years ago
|
||
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•17 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Summary: Form -> Select -> Jump-Menus → Form -> Select -> Jump-Menus, selectedIndex can be set to a disabled option
Comment 4•17 years ago
|
||
Comment 5•17 years ago
|
||
Comment on attachment 277993 [details]
Testcase #2
Sorry, attached this to the wrong bug.
Attachment #277993 -
Attachment is obsolete: true
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•13 years ago
|
||
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•6 years ago
|
||
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
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•