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

Status: VERIFIED FIXED

(Toolkit :: Themes, defect)

Description

[Rares Doghi, Desktop QA]

Attachment: High Contrast.jpg

[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

Comment 1

[Dão Gottwald [:dao]]

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.

Comment 2

[:Gijs (out for now; he/him)]

(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.

Comment 3

[:Gijs (out for now; he/him)]

Attachment: Bug 1705133 - add initial high contrast support for modals and notification bars, r?dao,jaws,mstriemer

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.

Comment 4

[Dão Gottwald [:dao]]

(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.

Comment 5

[Rares Doghi, Desktop QA]

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.

Comment 6

[Rares Doghi, Desktop QA]

Attachment: High Contrast Windows.png

Comment 7

[Rares Doghi, Desktop QA]

Attachment: HighContrast_Update_restart_panel.png

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

Comment 8

[:Gijs (out for now; he/him)]

(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!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/17e9b05e998c
add initial high contrast support for modals and notification bars, r=jaws

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/17e9b05e998c

Comment 11

[Rares Doghi, Desktop QA]

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.

Comment 12

[:Gijs (out for now; he/him)]

(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.

Comment 13

[Rares Doghi, Desktop QA]

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.