Closed Bug 1105364 Opened 10 years ago Closed 3 years ago

Transparent borders get rendered as opaque in High Contrast mode (because "border-color:transparent" is ignored and forced to the foreground color)

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
94 Branch
Accessibility Severity s3
Tracking Status
firefox93 --- wontfix
firefox94 --- fixed

People

(Reporter: jaws, Assigned: emilio)

References

Details

(Keywords: access, Whiteboard: [hcm-2021-h2])

Attachments

(2 files)

STR:
Enable High-Contrast mode on Windows
Visit the following page:
data:text/html,<span style='border:100px solid transparent'>hello</span

ER:
The text should not have a border surrounding it.

AR:
The text has a 100px border surrounding it, even though the border-color is 'transparent'.

Seems similar to bug 495798.
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #0)
> ER:
> The text should not have a border surrounding it.

The text should not have a visible border surrounding it. It should remain transparent.

> 
> AR:
> The text has a 100px border surrounding it, even though the border-color is
> 'transparent'.

The text has a 100px opaque border surrounding it.
This is not about high-contrast mode but rather the behavior of the "allow pages to change colors" preference, no?  It just happens that high-contrast mode enables that...
border-bottom-color has CSS_PROPERTY_IGNORED_WHEN_COLORS_DISABLED. Does that map to the "allow pages to change colors", and if so, how does high-contrast mode or the "allow pages to change colors" mode refer to 'transparent' as an opaque color?
CSS_PROPERTY_IGNORED_WHEN_COLORS_DISABLED is consulted when "allow pages to change colors" is false, yes.

In that mode, for a property that has that flag, it looks like we have the following behavior:

1)  If the property is "background-color", leave colors that have an alpha of 0 alone and
    convert any other value to the user's default background color.
2)  For any other property, ignore the color declaration.

So back to your testcase.  It gets treated identically to:

  data:text/html,<span style='border:100px solid'>hello</span

because the "transparent" color value is ignored, because the property involved is not "background-color".
Attached patch WIPSplinter Review
So what would be wrong with doing this? (it doesn't work by the way. setting the color to be 'red' for example doesn't end up drawing any color in high contrast mode).
> So what would be wrong with doing this?

Nothing per se, with the following caveats:

1)  It's a behavior change (e.g. allows pages to restyle the borders of form controls
    even when "allow pages to change colors" is false).  Is it a behavior change we
    want?
2)  nsRuleNode::HasAuthorSpecifiedRules also needs to be adjusted.
3)  Using the default _background_ color for borders is clearly wrong.  That's what your
    "doesn't work" is presumably about: you're getting a default background color (white,
    I bet) border on top of your default background (also white, I bet).  Using the
    default border color (that is "currentColor") would make more sense if we want to do
    something like this.

This bug would probably be worth investigating, as we make steps to improve our High Contrast Mode experience (and opt-in a bunch of mac users via bug 1713015).

Right now the Google login page has weird broken-looking black bars, which are actually just transparent borders that Google is using for layout purposes rather than as actual borders (i.e. they're not intended to be visible). See screenshot in attachment 9236384 [details] and notes in bug 1725899 comment 5.

OS: Windows 7 → All
Hardware: x86_64 → All
See Also: → 1725899
Summary: border-color:transparent is shown as the inherited color when in High Contrast mode → Transparent borders get rendered as opaque in High Contrast mode (because "border-color:transparent" is ignored and forced to the foreground color)

haha I was just looking to see if we had a bug on this -- emilio, I think we need to add a similar clause in that tweak declarations function for border color, like we do for background. what do you think?

Flags: needinfo?(emilio)

I think we're the only browser that has this issue, BTW. Google's "High Contrast" extension for Chrome has a black-text-on-yellow-background mode which is pretty similar to our HCM/forced-colors mode, and which doesn't have this problem.

I don't know offhand if they use roughly the same implementation approach that we do (ignoring color-valued properties, with some sort of exception for this case) vs. if they do something completely different under the hood.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

Yeah this looks sensible, patch posted.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/04110942c22b
Respect transparent and system color border colors in forced-colors mode. r=morgan
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
Regressions: 1728187

Can we get this backed out from beta when the merge happens? The front-end team needs some time to fix bug 1728187 so it'd be better to do that. It shouldn't be necessary to back out from central.

Flags: needinfo?(sheriffs)

I will take care of this on merge day (Sep 6th).

Flags: needinfo?(sheriffs)

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.
If yes, don't forget to request an uplift for the patches in the regression caused by this fix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Keywords: access
Whiteboard: [hcm-2021-h2][access-s3]
Regressions: 1740924

This change is a major a11y regression for Windows High Contrast users. Transparent borders are a very common web technique for ensuring that shapes are visible in High Contrast mode: https://www.google.com/search?q=transparent+border+high+contrast

Whiteboard: [hcm-2021-h2][access-s3] → [hcm-2021-h2]
Accessibility Severity: --- → s3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: