From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 A <select> element inside a <span class="foo"> tag, where class "foo" has a CSS background-color defined, displays incorrectly. Looks like the background-color obscures part of the widget's controls. This is visible on many of sun.com's pages using Moz 0.9.3 on Win98. Reproducible: Always Steps to Reproduce: 1. Go to http://supportforum.sun.com/index.html 2. Look at the drop-down munu in the top bar Actual Results: The widget's controls are partially obscured by the blue that is defined in the surrounding SPAN tag's style. Expected Results: The widget should look normal, but still display the blue background dictated by the style carried by that particular SPAN tag. To be sure, I built a test page and re-created the scenerio in a few different ways, using DIV instead of SPAN, using a <td bgcolor="#RRGGBB"> instead of SPAN, and so on, but I only got this behavior using the method originally described. For controlling background color, people ought to say <select class="foo">...</select> instead of <span class="foo"><select>...</select></span>. Nevertheless, this bug should be fixed.

confirmed win98 build:2001082508 I would increase the severity of this one - it obscures the form control making it non-obvious that its a select box, rendering certain pages unusable to the novice user.

The problem is the select is inheriting some style it shouldn't. Need generic way to keep form controls from inheriting style from the rest of the content. I messed with putting important on some of the rules and it didn't work.

*** Bug 99274 has been marked as a duplicate of this bug. ***

*** Bug 93084 has been marked as a duplicate of this bug. ***

*** Bug 99736 has been marked as a duplicate of this bug. ***

On bug 93084, I noted "This appeared on the trunk sometime after the 2001-07-11-07-trunk build, and before the 2001-07-14-11-trunk build on win32 (at least). [It is not on the 0.9.2+,etc. branch)." By the way, rods, did you really mean to mark this as both P1 _and_ Future?

If you change the size-attribute of the select-element to 2 or higher, this bug is not showing up. Just wondering, if there is something wrong in the http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsGfxTextControlFrame2.cpp 2028 // Set the neccessary style attributes on the text control. 2029 2030 if (IsSingleLineTextControl()) 2031 rv = divContent->SetAttr(kNameSpaceID_None,nsHTMLAtoms::style, NS_ConvertASCIItoUCS2(DIV_STRING_SINGLELINE), PR_FALSE); 2032 else { 2033 nsAutoString divStr; divStr.AssignWithConversion(DIV_STRING); 2034 const nsStyleDisplay* disp = (const nsStyleDisplay*) 2035 mStyleContext->GetStyleData(eStyleStruct_Display); 2036 if (disp->mOverflow == NS_STYLE_OVERFLOW_SCROLL) 2037 divStr += NS_LITERAL_STRING("overflow:scroll;"); 2038 else if (disp->mOverflow == NS_STYLE_OVERFLOW_HIDDEN) 2039 divStr += NS_LITERAL_STRING("overflow:hidden;"); 2040 else divStr += NS_LITERAL_STRING("overflow:auto;"); 2041 rv = divContent->SetAttr(kNameSpaceID_None,nsHTMLAtoms::style, divStr, PR_FALSE); 2042 }

Ooops, maybe the problem is more likely in http://lxr.mozilla.org/seamonkey/source/layout/html/forms/src/nsComboboxControlFrame.cpp BTW. Try zooming a lot "smaller ctrl+-", the widget's controls are starting to show again. BTW2. If form-element is inside span-element everything is OK. (In testcases the form-element is outside the span-element or there is no form-element at all,)

*** Bug 109368 has been marked as a duplicate of this bug. ***

*** Bug 111244 has been marked as a duplicate of this bug. ***

*** Bug 112443 has been marked as a duplicate of this bug. ***

Confirmed. The behavior described in comment #14 also manifests itself on 0.9.6 on Windows 98.

*** Bug 118134 has been marked as a duplicate of this bug. ***

The way to fix this is to fix the combobox so it paints itself entirely in the foreground paint layer.

Ok, I just spent an hour building 0.9.7, verifying that it had the bug, applying this patch, and verifying it fixed it. It's small, obvious. PLEASE include for 0.9.8! (!!!) PLEASE!!!!

jkeiser or rods, could you please review this 6-line patch? Not sure who should sr=. Thanks in advance.

Comment on attachment 63504 [details] [diff] [review] patch r=jkeiser

*** Bug 125363 has been marked as a duplicate of this bug. ***

attinasi, can you sr this smallish patch? Surprised Sun wasn't all over this once since it makes their page look pretty poor.

I'm seeing this with XBLFC too, with select and button!!! I suppose the patch is only for select?

*** Bug 129070 has been marked as a duplicate of this bug. ***

XBL Form Controls are a different beastie entirely.

Comment on attachment 63504 [details] [diff] [review] patch sr=attinasi - BUT, we need a nice comment explaining why we are painting everything in the FOREGROUND layer - it looks wrong to be painting BACKGROUND, for instance, in the FOREGROUND layer.

I know the XBLFC are totally different but for some reason they behave same (wrong) way: some elements can't be in <SPAN></SPAN> Has anyone tried the patch with the attachment in the comment #14? (I suppose it does not work.)

Without the fix for bug 87981 both the buttons and selects are OK (only the old FC not XBLFC).

I was wrong. Without the fix for bug 87981 both the buttons and selects are NOT OK.

bug 115438 dupl of this?

Yes, that's a dupe.

Whoah! What happened to this? nsbeta1, we have a patch.

Added the comments attinasi asked for

Comment on attachment 77412 [details] [diff] [review] Patch v1.0.1 Carrying r=jkeiser, sr=attinasi

*** Bug 135097 has been marked as a duplicate of this bug. ***

nsbeta1+ [adt2]

Comment on attachment 77412 [details] [diff] [review] Patch v1.0.1 a=asa (on behalf of drivers) for checkin to the 1.0 trunk

*** Bug 115438 has been marked as a duplicate of this bug. ***

Marking adt1.0.0+ per ADT triage.

Fix checked in.

Oh, I had a similar (but covering a bunch more controls) patch in bug 107244.

<select> -elements are now ok, but the buttons are displayed badly when placed inside span. Try attachment in comment 14.

Try today's nightly. dbaron checked in the fix he mentioned in comment 41. If it doesn't work for you, comment there; but it works for me.

Verified fixed Win XP branch (2002042306) win 2k trunk (2002042303) Mac OS X trunk (2002042203) Mac OS X branch(2002042205) and linux branch (2002042208) and linux trunk (2002042210), marking verified1.0.0