Open
Bug 193534
Opened 22 years ago
Updated 2 years ago
disabled <SELECT> can still be scrolled
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
REOPENED
People
(Reporter: maly, Unassigned)
References
Details
(Keywords: parity-ie, testcase)
Attachments
(1 file)
646 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 I think this is a bug, some may think this is evangalism, but I noticed Mozilla handles <select disabled> in what I would consider a strange way, and definitely different from IE. When the listbox is disabled, you cannot make any selections, BUT you can scroll through it. I think this is a bad idea because: a) it is supposed to be disabled -> DISABLED should mean disabled in all ways. b) Completely disabling any widget allows a developer to completely take control over it and utilize it to his/her own needs. For example at one point I wanted to have two listboxes side by side always being in synch with each other. So I disabled both of them, and wrote javascript code to scroll up and down through both listboxes in sync. Works great in IE and Mozilla, BUT because Mozilla allows scrolling through a listbox even when it's disabled, sync can be potentially lost. Reproducible: Always Steps to Reproduce: All this is Mozilla's handling of disabled in <select>. All you need to do is create a listbox with enough entries so that it scrolls. Actual Results: see details Expected Results: should handle it like IE does
Comment 1•22 years ago
|
||
Peter, do you know of a site that uses this or have a testcase already?
Comment 2•22 years ago
|
||
Comment 3•22 years ago
|
||
confirmed with Moz 1.3b on WinXP. over to Form Controls
Assignee: asa → form
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout: Form Controls
Ever confirmed: true
QA Contact: asa → desale
Summary: Mozilla handling <select disabled> → disabled <SELECT> can still be scrolled
Comment 4•21 years ago
|
||
-> All/All (1.4b OS X) Looking at the testcase however I'm not sure I agree with the initial presumption that disabled should mean that one can't see all the options and not just that you can't select any options.
OS: Windows 98 → All
Hardware: PC → All
Comment 5•20 years ago
|
||
I would vote for WONTFIX. The behavior of Mozilla is better.
Updated•20 years ago
|
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Comment 6•19 years ago
|
||
Anne, this is sort of the module owners call. ccing some ui people too, for their feedback.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 7•19 years ago
|
||
Since single select dropdowns don't let you view the options (the dropdown is disabled), its rather inconsistent to act differently for multiple selects, IMO.
Comment 8•19 years ago
|
||
As second question is whether there is a way to disable a XUL scrollbar (which is what we have here).
Comment 9•19 years ago
|
||
Currently I don't know of way to stop a XUL scrollbar from attempting to scroll except by setting its maxpos to 0 (which also locks the curpos to 0). Note that you would also have to disable mousewheel scrolling. Also note that this bug also affects textareas.
Updated•15 years ago
|
Assignee: layout.form-controls → nobody
QA Contact: ian → layout.form-controls
Comment 12•6 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-ie
Whiteboard: [parity-IE]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•