Open Bug 1805640 Opened 3 years ago Updated 3 years ago

[HCM] Firefox does not account for the HCM color scheme, basing its extension icon selection on the currently applied theme, causing visibility issues.

Categories

(WebExtensions :: General, defect, P4)

Firefox 110
defect

Tracking

(firefox109 affected, firefox110 affected)

Tracking Status
firefox109 --- affected
firefox110 --- affected

People

(Reporter: acornestean, Unassigned)

References

Details

Attachments

(2 files)

Attached image Windows HCM.png

Affected versions:

  • Beta (109.0b2/20221213185929)
  • Nightly (110.0a1/20221213165020)

Affected OSes: Windows 10, Ubuntu 16.04 LTS

Description:
Firefox does not account for the HCM color scheme and selects extension icons based on the currently applied theme, potentially causing visibility issues.

Note: Tested macOS as well and no visibility issues were observed with this OS when using the default , Light or Dark theme.

As such with HCM enabled the following occurs:

WINDOWS
=Default system theme=

  • some black extension buttons (Tree Style Tab, Tab Stash, Undo Close Tab, for example) are not very visible in the UEB (unified extension button) panel until hovering over them.
  • when pinned to the toolbar, Tree Style Tab’s button is dark colored and is not very visible, unlike the other 2 mentioned above which turn a light gray.
    Firefox chooses the Tree Style Tab button based on the current theme which is intrinsically light and thus selects the darker extension icon.
    = Dark theme=
  • extension buttons are visible in both the UEB panel and when pinned to the toolbar
    =Light theme=
  • extension buttons are visible in the UEB panel, except Tab Stash, which is visible only when hovered over.
  • when pinned to the toolbar, all extension buttons appear to be fairly visible

LINUX
=Default system theme=

  • extension buttons are visible in the UEB, except when hovered over.
  • when pinned to the toolbar, the buttons are visible
    =Dark theme=
  • extension buttons are visible in both the UEB panel and when pinned to the toolbar
    =Light theme=
  • extension buttons are visible in the UEB, except when hovered over.
  • when pinned to the toolbar, the buttons are visible

For more details, see the attached screenshots.

Steps to reproduce:
Preconditions:

  1. High contrast mode is enabled in the OS
  2. Install several extensions with darker/black buttons (Tree Style Tab, Tab Stash, Undo Close Tab, for example)
  3. Open the UEB panel and observe the extension buttons. Some visibility issues occur when hovering on/off the extension buttons.
  4. Pin the extension buttons to the toolbar and observe them. Some visibility issues occur due to how Firefox handles HCM.

Actual:
Visibility issues occur due to how Firefox handles HCM.

Expected:
Extension buttons in the UEB and on the toolbar should be visible at all times when HCM is enabled.

Attached image Linux HCM.png
See Also: → 1795723

The severity field is not set for this bug.
:robwu, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(rob)

:ayeddi what do you think about this bug? How do we deal with icons when users use HCM elsewhere? I have the feeling that icons might be less important are most of them don't carry any specific meaning (though we could have badges but those should be more visible).

Severity: -- → S3
Flags: needinfo?(rob) → needinfo?(ayeddi)
Priority: -- → P4
See Also: → 1798088

(In reply to William Durand [:willdurand] from comment #3)

:ayeddi what do you think about this bug? How do we deal with icons when users use HCM elsewhere? I have the feeling that icons might be less important are most of them don't carry any specific meaning (though we could have badges but those should be more visible).

Your feeling is correct: HCM is not expected to handle images, because it is aimed to communicate semantics of the content and it is a very difficult task for images. The goal is to make the text and active UI readable and more consistent visually for users to perceive and operate it. And in this case the textual information for each addon is respecting the HCM, while icons play a supportive role. They are adjacent to the redundant textual label and thus they are also not covered by the WCAG 2.1 Success Criterion 1.4.11 Non-text contrast.

That's being said, with dark and light sets of icons provided by the content authors nowadays we probably can manage it while on HCM, but we would also need to respect the dark or light themes of the HCM that a user activated, plus each HCM allows for individual customization. If we can change the color of these icons to, say ButtonText against ButtonFace background to provide a high contrast color pair and preserve the semantics, this would follow the user's settings and provide more delightful experience for sure. But I am not aware how much control of the icons for addons do we have.

Flags: needinfo?(ayeddi)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: