452800 - textarea and input styled non-inset/outset border styles do not display 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.1) Gecko/2008070208 Firefox/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0pre

If I change the border style of an input type=text or a textarea that border does not appear when in high contrast mode and it should.  



Reproducible: Always

Steps to Reproduce:
1. create the following input:
<label for="inline">Inline style: </label><input type="text" style="border:1px solid green;">
2. view in FF3 - input has a green border
3. turn on windows high contrast mode
4. reload file - the input border is no longer visible.  
You should be able to restyle the border of an input or textarea and still have it work when in high contrast mode. The above steps work properly in Firefox 2, IE6 and IE7

Actual Results:  
styled border on input or textarea is not visible in high contrast mode.

Expected Results:  
styled border should still be visible with color overridden to the high contrast theme.

Comment 1

[Becky Gibson]

Attachment: demonstrates problem of styled input and textarea in high contrast mode

Comment 2

[mike.billau]

Hello. I wanted to point out that this was somehow fixed in FF ESR, but has been broken again with the latest version (15).

Comment 3

[Piyush Agarwal]

Hello, we can reproduce this as well in FF ESR 17.0.2 and FF18.

Thanks,
Piyush Agarwal

Comment 4

[dlindsey]

I can reproduce on FF19

Comment 5

[Josh Dick]

This bug can still be reproduced in Firefox 25.

Comment 6

[roy]

This bug persists in Firefox 26 as well (running on Windows 7).  Is there a forthcoming fix? (or at least a work-around?)

Comment 7

[alexander :surkov (:asurkov)]

Do you know somebody how could help with the issue?

Comment 8

[Alexander Krauss]

I can still reproduce this in Firefox 36.0.1.

From a page author's perspective, a possible (but ugly) workaround is to detect high contrast mode (by observing that background-image properties are set to 'none' even when background images were declared in the css) and apply a border-style of "inset" or "outset" buttons and inputs in this case. Then, at least some borders are visible, which is better than having no borders at all.

Comment 9

[Marco Zehe (:MarcoZ)]

Gijs, any good place where these bugs live nowadays?

Comment 10

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #9)
> Gijs, any good place where these bugs live nowadays?

I don't actually understand what the desired fix is, and that probably helps determine where this should live.

We've not honoured any author-specified colors, including border colors, in high contrast mode since the dawn of time. We recently added a user-visible pref which will let you override this behaviour (bug 639134).

I don't know what this bug is asking for. Marco, can you clarify?

Comment 11

[Marco Zehe (:MarcoZ)]

Passing the question on to Becky who filed the bug first. Being totally blind, I don't know the answer.

Comment 12

[Alexander Krauss]

I think I can clarify this, as this is easily reproducable:

- On Windows, enable high contrast mode (by pressing Alt+LeftShift+PrtScrn).
- View attachment 336061 [details] in Firefox

Observed result:
- The unstyled inputs are displayed with a border (the default style)
- Inputs with an explicitly styled border are displayed with no border at all

Expected result:
- Inputs with an explicitly styled border are displayed in the default style, i.e., with the default border but no colors etc.

Impact:
- In high contrast mode, empty input fields effectively disappear. This introduces an accessibility problem for visually impaired users, who must rely
on high-contrast mode.

Further observations:
- The bug is triggerd as soon as a border-style property other than 'inset' or 'outset' is applied.

Comment 13

[:Gijs (he/him)]

This regressed between 2007-05-09 and 2007-05-10... but about:buildconfig doesn't have rev information. I'll look for those manually later today.

Comment 14

[:Gijs (he/him)]

This was initially regressed by bug 58048 (though I've seen other odd behaviours while regression hunting that might be explained by the followups from there). I don't know how helpful that is, but in any case, Boris and/or dbaron will know a lot more than me about how to fix it.

Comment 15

[Rich Schwerdtfeger]

This has been outstanding since April. Can someone focus on this issue? Firefox is the certified IBM browser for its employees and some use this in high contrast mode due to a low vision impairment. Can some focus be put on this?

Comment 16

[:Gijs (he/him)]

Boris, any chance you could have a look at this, or provide hints for someone else looking?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Is this problem reproducible by just setting "Override the colors specified by the page with my selections above:" to "Always" in preferences?  Or do you have to be in an actual high-contrast mode?  Because I just tried the "Always" setting and at least on Mac I do get a border on the input if the page has <input style="border: 5px solid green">.

If this requires an actual high-contrast mode, I'd have to dig up a Windows machine to look myself, but a good start would be checking what colors -moz-Field and ThreeDFace are in that high-contrast mode.

Comment 18

[Hans Hillen]

The issue is specific to Windows High Contrast Mode, so you do need a Windows (virtual) machine to reproduce it. Also see my comment at https://bugzilla.mozilla.org/show_bug.cgi?id=790623 for more information and another test case.

Comment 19

[Boris Zbarsky [:bzbarsky]]

OK.  Well, I'm not likely to hunt down a Windows machine until at least two weeks from now; I have other things on my priority list.  Someone who has one getting the information I asked for in comment 17 would be pretty useful, though.

Comment 20

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #17)
> A good start would be checking what colors
> -moz-Field and ThreeDFace are in that high-contrast mode.

There are different HCM themes. On Windows 8:

"High Contrast White": both #fff.
"High Contrast Black": both #000.
"High Contrast #1": both #000. 
"High Contrast #2": both #000.

All of these are identical to the background color of the respective HCM themes. This probably makes a reasonable amount of sense in that -moz-Field is (I think?) meant to correspond to the background color of fields (-moz-fieldtext would correspond to text color, and is in use here), and in HCM there are no 3D button effects, so the result of that is somewhat arbitrary.

We don't have a good media query for high contrast mode (and exposing one to web content has both pros and cons which I don't think we should get into in this thread), but in browser code we tend to use:

@media not all and (-moz-windows-default-theme) {}

maybe combined with checking for classic (for which we also have a media query, and where the defaults probably make sense?).

I wonder if just using that to pick a different default border color (-moz-fieldtext ? ) in forms.css for these themes and |input| would be enough.

This would in theory impact other third-party Windows themes. Historically, that hasn't really been a cause for concern, as the number of users on those themes is extremely small.

Boris, does this sound sensible?

Comment 21

[Boris Zbarsky [:bzbarsky]]

> All of these are identical to the background color of the respective HCM themes.

OK, well there is our problem.  In forms.css we use -moz-Field for the background of the input and ThreeDFace for the border color.  If they're the same color, then you won't see a border distinct from the background.  (I know you already knew all this; mostly for the benefit of others following along).

> Boris, does this sound sensible?

Seems ok to me.

Comment 22

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

Bug 452800 - change border colors on high contrast windows themes, r?bz,f?dao

Comment 23

[:Gijs (he/him)]

Comment on attachment 8628433 [details]
MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

Dão, can you check if my media query fu is sensible here?

Comment 24

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8628433 [details]
MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

https://reviewboard.mozilla.org/r/12381/#review10887

::: layout/style/forms.css:62
(Diff revision 1)
> -  border: 2px groove ThreeDFace;
> +  border: 2px groove var(--threedfacebordercolor);

Nothing guarantees that -moz-FieldText is visible for fieldset, since it doesn't have -moz-field as a background color.  Maybe just have that fall back to black?  Or better yet currentColor?

::: layout/style/forms.css:80
(Diff revision 1)
> -  border: 2px inset ThreeDFace;
> +  border: 2px inset var(--threedfacebordercolor);

Again, it might make some sense to fall back to currentColor.  At least that's pretty darn likely to be visible against the background!

::: layout/style/forms.css:216
(Diff revision 1)
> -  border-color: ThreeDFace;
> +  border-color: var(--threedfacebordercolor);

This should use -moz-ComboboxText, or, again, currentColor.  Nothing ensures that -moz-fieldtext is visible on top of a -moz-combobox background.

::: layout/style/forms.css:562
(Diff revision 1)
> -  border: 1px inset ThreeDShadow ! important;
> +  border: 1px inset var(--threedshadowbordercolor) ! important;

What guarantees that -moz-fieldtext is different from ThreeDFace, which we're using for background color here?  Again, using the same thing as color (either GrayText explicitly or currentColor) would be better.

::: layout/style/forms.css:604
(Diff revision 1)
> -  border: 2px outset ButtonFace;
> +  border: 2px outset var(--buttonfacebordercolor);

Same issue here: -moz-fieldtext may not be visible on top of ButtonFace.

More generally, though, this code is not trying to make the borders particularly visible on top of the background.  I'm not sure we should change that.

::: layout/style/forms.css:718
(Diff revision 1)
> -  border: 2px outset ButtonFace;
> +  border: 2px outset var(--buttonfacebordercolor);

And here, same thing with ButtonFace

::: layout/style/forms.css:35
(Diff revision 1)
> +  --threedfacebordercolor: ThreeDFace;

Worth checkin with Cameron on the performance implications of using variables here, if any.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8628433 [details]
MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

Cameron, how OK are you with using variables in UA stylesheets in this situation?

Comment 26

[:Gijs (he/him)]

https://reviewboard.mozilla.org/r/12381/#review10887

> Same issue here: -moz-fieldtext may not be visible on top of ButtonFace.
> 
> More generally, though, this code is not trying to make the borders particularly visible on top of the background.  I'm not sure we should change that.

So the net consequence of high contrast mode is that very few different colors are in use. When I tested buttons, they were indistinguishable from the background (ie both the background color and the border color of the button end up being the same as the document background color), making it hard to figure out how to click them. Of course, normally the "outset" part "fixes" this (so the border is visible in a single color, but the background of the button stays the same as the background of the doc), but as soon as a website changes the border-style to "solid", we're in trouble.

Comment 27

[Boris Zbarsky [:bzbarsky]]

OK.  In that case, I would vote we use currentColor on the buttons too.

Comment 28

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #27)
> OK.  In that case, I would vote we use currentColor on the buttons too.

OK. Presumably we still want to restrict this to the HCM case only. I'll wait for Dão and Cameron's feedback and then put up a new patch that uses currentColor where suggested.

Comment 29

[Boris Zbarsky [:bzbarsky]]

> Presumably we still want to restrict this to the HCM case only.

Yes, we do.

Comment 30

[Dão Gottwald [:dao]]

Comment on attachment 8628433 [details]
MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

The !-moz-windows-default-theme && !-moz-windows-classic media query doesn't seem to make sense.

It seems to me that we should just use ThreeDLightShadow, which as opposed to ThreeDFace is actually meant to be used as a border color.

Comment 31

[Cameron McCormack (:heycam)]

Comment on attachment 8628433 [details]
MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

(In reply to Boris Zbarsky [:bz] from comment #25)
> Cameron, how OK are you with using variables in UA stylesheets in this
> situation?

I'm not too worried about the performance and memory implications -- the time needed to re-parse the border property at computed value time shouldn't be that much, and it's only 504 bytes (on 64-bit) overhead per fieldset, input, etc. element.

However, the variables will be visible to content.  You'll be able to see them on a computed style object for these elements.  I don't think we should be leaking the implementation details to content like this.  So unfortunately I think we should just be doing something like this instead:

  fieldset {
    border: 2px groove ButtonFace;
  }

  %ifdef XP_WIN
  @media not all and (-moz-windows-default-theme) {
    @media not all and (-moz-windows-classic) {
      fieldset {
        border: 2px groove -moz-FieldText;
      }
    }
  }
  %endif

Comment 32

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #30)
> Comment on attachment 8628433 [details]
> MozReview Request: Bug 452800 - change border colors on high contrast
> windows themes, r?bz,f?dao
> 
> The !-moz-windows-default-theme && !-moz-windows-classic media query doesn't
> seem to make sense.

Could you explain why you think not? Classic counts as "not default theme" (just doublechecked on my win7 VM), so the "!-moz-windows-classic" part restricts the subset of Windows themes where we apply this. That seems correct to me.

> It seems to me that we should just use ThreeDLightShadow, which as opposed
> to ThreeDFace is actually meant to be used as a border color.

The result is not the same, though. Close (to my eyes, anyway), but not the same (specifically #f0f0f0 vs. #e3e3e3 on win8 modern).

Are you saying you expect that the right thing is to change that default color everywhere? That seems pretty scary from a web compat perspective. It's also not clear to me whether you think it is a correct replacement for "ButtonFace" where we are currently using that, or just for ThreeDFace.

(In reply to Cameron McCormack (:heycam) from comment #31)
> However, the variables will be visible to content.  You'll be able to see
> them on a computed style object for these elements.

Boo. :-(
*mumbles something about having nice things*

(Thanks for flagging this up early!)

Comment 33

[Dão Gottwald [:dao]]

(In reply to :Gijs Kruitbosch from comment #32)
> (In reply to Dão Gottwald [:dao] from comment #30)
> > The !-moz-windows-default-theme && !-moz-windows-classic media query doesn't
> > seem to make sense.
> 
> Could you explain why you think not? Classic counts as "not default theme"
> (just doublechecked on my win7 VM), so the "!-moz-windows-classic" part
> restricts the subset of Windows themes where we apply this. That seems
> correct to me.

Restrict to what? This applies to any third-party theme. Even worse, high contrast themes are classic themes at least on Windows XP, aren't they? Not sure about later versions; if we don't consider them classic there I think we might even want to change that, since classic basically just means "bulky design with unpredictable platform colors" and high contrast fits well in that bucket.

> > It seems to me that we should just use ThreeDLightShadow, which as opposed
> > to ThreeDFace is actually meant to be used as a border color.
> 
> The result is not the same, though. Close (to my eyes, anyway), but not the
> same (specifically #f0f0f0 vs. #e3e3e3 on win8 modern).
> 
> Are you saying you expect that the right thing is to change that default
> color everywhere?

Yes

> That seems pretty scary from a web compat perspective.

How so?

> It's also not clear to me whether you think it is a correct replacement for
> "ButtonFace" where we are currently using that, or just for ThreeDFace.

Seems correct for both.

Comment 34

[Hans Hillen]

I don't want to distract from this effort, but can I just add that FF currently doesn't appropriately update link colors when switching to an HC mode. So the user has to change default link colors manually on each switch, or (likely) end up with the poorly contrasting link colors (e.g. dark blue and purple on a black background). Instead, links should just be given a color that makes sense in the chosen color contrast scheme when an HC mode is changed (which is what IE does).

Comment 35

[:Gijs (he/him)]

(In reply to Hans Hillen from comment #34)
> I don't want to distract from this effort, but can I just add that FF
> currently doesn't appropriately update link colors when switching to an HC
> mode. So the user has to change default link colors manually on each switch,
> or (likely) end up with the poorly contrasting link colors (e.g. dark blue
> and purple on a black background). Instead, links should just be given a
> color that makes sense in the chosen color contrast scheme when an HC mode
> is changed (which is what IE does).

I'm sorry, but it's not useful to bring that up here. It won't get fixed in this bug. Please file a different bug (if one is not filed already, which I suspect it is).


(In reply to Dão Gottwald [:dao] from comment #33)
> (In reply to :Gijs Kruitbosch from comment #32)
> > (In reply to Dão Gottwald [:dao] from comment #30)
> > > The !-moz-windows-default-theme && !-moz-windows-classic media query doesn't
> > > seem to make sense.
> > 
> > Could you explain why you think not? Classic counts as "not default theme"
> > (just doublechecked on my win7 VM), so the "!-moz-windows-classic" part
> > restricts the subset of Windows themes where we apply this. That seems
> > correct to me.
> 
> Restrict to what?

The intent was: high contrast windows themes, and I knew that this would include third-party themes, and that was not a dealbreaker to me considering population size for that group.

> Even worse, high
> contrast themes are classic themes at least on Windows XP, aren't they?

I did not know this. But yes, this is the case on XP and Windows 7, but not on Windows 8. I'm not sure that updating win8 (compositor) high contrast themes to be classic makes sense for our style rules, but it's not really within the scope of this bug anyway.

> > > It seems to me that we should just use ThreeDLightShadow, which as opposed
> > > to ThreeDFace is actually meant to be used as a border color.
> > 
> > The result is not the same, though. Close (to my eyes, anyway), but not the
> > same (specifically #f0f0f0 vs. #e3e3e3 on win8 modern).
> > 
> > Are you saying you expect that the right thing is to change that default
> > color everywhere?
> 
> Yes
> 
> > That seems pretty scary from a web compat perspective.
> 
> How so?

Changing the default border colors for these widgets on every website we render, for everybody, is much more high risk than restricting the change to less-frequently-used themes, where the current colors don't work well for some of them. Likewise, testing this change across all the different Windows versions and themes is a lot more work, and it's not like it'll give us much of a guarantee we won't be breaking styling somewhere. OTOH, form control styling on the web is pretty messy already, so maybe we can just "whatever" that concern? I don't know. (bz?)

I had a look at our implementation, and it seems threedlightshadow is the same as threedface on gtk, and that the two are hardcoded in our cocoa implementation (as #f0f0f0 for threedface (and buttonface), and #dadada for threedlightshadow). On Windows, it'll depend on the Windows theme.

Comment 36

[Boris Zbarsky [:bzbarsky]]

> so maybe we can just "whatever" that concern?

How consistent are these border colors across browsers in practice?

Comment 37

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] from comment #36)
> > so maybe we can just "whatever" that concern?
> 
> How consistent are these border colors across browsers in practice?

I will try to have a look later this week.

Comment 38

[Dão Gottwald [:dao]]

I don't think that question is all that interesting. For web content these colors are already moving targets because OS themes vary.

Comment 39

[:Gijs (he/him)]

(In reply to Dão Gottwald [:dao] from comment #38)
> I don't think that question is all that interesting. For web content these
> colors are already moving targets because OS themes vary.

The question is whether that is actually the case for other browsers. They might not use the OS theme colors at all. I'd also note that "even" for Firefox, Windows 7 + 8 compositor values are all identical (no matter what aero/aero basic / modern style you use). It's just classic, winxp and hcm which are "special".

Comment 40

[Dão Gottwald [:dao]]

(In reply to :Gijs Kruitbosch from comment #39)
> (In reply to Dão Gottwald [:dao] from comment #38)
> > I don't think that question is all that interesting. For web content these
> > colors are already moving targets because OS themes vary.
> 
> The question is whether that is actually the case for other browsers. They
> might not use the OS theme colors at all.

Even if they don't, how's that relevant for whether we can switch from one platform color to another one?

> I'd also note that "even" for
> Firefox, Windows 7 + 8 compositor values are all identical (no matter what
> aero/aero basic / modern style you use). It's just classic, winxp and hcm
> which are "special".

And OS X and all kinds of Linux flavors.

Comment 41

[:Gijs (he/him)]

Comment on attachment 8628433 [details]
MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

Comment 42

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8628433 [details]
MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz

https://reviewboard.mozilla.org/r/12381/#review12089

Ship It!

Comment 43

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/662737a36e01

Comment 44

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/662737a36e01

Comment 47

[jmikebot]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #17)
> Is this problem reproducible by just setting "Override the colors specified
> by the page with my selections above:" to "Always" in preferences?  Or do
> you have to be in an actual high-contrast mode?  Because I just tried the
> "Always" setting and at least on Mac I do get a border on the input if the
> page has <input style="border: 5px solid green">.
> 
> If this requires an actual high-contrast mode, I'd have to dig up a Windows
> machine to look myself, but a good start would be checking what colors
> -moz-Field and ThreeDFace are in that high-contrast mode.

You do have to be in high-contrast mode.  When I disable high-contrast mode, my theme is identical; however, the problem does not persist.

Comment 48

[Boris Zbarsky [:bzbarsky]]

Commenting on a fixed bug is not likely to have any useful effect...

Comment 49

[jmikebot]

Update: it does persist, however, that forms can be completely black in the background, and it does persist that some fields have no outline or a black outline and are the same color as the background; so, they are invisible to users. 

Disabling high-contrast mode effects other applications, and it would be very nice to continue them.  Also, I might have an OS bug.  I will re-confirm later.

(In reply to jmikebot from comment #47)
> (In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #17)
> > Is this problem reproducible by just setting "Override the colors specified
> > by the page with my selections above:" to "Always" in preferences?  Or do
> > you have to be in an actual high-contrast mode?  Because I just tried the
> > "Always" setting and at least on Mac I do get a border on the input if the
> > page has <input style="border: 5px solid green">.
> > 
> > If this requires an actual high-contrast mode, I'd have to dig up a Windows
> > machine to look myself, but a good start would be checking what colors
> > -moz-Field and ThreeDFace are in that high-contrast mode.
> 
> You do have to be in high-contrast mode.  When I disable high-contrast mode,
> my theme is identical; however, the problem does not persist.