Closed Bug 1785736 Opened 4 months ago Closed 2 months ago

Progress Bar in Firefox View lacks contrast in Windows/macOS high contrast mode

Categories

(Firefox :: Firefox View, defect, P2)

defect

Tracking

()

VERIFIED FIXED
106 Branch
Tracking Status
firefox106 --- verified
firefox107 --- verified

People

(Reporter: rfambro, Assigned: cmkm)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [fidefe-2022-mr1-firefox-view] )

Attachments

(5 files, 1 obsolete file)

Progress bars are not styled with sufficient contrast. They do not use increased contrast in Mac or Windows HCM.

Severity: -- → S4
Priority: -- → P3
Whiteboard: [fidefe-2022-mr1-firefox-view]
Blocks: firefox-view
Keywords: access
Summary: Progress Bar Contrast → Progress Bar in Firefox View lacks contrast in Windows/macOS high contrast mode
Priority: P3 → P2

The a11y team told us we should use SelectedItem and SelectedItemText for the background and foreground colours, respectively. The progress state (using the pseudo element) and the border should use the foreground colour.

Cieara has offered to take this on!

Assignee: nobody → cmeador
Status: NEW → ASSIGNED
Pushed by cmeador@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ef63c5cae6ba
Progress bar HCM palette changes r=Gijs
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch
Attached image current appearance

Are the progress bar colors reversed? Or should the border be SelectedItem instead of SelectedItemText?

Attached image colors swapped

With the colors reversed

Attached image just the border swapped

With just the border set to SelectedItem

See Also: → 1790660

I originally tested this on Windows where it looked fine. I assume the screenshot is from macOS? IIRC these were the colours suggested by the a11y team, and it would seem to make sense to do it the way around it currently is (SelectedItemText for the foreground ergo border + progress, SelectedItem for the background) but I agree that it doesn't look great on macOS. Morgan, did I miss something? Do we just want to / need to do a per-platform thing? Or is the use of foreground/background here just confusing? :-(

Flags: needinfo?(mreschenberg)

Ah yeah we'll need to do a per-platform thing here, sorry about that I think we tested with just windows HCM when we gave that advice.

We can put the current, ok-on-windows styling inside of a forced-colors:active media query, and then the mac stuff can go in a prefers-contrast:more and (not forced-colors) block.

Flags: needinfo?(mreschenberg)

Hello,

I have verified this issue on macOS 12, Windows 11 and Ubuntu 22 on 106.0b4 and latest 107a1.

Unfortunately , the colours suggested by a11y team does not seem to be very good as it gives the impression that the progress bar is at 100%. Could they be reverted to the state they were before 2022-09-15? (as it stands, this bad visibility issue occurs for all OS's, not only for macOS)

Here is an attachment of the issue : image

Flags: needinfo?(cmeador)

This reverts commit f9073349e201d4b3f91a6bcfc02406b0bf84cd4f.

Hi Morgan and Gijs! I submitted a revert patch for this until I can submit another patch with the per-platform queries Morgan suggested. Please let me know if I should do this differently, thank you!

Flags: needinfo?(mreschenberg)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(cmeador)

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #10)

Hello,

I have verified this issue on macOS 12, Windows 11 and Ubuntu 22 on 106.0b4 and latest 107a1.

Unfortunately , the colours suggested by a11y team does not seem to be very good as it gives the impression that the progress bar is at 100%. Could they be reverted to the state they were before 2022-09-15? (as it stands, this bad visibility issue occurs for all OS's, not only for macOS)

Here is an attachment of the issue : image

I'm pretty confused at this point - what OS is this screenshot from, and how did you test high contrast mode? I'm surprised that the SelectedItemText colour is the same as the background colour here.

(In reply to Cieara Meador [:cmkm] from comment #12)

Hi Morgan and Gijs! I submitted a revert patch for this until I can submit another patch with the per-platform queries Morgan suggested. Please let me know if I should do this differently, thank you!

I think we should reopen this. I'm not sure if a revert is really our best option - it sounds (and looks on that screenshot) like if we used SelectedItemText as the background colour of the entire bar, but SelectedItem as the foreground (border) colour and filled-in-progress-bit background colour, the macOS bits would look OK and so would the screenshot that Vlad has provided (though unclear if that is also macOS?). It's semantically... odd... to do it that way around but if it reliably works (also on Windows?), it might be our best bet. I defer to Morgan as to what's happening here and if that is definitely for real our best option; It sounds like we're surprised by the results here, and I'm not sure why that is. It would probably be useful to have screenshots for the 4 main win10 HCM themes, and maybe macOS, of whatever path we end up taking here.

Status: RESOLVED → REOPENED
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(vlad.lucaci)
Resolution: FIXED → ---

Hello,

Here you can find screenshots of the issue for the following configurations:

  • macOS 12 (for macOS it is enough to only activate Increase Contrast to reproduce the issue, Invert Colours is not required)
  • Ubuntu 22
  • Windows 10 (HC Black, HC White, HC 1, HC 2)
  • Windows 11 (Night Sky, Aquatic, Dusk, Desert)

This issue occurs regardless of the OS's theme (Dark/Light).

Flags: needinfo?(vlad.lucaci)
Attachment #9296386 - Attachment is obsolete: true
Pushed by cmeador@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/36339a5e7c97
Invert Firefox View progress bar HCM palette r=Gijs

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #14)

Hello,

Here you can find screenshots of the issue for the following configurations:

  • macOS 12 (for macOS it is enough to only activate Increase Contrast to reproduce the issue, Invert Colours is not required)
  • Ubuntu 22
  • Windows 10 (HC Black, HC White, HC 1, HC 2)
  • Windows 11 (Night Sky, Aquatic, Dusk, Desert)

This issue occurs regardless of the OS's theme (Dark/Light).

Hi there! Just landed a patch inverting the colors, which looks good on the Windows 11 HCM themes as well as macOS Increased Contrast. Vlad, would you be able to confirm that this fixes Win10 and Ubuntu?

Flags: needinfo?(vlad.lucaci)

Hello,

Confirming that the patch inverting colors looks good as well on Windows 11, Windows 10, Ubuntu 22 and macOS 12.

Builds used to verifiy this issue from Treeherder:

  • 107.0a1(20220930040029) for macOS
  • 107.0a1(20220930062533) for Ubuntu22, Windows 11 and Windows 10
Flags: needinfo?(vlad.lucaci)

Comment on attachment 9296723 [details]
Bug 1785736 - Invert Firefox View progress bar HCM palette r?Gijs

Beta/Release Uplift Approval Request

  • User impact if declined: Progress bars on FxView are not readable in HCM
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See earlier comments.
  • List of other uplifts needed: N/A
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Straightforward CSS-only change that only affects HCM.
  • String changes made/needed: Nope
  • Is Android affected?: No
Attachment #9296723 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Status: REOPENED → RESOLVED
Closed: 3 months ago2 months ago
Resolution: --- → FIXED

Comment on attachment 9296723 [details]
Bug 1785736 - Invert Firefox View progress bar HCM palette r?Gijs

Approved for 106.0b7, thanks.

Attachment #9296723 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Confirming this issue as verified fixed on 107.0a1(20221002212226) and 106.0b7(20221002185807) using HCM of Win10, Win11, macOS 12 , Ubuntu 22.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(mreschenberg)
You need to log in before you can comment on or make changes to this bug.