495798 - background-color:transparent on button not honored in high contrast mode

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Becky Gibson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0pre

Overlay a button over text or an image. Set the button style to background-color:transparent.  The text or image the button is on top of should be visible within the button borders.  This does not work in high contrast mode.  

This used to work correctly in Firefox 2 and in Firefox 3.0.5.  It no longer works in Firefox 3.0.10 nor in a Minefield daily build.  

This example is fairly simple, a button over an image, But, this is causing a much bigger problem where a button is overlaid over text in order to make a large clickable area.  

Reproducible: Always

Steps to Reproduce:
1. load http://weba11y.com/Examples/bugs/buttonTransparencyHC.html 
2.Note that the image is visible within the border of the transparent button.
3.Switch to high contrast mode.  
Actual Results:  
The image is no longer visible within the borders of the button because background-color:transparent is not honored for the button.

Expected Results:  
In high contrast mode, background-color:transparent should be honored on a button. This worked in Firefox 2 and through Firefox 3.0.5.

Comment 1

[Dão Gottwald [:dao]]

Could you please attach a screenshot? It's not clear to me what you're seeing.

Comment 2

[Becky Gibson]

Attachment: This image shows a button with background-color:transparent displayed above an image in normal mode.

Because the button is transparent, you can see the image through the button. The button is above the mouse pointer and contains the value "text".

Comment 3

[Becky Gibson]

Attachment: This image shows a button with background-color:transparent displayed above an image in Windows High Contrast mode.

Notice that the background of the button is now solid - the image can no longer be seen through the button even though background-color: transparent has been set on the button.   Shouldn't transparent still be honored in high contrast mode even though colors are not?  This worked up until Firefox 3.0.7.

Comment 4

[Becky Gibson]

Attachment: This image shows a set of three buttons with a name above the buttons.

This is a real world example. There is a transparent button overlayed on top of the text so that the name is clickable.

Comment 5

[Becky Gibson]

Attachment: This image shows a set of three buttons with a name above the buttons in High contrast mode, the name is no longer visible.

Refer to the attached NormalMode.bmp to see where the names should be displayed.   This is a real world example where a button with background-color:transparent is overlain above the text.   Before Firefox 3.0.7 the names were still visible in high contrast mode.

Comment 6

[Becky Gibson]

Attachment: Real world example of problems using background-color:transparent on a button in high contrast mode

When you view this file in normal mode you will see "Lance Armstrong" displayed twice.   When you view this file in Windows high contrat mode, the text is no longer visible.  That is because the text is below a button with background-color:transparent.  The transparent setting is not honored in high contrast mode but it used to be up until Firefox 3.0.7.

Comment 7

[Dão Gottwald [:dao]]

I can't reproduce this.

Comment 8

[Becky Gibson]

Attachment: Image of the problem in Minefield 20090602 build

This is the example at http://weba11y.com/Examples/bugs/buttonTransparencyHC.html running in high contrast mode on a the 20090602 Minefield daily build.  The button in the center of the image containing the value "test" should be transparent but it is not.  The button is displaying using the high contrast background color of black.  The button has background-color:transparent set and that should be honored in high contrast mode.

Comment 9

[Joseph Scheuhammer (:clown)]

I can reproduce this, following the "steps to reproduce" in the original description above.

Details:
- WinXP SP3
- FF 3.0.11 (button is *not* transparent in high contrast mode).
- FF 2.0.0.20 (button *is* transparent in high contrast mode).
- button is transparent in standard contrast mode for both versions.

One note: not sure it matters but... the text of the button label, "test", is white for FF2 in standard contrast mode, but black in FF3, and is white in both cases when in high contrast mode.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So this is somewhat purposeful.  High contrast mode is not needed to reproduce; it's enough to go to Firefox Preferences > Content > Colors and uncheck "Allow pages to choose their own colors".  One of the side-effects of being in a high-contrast theme is that we behave as if that were unchecked (see bug 239914).  Once that's done, of course, your page's styling on the button is ignored, and in particular your "transparent" style is ignored.

Over to accessibility in case they want to reevaluate the tradeoffs here.  Certainly not a form controls issue.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Note that contrary to bug 239914 comment 7, IE doesn't quite disable all user color styling.  It seems to allow "transparent" to be set for background, per the testcases in this bug, but not allow a background color to be set.  Confirming based on that.

Comment 12

[Boris Zbarsky [:bzbarsky]]

That said, there's something else weird going on here.  It doesn't look like we should be ignoring transparent background styles.  Let me dig a bit more.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Ah, I see what's up.  We're not dropping native theming when page's can't set their own colors.  And the reason for that is the fix for bug 437366.  Note that backing that out makes form controls unreadable in many cases for users of high-contrast themes.  Many more cases than involve transparent backgrounds.

Over to style system, but I'm really not quite sure what the right behavior is here, much less how to get it to happen...

Comment 14

[Boris Zbarsky [:bzbarsky]]

I suppose we could pass in the "document colors disabled" boolean to nsRuleNode::HasAuthorSpecifiedRules instead of not calling it at all and treat transparent specially....

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: This seems to do the trick

Comment 16

[Mike Bergstrom]

is there any additional information regarding when this might get into a build?

Comment 17

[Boris Zbarsky [:bzbarsky]]

See the whiteboard field, and http://www-archive.mozilla.org/hacking/life-cycle.html

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 381327 [details] [diff] [review]
This seems to do the trick

>+              // If author colors are not allowed, only claim to have
>+              // author-specified rules if we're looking at the background
>+              // color and it's set to transparent.  Anything else should get
>+              // set to a dummy value instead.
>+              if (aAuthorColorsAllowed ||
>+                  (i == 0 &&
>+                   (ruleTypeMask & NS_AUTHOR_SPECIFIED_BACKGROUND) &&
>+                   !values[0]->IsNonTransparentColor())) {
>+                return PR_TRUE;
>+              }

Could you precede this with an assertion documenting the assumption:

NS_ABORT_IF_FALSE(!(ruleTypeMask & NS_AUTHOR_SPECIFIED_BACKGROUND) ||
                  i != 0 ||
                  values[0] == &colorData.mBackColor,
                  "first value must be background color");

>+              values[i]->SetDummyValue();

What's this for?

The rest seems ok to me.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 381327 [details] [diff] [review]
This seems to do the trick

bz reminded me of the surrounding code which makes us need the SetDummyValue (so we ignore rules lower in the cascade that specify transparent backgrounds that are overridden by a rule specifying a non-transparent one)

So r+sr=dbaron with the assertion added.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Attachment: Merged to tip

Comment 21

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/a68245f91aa8.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Attachment: 1.9.1 merge

Comment 23

[Boris Zbarsky [:bzbarsky]]

Attachment: 1.9.0 merge

Comment 24

[Samuel Sidler (old account; do not CC)]

Comment on attachment 383580 [details] [diff] [review]
1.9.0 merge

Approved for 1.9.0.12. a=ss

Comment 25

[Boris Zbarsky [:bzbarsky]]

Fixed in CVS.

Comment 26

[Samuel Sidler (old account; do not CC)]

Fixed this in 1.9.0.12, so we should fix it in 1.9.1.x, maybe 1.9.1.1?

Comment 27

[Samuel Sidler (old account; do not CC)]

Since this blocked 1.9.0.12, I'm going to block on it for 1.9.1.1, even though it's not a security or stability fix.

Comment 28

[Samuel Sidler (old account; do not CC)]

Comment on attachment 383567 [details] [diff] [review]
1.9.1 merge

Approved for 1.9.1.1. a=ss

Comment 29

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 383567 [details] [diff] [review]
1.9.1 merge

We'll get this in 1.9.1.2, can't wait for it for the now-firedrilltastic 1.9.1.1

Comment 30

[Kevin Brosnan]

v.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.12) Gecko/2009070611 Firefox/3.0.12
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090716 Minefield/3.6a1pre

Comment 31

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 383567 [details] [diff] [review]
1.9.1 merge

a=beltzner, please land on mozilla-1.9.1

Comment 32

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/045eb5b91d08

Comment 33

[Boris Zbarsky [:bzbarsky]]

And pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ef2ea08865d9 to fix build bustage.

Comment 34

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Comment 35

[Boris Zbarsky [:bzbarsky]]

This landed before the 1.9.2 branchpoint.

Comment 36

[Ed Schiebel]

I realize this is an old issue, but I've run into the analagous problem with border-color.  Transparent borders are being rendered in the system's selected color, rendering web pages that utilize transparent borders poorly. I'm wondering if support for transparent could/should be extended to all styles, not just background-color.