Closed Bug 1705133 Opened 4 years ago Closed 4 years ago

High Contrast mode does not affect Proton modals and notification bars due to the use of hardcoded non-keyword colours in chrome docshells

Categories

(Toolkit :: Themes, defect)

defect

Tracking

()

VERIFIED FIXED
89 Branch
Accessibility Severity s2
Tracking Status
firefox87 --- disabled
firefox88 --- disabled
firefox89 --- verified

People

(Reporter: rdoghi, Assigned: Gijs)

References

(Blocks 4 open bugs)

Details

(Keywords: access, Whiteboard: [proton-modals][proton-infobars] )

Attachments

(4 files)

Attached image High Contrast.jpg (deleted) —

[Affected platforms]:
Platforms: Mac OSX, Ubuntu 20.04

[Steps to reproduce]

  1. Enable High Contrast mode on Mac OSX from the accessibility > display options
  2. Start Firefox with the following prefs enabled: browser.proton.enabled = true / prompts.windowPromptSubDialog = true / prompts.contentPromptSubDialog = true / browser.proton.modals.enabled = true
  3. Trigger any modal like the "Close multiple tabs" modal.

[Expected result]
Each button or field from the Modal should have a darker border with High Contrast enabled.

[Actual result]
There is no difference on any modal with or without High Contrast enabled on Mac OSX or Ubuntu 20.04

Has Regression Range: --- → no
Has STR: --- → yes
OS: macOS → Unspecified
Summary: High Contrast mode will not affect Modals on Mac OSX → High Contrast mode will not affect Modals on Mac and Ubuntu
Whiteboard: [proton-modals]

This affects all platforms and is due to the use of in-content/common.css in chrome. Notification bars are affected too. In content documents, high contrast automatically overrides colors, but not in chrome.

mstriemer or Gijs, is there a plan for addressing this? Basic high contrast support is kind of a must.

Severity: S3 → S2
Component: Notifications and Alerts → Themes
Flags: needinfo?(mstriemer)
Flags: needinfo?(gijskruitbosch+bugs)
Keywords: access
OS: Unspecified → All
Priority: -- → P1
Hardware: Desktop → All
Summary: High Contrast mode will not affect Modals on Mac and Ubuntu → High Contrast mode does not affect Proton modals and notification bars due to use of in-content/common.css
Whiteboard: [proton-modals] → [proton-modals][proton-infobars]

(In reply to Dão Gottwald [::dao] from comment #1)

This affects all platforms

Rares, can you clarify? Based on the conversation on slack and comment #0, my impression was that you didn't see this on Windows.

and is due to the use of in-content/common.css in chrome. Notification bars are affected too. In content documents, high contrast automatically overrides colors, but not in chrome.

This does have to do with the use of chrome vs content docshells, but which stylesheet we use to assign the styles doesn't really matter...

(In reply to Dão Gottwald [::dao] from comment #1)

mstriemer or Gijs, is there a plan for addressing this?

Yes, using the forced-colors media query to show borders and use system colours in that case.

Basic high contrast support is kind of a must.

It's up to product to prioritize this.

Flags: needinfo?(rares.doghi)
Flags: needinfo?(mstriemer)
Flags: needinfo?(gijskruitbosch+bugs)
Priority: P1 → --
Summary: High Contrast mode does not affect Proton modals and notification bars due to use of in-content/common.css → High Contrast mode does not affect Proton modals and notification bars due to the use of hardcoded non-keyword colours in chrome docshells

We probably want to iterate on this, just like HCM support in general isn't really
"finished", and we have better options now that we have better media query support
for it, but this gets us pretty similar outcomes to the pre-proton state, and we
should be able to build on that going forward.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED

(In reply to :Gijs (he/him) from comment #2)

and is due to the use of in-content/common.css in chrome. Notification bars are affected too. In content documents, high contrast automatically overrides colors, but not in chrome.

This does have to do with the use of chrome vs content docshells, but which stylesheet we use to assign the styles doesn't really matter...

In-content stylesheets have been created with the intention that they're used in content docshells where they can take advantage of said behavior.

Basic high contrast support is kind of a must.

It's up to product to prioritize this.

We, Mozilla, have agreed on a bunch of core principles that usually aren't up for debate. They include accessibility and high contrast support is an essential part of this. So we need to assume a high priority until we hear otherwise. I don't want to play edit wars but as the triage owner I consider this highest priority.

On Windows the High Contrast option is a lot more different than Mac or Ubuntu, it wouldnt just create a more visible border around the items but it would change everything.
This affects windows as well but in a different way I thought that maybe Bug 1701691 would be the one to fix it.
If not we can add a new issue if needed. Ill add a screenshot with the High Contrast turned on, because the modal will keep its own design.

Please let me know if we should log a separate issue for this High Contrast Theme from Windows.

Flags: needinfo?(rares.doghi) → needinfo?(gijskruitbosch+bugs)
Attached image High Contrast Windows.png (deleted) —
Attached image HighContrast_Update_restart_panel.png (deleted) —

I think this is how the modals should probably look like with High Contrast on Windows.

(In reply to Rares Doghi from comment #5)

On Windows the High Contrast option is a lot more different than Mac or Ubuntu, it wouldnt just create a more visible border around the items but it would change everything.
This affects windows as well but in a different way I thought that maybe Bug 1701691 would be the one to fix it.
If not we can add a new issue if needed. Ill add a screenshot with the High Contrast turned on, because the modal will keep its own design.

Please let me know if we should log a separate issue for this High Contrast Theme from Windows.

No, we can deal with it in this bug. Thank you for clarifying!

Flags: needinfo?(gijskruitbosch+bugs)
Depends on: 1705776
No longer depends on: 1705776
Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/17e9b05e998c add initial high contrast support for modals and notification bars, r=jaws
Whiteboard: [proton-modals][proton-infobars] → [proton-modals][proton-infobars] [access-s2]
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

Hi Gijs, this issue is indeed fixed for all platforms, Windows, Mac and Ubuntu the only problem is that none of the buttons on the modals react to Hover or Button press, there is no animation at all for any of the buttons.

Without proton, the old design used to change color on hover as well as Button press. Please let me know if I should log a separate issue for it or if we should reopen this one.

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Rares Doghi from comment #11)

Hi Gijs, this issue is indeed fixed for all platforms, Windows, Mac and Ubuntu the only problem is that none of the buttons on the modals react to Hover or Button press, there is no animation at all for any of the buttons.

Without proton, the old design used to change color on hover as well as Button press. Please let me know if I should log a separate issue for it or if we should reopen this one.

Please file a separate bug.

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(rares.doghi)

This issue is verified as fixed in our latest Nightly build 89.0a1 (2021-04-19), I will update the flags accordingly, and I filed Bug 1706155 as a separate issue.

Status: RESOLVED → VERIFIED
Flags: needinfo?(rares.doghi)
Regressions: 1711580
Regressions: 1713133
Accessibility Severity: --- → s2
Whiteboard: [proton-modals][proton-infobars] [access-s2] → [proton-modals][proton-infobars]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: