Last Comment Bug 382600 - [FIX]When an empty select box is disabled an XX is added to it (1.8 branch only)
: [FIX]When an empty select box is disabled an XX is added to it (1.8 branch only)
: fixed1.8.0.13, regression, verified1.8.1.5
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: 1.8 Branch
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (TPAC)
: 382875 383003 383177 383205 383452 (view as bug list)
Depends on:
Blocks: 323656
  Show dependency treegraph
Reported: 2007-05-31 07:10 PDT by Marryat Stevens
Modified: 2007-07-10 12:34 PDT (History)
26 users (show)
dveditz: blocking1.8.1.5+
dveditz: blocking1.8.0.13+
bzbarsky: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Testcase from initial comment (536 bytes, text/html)
2007-05-31 07:12 PDT, Dave Townsend [:mossop]
no flags Details
Fix (1.07 KB, patch)
2007-06-03 13:55 PDT, Boris Zbarsky [:bz] (TPAC)
dbaron: review+
dbaron: superreview+
dveditz: approval1.8.1.5+
dveditz: approval1.8.0.13+
Details | Diff | Splinter Review
Regression test (for trunk) (1.96 KB, patch)
2007-06-03 13:56 PDT, Boris Zbarsky [:bz] (TPAC)
no flags Details | Diff | Splinter Review

Description Marryat Stevens 2007-05-31 07:10:07 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20070515 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20070515 Firefox/

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 (

Reproducible: Always

Steps to Reproduce:
Actual Results:  

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">

<title>Floating div test</title>

<style type="text/css">


<script language='javascript'>


<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">



Expected Results:  
These XX should not have been present.
Comment 1 Dave Townsend [:mossop] 2007-05-31 07:12:12 PDT
Created attachment 266751 [details]
Testcase from initial comment
Comment 2 Dave Townsend [:mossop] 2007-05-31 07:17:10 PDT
I'm seeing this on a current Bon Echo nightly but not a trunk build
Comment 3 Olli Pettay [:smaug] (TPAC) 2007-05-31 07:32:10 PDT
It would be great to get regression range. Odd bug.
Comment 4 John P Baker 2007-05-31 08:04:44 PDT
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 Mats Palmgren (:mats) 2007-05-31 17:03:14 PDT
I think this was caused by bug 323656 (confirmed by a local backout of
bug 323656 and bug 377824).
Comment 6 Nick 2007-05-31 19:32:09 PDT
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.

      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
    <select id="s" multiple="multiple"></select>

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.
Comment 7 Boris Zbarsky [:bz] (TPAC) 2007-05-31 20:26:23 PDT
I'll try to get to this ASAP.
Comment 8 Boris Zbarsky [:bz] (TPAC) 2007-05-31 23:32:46 PDT
We really need to start running regression tests on branch, imo...  And add this to the tests, of course.
Comment 9 Damon Miller 2007-06-01 12:49:01 PDT
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.
Comment 10 Adam Guthrie 2007-06-01 13:40:30 PDT
*** Bug 382875 has been marked as a duplicate of this bug. ***
Comment 11 :Gavin Sharp [email:] 2007-06-02 16:10:43 PDT
*** Bug 383003 has been marked as a duplicate of this bug. ***
Comment 12 Boris Zbarsky [:bz] (TPAC) 2007-06-03 13:55:05 PDT
Created attachment 267073 [details] [diff] [review]
Comment 13 Boris Zbarsky [:bz] (TPAC) 2007-06-03 13:56:53 PDT
Created attachment 267074 [details] [diff] [review]
Regression test (for trunk)
Comment 14 Kevin Brosnan 2007-06-04 11:56:43 PDT
*** Bug 383177 has been marked as a duplicate of this bug. ***
Comment 15 :Gavin Sharp [email:] 2007-06-04 15:19:35 PDT
*** Bug 383205 has been marked as a duplicate of this bug. ***
Comment 16 Mark Brocato 2007-06-04 15:32:13 PDT
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 Leandro Martins 2007-06-06 05:27:50 PDT
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 }
Comment 18 Dave Townsend [:mossop] 2007-06-06 05:38:58 PDT
*** Bug 383452 has been marked as a duplicate of this bug. ***
Comment 19 Boris Zbarsky [:bz] (TPAC) 2007-06-06 09:09:45 PDT
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 Sander Kruger 2007-06-08 01:45:10 PDT
This bug also accurs in
Comment 21 katsu taka 2007-06-08 06:09:19 PDT
I also.
Is firefox-auto-update the cause?

Maybe, I have no problem until very recently.
I have looked "XX" for few weeks.

Comment 22 Boris Zbarsky [:bz] (TPAC) 2007-06-08 08:23:48 PDT
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.
Comment 23 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2007-06-15 15:40:06 PDT
Comment on attachment 267073 [details] [diff] [review]


(Does this fix some of the longstanding style context parenting warnings?)
Comment 24 Boris Zbarsky [:bz] (TPAC) 2007-06-15 21:48:36 PDT
It doesn't, but the bug it's a regression from did.
Comment 25 Boris Zbarsky [:bz] (TPAC) 2007-06-15 21:49:12 PDT
Comment on attachment 267073 [details] [diff] [review]

Note that this is a branch-only regression, so no checkin on trunk....

I think this is very very safe.
Comment 26 Daniel Veditz [:dveditz] 2007-06-22 11:05:03 PDT
Comment on attachment 267073 [details] [diff] [review]

approved for and, a=dveditz for release-drivers
Comment 27 Boris Zbarsky [:bz] (TPAC) 2007-07-03 11:28:33 PDT
Fixed on both branches.  Checked in regression test.
Comment 28 Al Billings [:abillings] 2007-07-10 12:34:07 PDT
Verified in branch with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2007071004 BonEcho/

Verified in trunk with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a7pre) Gecko/200707100404 Minefield/3.0a7pre

Note You need to log in before you can comment on or make changes to this bug.