1348574 - Selected awesomebar item uses the wrong text color with High Contrast black theme (selected item text lacks contrast)

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Comment 1

[Dão Gottwald [::dao]]

Attachment: Bug 1348574 - Clean up .autocomplete-richlistitem styling.

Review commit: https://reviewboard.mozilla.org/r/121650/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/121650/

Comment 2

[Marco Bonardo [::mak]]

Comment on attachment 8848764 [details]
Bug 1348574 - Clean up .autocomplete-richlistitem styling.

https://reviewboard.mozilla.org/r/121650/#review124526

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2b00bde40255
Clean up .autocomplete-richlistitem styling. r=mak

Comment 4

[Wes Kocher (:KWierso)]

https://hg.mozilla.org/mozilla-central/rev/2b00bde40255

Comment 5

[Dão Gottwald [::dao]]

Comment on attachment 8848764 [details]
Bug 1348574 - Clean up .autocomplete-richlistitem styling.

Approval Request Comment
[Feature/Bug causing the regression]: probably bug 1181078
[User impact if declined]: selected awesomebar result lacks sufficient contrast in high contrast mode on Windows
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: no
[Needs manual test from QE? If yes, steps to reproduce]: STR are to enable high contrast mode and use the awesomebar
[List of other uplifts needed for the feature/fix]: /
[Is the change risky?]: hardly
[Why is the change risky/not risky?]: just consolidating a bunch of CSS rules, pretty straightforward
[String changes made/needed]: /

Comment 6

[Gerry Chang [:gchang]]

Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!

Comment 7

[roxleitan]

Tested this issue on Nightly 55.0a1 (2017-03-21) on Windows 10 x64 and Windows 7 x64 using High Contrast Black Theme. Text from Awesomebar has white color even when is highlighted(selected).

Tested on latest Nighly 55.0a1 (2017-03-27). On Windows 10 x64, text changes the color from white to black when is selected and on Windows 7 x64 the text color is the same (white) in selected and non-selected mode.

Is this expected for Windows 7? Should I verify something else for this bug?

Comment 8

[Dão Gottwald [::dao]]

(In reply to [e-mail] from comment #7)
> Tested this issue on Nightly 55.0a1 (2017-03-21) on Windows 10 x64 and
> Windows 7 x64 using High Contrast Black Theme. Text from Awesomebar has
> white color even when is highlighted(selected).
> 
> Tested on latest Nighly 55.0a1 (2017-03-27). On Windows 10 x64, text changes
> the color from white to black when is selected and on Windows 7 x64 the text
> color is the same (white) in selected and non-selected mode.
> 
> Is this expected for Windows 7? Should I verify something else for this bug?

In other words, the bug is still present on Windows 7? No, this is not expected. Could you please file a followup bug and attach a screenshot? Thanks!

Comment 9

[Gerry Chang [:gchang]]

Comment on attachment 8848764 [details]
Bug 1348574 - Clean up .autocomplete-richlistitem styling.

Fix a regression related to selected awesomebar in high contrast mode on Windows and was verified. Aurora54+ & Beta53+.

Comment 10

[roxleitan]

Hi,

Based on comment 7 and comment 8 I will mark this bug as Verified fixed.

For Windows 7 I filed bug 1351244.

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3d505d4ed9fa

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1411f6a2c163

Comment 13

[Timea Zsoldos [:zstimi/tzsoldos], Desktop Release QA]

I have reproduced this issue using Firefox 52.0.1 (ID=20170327081421) on Win 8.1 x64.
I can confirm this issue is fixed, I verified using Firefox 53.0b8, 54.0a2 on Win 8.1 x64. For Windows 7 there is a new bug 1351244.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Is this severe enough to warrant backporting to ESR52 as well or should it just ride the 53 train?

Comment 15

[Dão Gottwald [::dao]]

Given that this probably existed since Firefox 48 and we didn't get bugs filed about it, I'd say it's not severe enough to backport to ESR52.