Found in

• 104.0b6

Affected versions

• 104.0b6
• 105.0a1 (2022-08-04)
• 103.0.1

Affected platforms

• Windows 11

Steps to reproduce

1. Activate OS Dark Mode
2. Launch FF.
3. CTRL+P and select color mode(color printer needed)

Expected result

• Highlight selector moves between Color/Back and White at the same time as the mouse pointer.

Actual result

• Highlight selector moves between Color/Back and White opposite of the mouse pointer.

Regression range

2022-08-05T14:57:37.613000: INFO : Narrowed integration regression window from [5907e9a7, d917b43d] (4 builds) to [077bfa71, d917b43d] (2 builds) (~1 steps left)
2022-08-05T14:57:37.621000: DEBUG : Starting merge handling...
2022-08-05T14:57:37.621000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=d917b43d44584cd7e9a1243b95287361a8625b38&full=1
2022-08-05T14:57:40.472000: DEBUG : Found commit message:
Bug 1744009 - Accessibility fixes for new combobox layout code. r=eeejay

• It would seem that the culprit is 1744009
• Pushlog_url

Additional notes

• A color printer is needed in order to verify/reproduce this issue.
• This issue DOES NOT occur in macOS 11/12, Ubuntu 22 or Windows 10.
• This issue only occurs with the OS Dark Mode activated.

Assume default styles fit well enough. This prevents confusing colors from
applying, since in the described case we pick the hovered select background,
but then override the options to use the unhovered background...

With short selects (like the ones that have only two options), that may cause
the wrong impression. A bit tricky!

This repros for me on win10, for what is worth.

I can repro on win 10 with dark mode as well, for the record.

https://hg.mozilla.org/mozilla-central/rev/158b3d5240b5

This seems like it'd be a pretty annoying issue to hit and the S2 seems justified. Given that, I think we should probably consider taking this on ESR102 also. That said, it has conflicts that I'm not sure how trivial they'd be to rebase through?

I managed to reproduce this issue on Firefox 104.0(build ID: 20220818191623) on Windows 11, using the STR from the Description. Verified as fixed on Firefox 105.0b5(build ID: 20220830185924) and Nightly 106.0a1(build ID: 20220831215447) on Windows 11 and Windows 10.

ESR Approval Request Comment
[Feature/Bug causing the regression]: N/A
[User impact if declined]: comment 0
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: comment 0
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not risky
[Why is the change risky/not risky?]: Relatively straight-forward patch.
[String changes made/needed]: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment on attachment 9292603 [details]
ESR102 patch.

Approved for 102.3esr.

https://hg.mozilla.org/releases/mozilla-esr102/rev/11f8c4fa6677

Hello,
Whilst testing the fix on 102.3.0esr(build ID: 20220902190600), I noticed that if the user insists enough with the selector, the issue reproduces again. I was wondering if I should re-open the bug or if this would be the expected behaviour of the fix?
I'm leaving 2 recording with the behaviour before/after the fix.

• before
• after

Thank you.

The behavior after the fix seems correct, not sure I'm missing something?

Emilio was kind enough to clarify on slack that the behaviour seen in the second video seems like a minor lag issue. Thank you, Emilio!
I confirm this fix is verified on Firefox 102.3.0esr on Windows 10 and Windows 11.