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)
Tracking
()
People
(Reporter: rdoghi, Assigned: Gijs)
References
(Blocks 4 open bugs)
Details
(Keywords: access, Whiteboard: [proton-modals][proton-infobars] )
Attachments
(4 files)
[Affected platforms]:
Platforms: Mac OSX, Ubuntu 20.04
[Steps to reproduce]
- Enable High Contrast mode on Mac OSX from the accessibility > display options
- Start Firefox with the following prefs enabled: browser.proton.enabled = true / prompts.windowPromptSubDialog = true / prompts.contentPromptSubDialog = true / browser.proton.modals.enabled = true
- 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
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
(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.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
(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.
Reporter | ||
Comment 5•4 years ago
|
||
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.
Reporter | ||
Comment 6•4 years ago
|
||
Reporter | ||
Comment 7•4 years ago
|
||
I think this is how the modals should probably look like with High Contrast on Windows.
Assignee | ||
Comment 8•4 years ago
|
||
(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!
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
|
||
bugherder |
Reporter | ||
Comment 11•4 years ago
|
||
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.
Assignee | ||
Comment 12•4 years ago
|
||
(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.
Reporter | ||
Comment 13•4 years ago
|
||
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.
Updated•1 years ago
|
Description
•