Closed Bug 1348574 Opened 3 years ago Closed 3 years ago

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

Categories

(Firefox :: Theme, defect)

48 Branch
All
Windows
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 55
Tracking Status
firefox52 --- wontfix
firefox-esr52 --- wontfix
firefox53 --- verified
firefox54 --- verified
firefox55 --- verified

People

(Reporter: dao, Assigned: dao)

References

(Blocks 1 open bug)

Details

(Keywords: access, regression)

Attachments

(1 file)

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

https://reviewboard.mozilla.org/r/121650/#review124526
Attachment #8848764 - Flags: review?(mak77) → review+
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2b00bde40255
Clean up .autocomplete-richlistitem styling. r=mak
https://hg.mozilla.org/mozilla-central/rev/2b00bde40255
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Flags: qe-verify+
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]: /
Attachment #8848764 - Flags: approval-mozilla-beta?
Attachment #8848764 - Flags: approval-mozilla-aurora?
Blocks: 1181078
Keywords: regression
Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(brindusa.tot)
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?
Flags: needinfo?(brindusa.tot) → needinfo?(dao+bmo)
(In reply to roxana.leitan@softvision.ro 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!
Flags: needinfo?(dao+bmo) → needinfo?(roxana.leitan)
Summary: Selected awesomebar item uses the wrong text color with High Contrast black theme → Selected awesomebar item uses the wrong text color with High Contrast black theme (selected item text lacks contrast)
Version: unspecified → 48 Branch
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+.
Attachment #8848764 - Flags: approval-mozilla-beta?
Attachment #8848764 - Flags: approval-mozilla-beta+
Attachment #8848764 - Flags: approval-mozilla-aurora?
Attachment #8848764 - Flags: approval-mozilla-aurora+
Hi,

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

For Windows 7 I filed bug 1351244.
Status: RESOLVED → VERIFIED
Flags: needinfo?(roxana.leitan)
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.
Is this severe enough to warrant backporting to ESR52 as well or should it just ride the 53 train?
Flags: needinfo?(dao+bmo)
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.
Flags: needinfo?(dao+bmo)
You need to log in before you can comment on or make changes to this bug.