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)

Product:
Core
Component:
Layout: Form Controls
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: marryats, Assigned: bzbarsky)

References

Details

(Keywords: fixed1.8.0.13, regression, verified1.8.1.5)

Attachments

(3 files)

Testcase from initial comment
536 bytes, text/html
Details
Fix
1.07 KB, patch
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
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.
Version: unspecified → 2.0 Branch
I'm seeing this on a current Bon Echo nightly but not a trunk build
Status: UNCONFIRMED → NEW
Component: General → DOM: HTML
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Version: 2.0 Branch → 1.8 Branch
It would be great to get regression range. Odd bug.
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
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.
I'll try to get to this ASAP.
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
We really need to start running regression tests on branch, imo...  And add this to the tests, of course.
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.
Attached patch Fix — — Splinter Review 
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED

        Attachment #267073 -
        Flags: superreview?(dbaron)

        Attachment #267073 -
        Flags: review?(dbaron)

    
  
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)

    
    

    
  
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.

    
    

    
  
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 }

    
    

    
  
Changing that CSS will break the layout of empty selects, though.  Really, we just need to get the fix reviewed and checked in.  ;)

    
    

    
  
This bug also accurs in 1.5.0.12

    
    

    
  
I also.
Is firefox-auto-update the cause?

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




    
    

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

    
    

    
  
It doesn't, but the bug it's a regression from did.

    
    

    
  
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?
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+

    
    

    
  
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+

    
    

    
  
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

    
    

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: