181490 - [Patch] background-color:transparent; doesn't apply to form elements (input, select, textarea) under windows XP

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX: Win32, defect)

Description

[Konstantin Vainer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016

CSS attribute "background-color: transparent;" is not handled correctly
[inconsistent with other platforms/OSes];

Reproducible: Always

Steps to Reproduce:
1. create input/select/textarea element in the document
2. give the created element property style="background-color: transparent;"
3. test it in browser...

Actual Results:  
element background turns white [probably other color - depending on system
setting of default window background color]

Expected Results:  
element background should become transparent [meaning that the appearing
background-color/background-mage should be derived from parent element]

The testcase was run on several windows OSes and appeared to have problems (work
wrong) only on Windows XP. Linux mozilla does not have this bug as well.

Comment 1

[Konstantin Vainer]

Attachment: testcase

Comment 2

[Tim Hill]

Theming should probably get turned off if there's a transparent background.

Comment 3

[Boris Zbarsky [:bzbarsky]]

to hyatt.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[alanjstr]

I changed my Windows color scheme so that textboxes had a blue background. 
Oddly, this seemed to make the Transparent work for everything except the SELECT.  

This is despite my userContent.css containing the following:
input,
textarea,
select {
  color: black;
  background-color: white;
}
button,
input[type="button"],
input[type="reset"],
input[type="submit"] {
  color: black !important;
  background-color: rgb(212,208,200) !imprtant;
}

(I've already filed a bug about form elements and userContent).

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

Comment 6

[alanjstr]

Forgot to add myself to the CC.  Sorry about the spam.

Comment 7

[Brian 'netdragon' Bober]

Bug 184359 has been fixed, but this bug is not fixed yet on Windows XP, 
2003013108.

Reason:
The select box in the testcase is still white. According to bug report, it is 
supposed to be red. Is that correct? Notice on IE, the same thing happened... 
I don't have any faith in IE having the correct behavior, though.

I gave you a filter string for email=bazookacarryingmonkeys

Comment 8

[Konstantin Vainer]

The selectbox really has to get red background , too...
and it does not work in 2003013108 ...

Comment 9

[alanjstr]

The only thing I see white is the dropdown box
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030911
Firebird/0.6.1+

Comment 10

[Erik Funkenbusch]

The select is still not showing transparently on this.

As a side note, there also seems to be a problem with listboxes (select with a
size > 1) as well on xp.  background-color doesn't seem to work at all on them
and only shows the default color, though the foreground color works correctly.

I don't know if this should be added as a new bug, or simply expanding the scope
of this bug to include listbox background color.

Comment 11

[Erik Funkenbusch]

Attachment: Testcase for listboxes

As you can see from this testcase, setting the background-color of a listbox
(select with size > 1) only shows the default color.  Setting the
background-color on the option does work for the option, but that leaves the
rest of the listbox unstyled.  Oddly enough, background-color works find on the
dropdown list (size = 1) although transparent does not work in either.

Comment 12

[Erik Funkenbusch]

Adding myself to the cc, sorry about the extra message

Comment 13

[Isaac Hwak Han]

Attachment: patch for <select> listbox

For LISTBOX, do the same thing done with TEXTFIELD in bug 184359.

Comment 14

[Anne (:annevk)]

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

Comment 15

[Anne (:annevk)]

Comment on attachment 137058 [details]
Testcase for listboxes

This has to do with bug 224974

Comment 16

[Brian Ryner (not reading)]

Comment on attachment 138657 [details] [diff] [review]
patch for <select> listbox

>Index: nsNativeThemeWin.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/gfx/src/windows/nsNativeThemeWin.cpp,v
>retrieving revision 3.31
>diff -p -w -u -r3.31 nsNativeThemeWin.cpp
>--- nsNativeThemeWin.cpp	21 Dec 2003 05:36:22 -0000	3.31
>+++ nsNativeThemeWin.cpp	8 Jan 2004 22:18:51 -0000
>@@ -1094,7 +1095,8 @@ PRBool nsNativeThemeWin::IsWidgetStyled(
>           }
>           break;                      
>         }
>-        case NS_THEME_TEXTFIELD: {
>+        case NS_THEME_TEXTFIELD:
>+        case NS_THEME_LISTBOX: {
>           defaultBorderStyle = NS_STYLE_BORDER_STYLE_INSET;
>           defaultBorderSize = NSIntPixelsToTwips(TEXTFIELD_BORDER_SIZE, p2t);
>           lookAndFeel->GetColor(nsILookAndFeel::eColor_threedface, defaultBorderColor);


I assume you've checked that TEXTFIELD_BORDER_SIZE is indeed the right border
for a listbox? (maybe it's worth a separate #define, for clarity)

r=bryner

Comment 17

[Malcolm Rowe]

Attachment: Updated version of Isaac's patch

This is Isaac's patch updated to take account of bryner's comments. It fixes
bug 224974, but it still doesn't fix background:transparent.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Why is it OK not to make the corresponding changes to nsNativeTheme.cpp?

Comment 19

[Isaac Hwak Han]

Thanks for Malcolm's updated patch. I was off-line due to national holiday.

(In reply to comment #15)
> This has to do with bug 224974

The bug was unconfirmed when I attached the patch, and has a dependency on this bug.

(In reply to comment #18)
> Why is it OK not to make the corresponding changes to nsNativeTheme.cpp?

Because nsNativeThemeWin is not a subclass of nsNativeTheme (I don't know why)
and this bug is Win32-specific -- all dups of bug 224974 were filed on Win32.
There are similar code in nsNativeTheme::IsWidgetStyled(), but lxr shows the
code is only executed on Mac.

(In reply to comment #16)
> I assume you've checked that TEXTFIELD_BORDER_SIZE is indeed the right border
> for a listbox? (maybe it's worth a separate #define, for clarity)

I have found CSS border: on SELECT is not honored by layout (see bug 150176), so
removing border checking code for LISTBOX seems to be good.

(In reply to comment #17)
> It fixes bug 224974, but it still doesn't fix background:transparent.

This can be partially fixed by adding an additional case for NS_THEME_DROPDOWN
to the patch, but I can't figure out how the _dropdown subwindow_ is rendered
(its background is always dark gray, when 'background: transparent' is applied
on SELECT like this bug's original testcase).

I'll update the patch soon.

Comment 20

[Isaac Hwak Han]

Attachment: Updated patch

- Added a case for DROPDOWN
- Removed CSS border checking for LISTBOX and DROPDOWN

Comment 21

[Boris Zbarsky [:bzbarsky]]

> lxr shows the code is only executed on Mac.

Yep.  And this bug does not show on Mac?  I'd be happier if both codepaths were
fixed (I don't quite understand why they are even separate...)

> I have found CSS border: on SELECT is not honored by layout

Please don't introduce _more_ dependancies on ua.css into this code.  We should
be moving toward having no such dependencies instead -- ua.css is subject to
change without notice.

Comment 22

[Malcolm Rowe]

Comment on attachment 139753 [details] [diff] [review]
Updated version of Isaac's patch

Clearing obsolete review requests.

I did wonder whether we should make Windows' nsNativeThemeWin inherit from
nsNativeTheme, just like the Mac version (but not the GTK version) - then at
least we could get rid of the Windows-specific version of IsWidgetStyled, and
use the shared one (and presumably also create a virtual method or methods to
retrieve the 'default settings' from the implementation classes, rather than
leave the [Mac-specific?] constants in nsNativeTheme).

I haven't got a Mac, so I can't test whether this bug is also a problem there.

> Please don't introduce _more_ dependancies on ua.css into this code.

Agreed. Is there any way we can fetch the style rules directly from ua.css,
rather than have to duplicate them here?

Comment 23

[Isaac Hwak Han]

> I did wonder whether we should make Windows' nsNativeThemeWin inherit from
> nsNativeTheme, just like the Mac version (but not the GTK version)

I filed bug 232175.

Comment 24

[[e-mail]]

Will this code have any impact on bug 227399?
Please dup/depend as necessary, thanks.

Comment 25

[Boris Zbarsky [:bzbarsky]]

We could maybe introduce a new style resolution method that would resolve style
using only sheets from the UA level?

Comment 26

[Malcolm Rowe]

> We could maybe introduce a new style resolution method that would resolve style
> using only sheets from the UA level?

I wondered whether we could get nsNativeTheme to cache the results of
getComputedStyle() on an otherwise unadorned <textarea>, <input type="select">,
etc, for the properties we're interested in. That would remove the dependency on
ua.css, and the only difference should be whether userContent.css is involved.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 139882 [details] [diff] [review]
Updated patch

sr=bzbarsky.  I think we should try to get this in for beta.  This is a pretty
high-visibility problem in form control rendering...

Comment 28

[chris hofmann]

Comment on attachment 139882 [details] [diff] [review]
Updated patch

a=chofmann for 1.7b

Comment 29

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 139882 [details] [diff] [review]
Updated patch

I assume chofmann meant to set the flag too...

Comment 30

[Boris Zbarsky [:bzbarsky]]

Checked that patch in.  Leaving open for the remaining combobox issues...

Comment 31

[[e-mail]]

Hey, did this fix bug 227399 too? If so, can someone comment to that effect?

Comment 32

[chris hofmann]

oops.  yes, thanks for setting the flag borris

Comment 33

[[e-mail]]

And did this fix bug 237138 too? If so, can someone comment to that effect?

Comment 34

[Boris Zbarsky [:bzbarsky]]

Neil, this certainly would not have fixed bug 237138

Comment 35

[[e-mail]]

bz, well, I'm finding it difficult to debug since the colours set in forms.css
seem to be overriding anything else...

Comment 36

[Boris Zbarsky [:bzbarsky]]

Eh?  They are?  You mean we're not using native theming for those controls?

Comment 37

[[e-mail]]

Sorry, must be an oddity in my build...

Comment 38

[Hermann Schwab]

Asking for blocking 1.8a4
testcase still shows the bug, and there is a patch having approval and
superreview for nearly half a year. Was approved for 1.7b, and still not checked
in to Mozilla 1.7.4.

Comment 39

[Christian :Biesinger (don't email me, ping me on IRC)]

> still not checked in to Mozilla 1.7.4.

are you sure about that? comment 30 said:
> Checked that patch in. 

Comment 40

[Hermann Schwab]

(In reply to comment #39)
> > still not checked in to Mozilla 1.7.4.
> 
> are you sure about that? comment 30 said:
> > Checked that patch in. 

No, I´m not sure.
I saw a testcase, tested, and saw the bug.
I saw a patch, looked at bug activity, when it was approved, and that was march.
( same time as comment 30 ;-)

So I assume you are correct that this patch got checked in, and the bug is open
for the remaining issues, the select with grey background.
It´s the small field between the password box and the textarea input.

Comment 41

[RNicoletto]

Last testcase WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 

Is this bug still valid?

Comment 42

[Hermann Schwab]

WFM using testcase
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090409 SeaMonkey/2.0b1pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10pre) Gecko/2009041006 GranParadiso/3.0.10pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090409 Minefield/3.6a1pre

Bug (background grey in open select as seen in my comment 40) still seen in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20