Closed
Bug 382600
Opened 17 years ago
Closed 17 years ago
[FIX]When an empty select box is disabled an XX is added to it (1.8 branch only)
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: marryats, Assigned: bzbarsky)
References
Details
(Keywords: fixed1.8.0.13, regression, verified1.8.1.5)
Attachments
(3 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dbaron
:
review+
dbaron
:
superreview+
dveditz
:
approval1.8.1.5+
dveditz
:
approval1.8.0.13+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 When an empty select box is disabled through javascript, an XX is added to it, which is not present in the generated source or the source of the document. This remains when the select box is not disabled but cannot be selected. It dissapears if the page is reloaded. This only happens after the last update (2.0.0.4) Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <title>Floating div test</title> <style type="text/css"> </style> <script language='javascript'> <!-- --> </script> </head> <body onload=''> <select name="filter_by" id="filter_by" multiple="yes" size="12" style="width:250px;"></select> <input type="button" onclick='document.getElementById("filter_by").disabled = !document.getElementById("filter_by").disabled;' VALUE="disable"> </body> </html> Expected Results: These XX should not have been present.
Reporter | ||
Updated•17 years ago
|
Version: unspecified → 2.0 Branch
Comment 1•17 years ago
|
||
Comment 2•17 years ago
|
||
I'm seeing this on a current Bon Echo nightly but not a trunk build
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Component: General → DOM: HTML
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Version: 2.0 Branch → 1.8 Branch
Comment 3•17 years ago
|
||
It would be great to get regression range. Odd bug.
Comment 4•17 years ago
|
||
Is this the: select::-moz-dummy-option { visibility: hidden; content: "XX"; /* demo 8, edge case test 1 */ } removed from forms.css on the trunk by bug 314879 although that wouldn't explain why it is now visible
Comment 5•17 years ago
|
||
I think this was caused by bug 323656 (confirmed by a local backout of bug 323656 and bug 377824).
Blocks: 323656
Component: DOM: HTML → Layout: Form Controls
Keywords: regression
OS: Windows XP → All
QA Contact: general → layout.form-controls
Hardware: PC → All
Actually, this effect seems to be triggered by modifying *any* CSS property of the select box. Any of the three examples below will cause this. <html> <body> <script> window.onload = function() { //document.getElementById("s").style.visibility = "visible"; // Ex. 1 //document.getElementById("s").style.color = "#ff0000"; // Ex. 2 //document.getElementById("s").style.width = "100px"; // Ex. 3 } </script> <select id="s" multiple="multiple"></select> </body> </html> Depending on the property, the "XX" may not be visible until the mouse moves over the document body or until the focus moves to the select box.
Assignee | ||
Comment 7•17 years ago
|
||
I'll try to get to this ASAP.
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Assignee | ||
Comment 8•17 years ago
|
||
We really need to start running regression tests on branch, imo... And add this to the tests, of course.
Comment 9•17 years ago
|
||
I am able to recreate this bug also by modifying CSS properties (just width and height, from what I've seen so far) on a parent element of the select.
Assignee | ||
Comment 12•17 years ago
|
||
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #267073 -
Flags: superreview?(dbaron)
Attachment #267073 -
Flags: review?(dbaron)
Assignee | ||
Comment 13•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Summary: When an empty select box is disabled an XX is added to it (2.0.0.4 only) → [FIX]When an empty select box is disabled an XX is added to it (2.0.0.4 only)
Comment 16•17 years ago
|
||
Does anyone know why wrapping the offending javascript in a window.setTimeout(function() {/* script goes here */}); seems to fix this and a million other UI rendering issues? I'm not sure if anyone else does this but its fixed dozens of mystery problems over the years but its kinda scary to say the least.
Comment 17•17 years ago
|
||
This is decided modifying in line 190, in the source "form.css", "content: 'XX'" for "content: ''". This source if finds in the directory of installation of its mozilla firefox "Mozilla Firefox\res\forms.css" View error: "YOUR_PATH\Mozilla Firefox\res\forms.css" 188 select::-moz-dummy-option { 189 visibility: hidden; 190 content: "XX"; /* demo 8, edge case test 1 */ 191 }
Assignee | ||
Comment 19•17 years ago
|
||
Changing that CSS will break the layout of empty selects, though. Really, we just need to get the fix reviewed and checked in. ;)
Comment 20•17 years ago
|
||
This bug also accurs in 1.5.0.12
Comment 21•17 years ago
|
||
I also. Is firefox-auto-update the cause? Maybe, I have no problem until very recently. I have looked "XX" for few weeks.
Assignee | ||
Comment 22•17 years ago
|
||
Guys, please stop spamming the bug. We know why the bug happens (see comment 5). We know where it's happening. We have a fix. We just need branch approval and checking of the fix in; the next set of security releases on the branches will have the fix.
Summary: [FIX]When an empty select box is disabled an XX is added to it (2.0.0.4 only) → [FIX]When an empty select box is disabled an XX is added to it (1.8 branch only)
Comment 23•17 years ago
|
||
Comment on attachment 267073 [details] [diff] [review] Fix r+sr=dbaron. (Does this fix some of the longstanding style context parenting warnings?)
Attachment #267073 -
Flags: superreview?(dbaron)
Attachment #267073 -
Flags: superreview+
Attachment #267073 -
Flags: review?(dbaron)
Attachment #267073 -
Flags: review+
Assignee | ||
Comment 24•17 years ago
|
||
It doesn't, but the bug it's a regression from did.
Assignee | ||
Comment 25•17 years ago
|
||
Comment on attachment 267073 [details] [diff] [review] Fix Note that this is a branch-only regression, so no checkin on trunk.... I think this is very very safe.
Attachment #267073 -
Flags: approval1.8.1.5?
Attachment #267073 -
Flags: approval1.8.0.13?
Updated•17 years ago
|
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Comment 26•17 years ago
|
||
Comment on attachment 267073 [details] [diff] [review] Fix approved for 1.8.1.5 and 1.8.0.13, a=dveditz for release-drivers
Attachment #267073 -
Flags: approval1.8.1.5?
Attachment #267073 -
Flags: approval1.8.1.5+
Attachment #267073 -
Flags: approval1.8.0.13?
Attachment #267073 -
Flags: approval1.8.0.13+
Assignee | ||
Comment 27•17 years ago
|
||
Fixed on both branches. Checked in regression test.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Keywords: fixed1.8.0.13,
fixed1.8.1.5
Resolution: --- → FIXED
Comment 28•17 years ago
|
||
Verified in branch with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5pre) Gecko/2007071004 BonEcho/2.0.0.5pre Verified in trunk with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/200707100404 Minefield/3.0a7pre
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.5 → verified1.8.1.5
You need to log in
before you can comment on or make changes to this bug.
Description
•