textarea and input styled non-inset/outset border styles do not display in high contrast mode

RESOLVED FIXED in Firefox 42

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
9 years ago
6 months ago

People

(Reporter: Becky Gibson, Assigned: Gijs)

Tracking

(Blocks: 4 bugs, {regression})

unspecified
mozilla42
x86
Windows XP
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 fixed)

Details

(URL)

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Created attachment 336061 [details]
demonstrates problem of styled input and textarea in high contrast mode

Updated

9 years ago
Blocks: 343205

Comment 2

5 years ago
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

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

Thanks,
Piyush Agarwal

Comment 4

4 years ago
I can reproduce on FF19

Comment 5

4 years ago
This bug can still be reproduced in Firefox 25.

Comment 6

4 years ago
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

4 years ago
Do you know somebody how could help with the issue?

Comment 8

2 years ago
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

2 years ago
Gijs, any good place where these bugs live nowadays?
Flags: needinfo?(gijskruitbosch+bugs)
(Assignee)

Comment 10

2 years ago
(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?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mzehe)
Passing the question on to Becky who filed the bug first. Being totally blind, I don't know the answer.
Flags: needinfo?(mzehe) → needinfo?(gibsonb)

Comment 12

2 years ago
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.
(Assignee)

Updated

2 years ago
Component: Disability Access → CSS Parsing and Computation
Flags: needinfo?(gibsonb) → needinfo?(gijskruitbosch+bugs)
Product: Firefox → Core
(Assignee)

Updated

2 years ago
Summary: textarea and input styled borders do not display in high contrast mode → textarea and input styled non-inset/outset border styles do not display in high contrast mode
Comment hidden (obsolete)
(Assignee)

Comment 14

2 years ago
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.
Blocks: 58048
Flags: needinfo?(gijskruitbosch+bugs)

Comment 15

2 years ago
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?
(Assignee)

Comment 16

2 years ago
Boris, any chance you could have a look at this, or provide hints for someone else looking?
Flags: needinfo?(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.
Flags: needinfo?(bzbarsky)

Comment 18

2 years ago
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.
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.
(Assignee)

Comment 20

2 years ago
(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?
Flags: needinfo?(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.
Flags: needinfo?(bzbarsky)
(Assignee)

Updated

2 years ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
(Assignee)

Comment 22

2 years ago
Created attachment 8628433 [details]
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
Attachment #8628433 - Flags: review?(bzbarsky)
(Assignee)

Comment 23

2 years ago
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?
Attachment #8628433 - Flags: feedback?(dao)
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.
Attachment #8628433 - Flags: review?(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?
Attachment #8628433 - Flags: feedback?(cam)
(Assignee)

Comment 26

2 years ago
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.
OK.  In that case, I would vote we use currentColor on the buttons too.
(Assignee)

Comment 28

2 years ago
(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.
> Presumably we still want to restrict this to the HCM case only.

Yes, we do.
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.
Attachment #8628433 - Flags: feedback?(dao) → feedback-
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
Attachment #8628433 - Flags: feedback?(cam) → feedback-
(Assignee)

Comment 32

2 years ago
(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!)
Flags: needinfo?(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.
Flags: needinfo?(dao)

Comment 34

2 years ago
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).
(Assignee)

Comment 35

2 years ago
(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.
Flags: needinfo?(bzbarsky)
> so maybe we can just "whatever" that concern?

How consistent are these border colors across browsers in practice?
Flags: needinfo?(bzbarsky)
(Assignee)

Comment 37

2 years ago
(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.
Flags: needinfo?(gijskruitbosch+bugs)
I don't think that question is all that interesting. For web content these colors are already moving targets because OS themes vary.
(Assignee)

Comment 39

2 years ago
(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".
(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.
(Assignee)

Comment 41

2 years ago
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
Attachment #8628433 - Attachment description: MozReview Request: Bug 452800 - change border colors on high contrast windows themes, r?bz,f?dao → MozReview Request: Bug 452800 - use ThreeDLightShadow for borders instead of ThreeDFace or ButtonFace, r?bz
Attachment #8628433 - Flags: review?(bzbarsky)
Attachment #8628433 - Flags: feedback-
Attachment #8628433 - Flags: review?(bzbarsky) → review+
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!
(Assignee)

Updated

2 years ago
Flags: needinfo?(gijskruitbosch+bugs)

Comment 43

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/662737a36e01
https://hg.mozilla.org/mozilla-central/rev/662737a36e01
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox42: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Duplicate of this bug: 1203613
(Assignee)

Updated

a year ago
Duplicate of this bug: 797040
Comment hidden (offtopic)
Commenting on a fixed bug is not likely to have any useful effect...
Comment hidden (offtopic)
Blocks: 898437
Blocks: 779725
Blocks: 698710
You need to log in before you can comment on or make changes to this bug.