Open Bug 1476524 Opened 3 years ago Updated 5 months ago

Address bar text selection colors are reversed in Dark theme

Categories

(Firefox :: Theme, defect, P5)

63 Branch
defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix

People

(Reporter: nachtigall, Unassigned)

References

Details

(Keywords: regression)

Attachments

(8 files)

Attached image awesomebar_before.png
mozregression says:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e01bc035fe389c36fcf95426c75a754b028f3581&tochange=b3b2ac62bbe0c726eb47ee5d2ce89ce332f82791

which is Bug 1475509

AR (what it looks like now in Nightly with Dark Theme, both on Windows and Linux):
awesomebar_before.png

I think the white background is too much into the eyes. Is this deliberately done?

Also when double clicking (doing a selection) in address bar, then it's also white.


ER (what it looked before):
awesomebar_after.png
Attached image awesomebar_after.png
Blocks: 1475509
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression
Summary: Regression: Highlight background of autocompletion is white not blue in address bar → Highlight background of autocompletion is white not blue in address bar
Bug 1475509 was about improving the theme for Mac OSX Mojave, I don't think it should have impacted Windows and Linux themes.

Tim it seems your patch changed the behaviour on other platforms, could you have a look please? Thanks
Flags: needinfo?(ntim.bugs)
Dão, what do you think should be done here ?
Flags: needinfo?(ntim.bugs) → needinfo?(dao+bmo)
fwiw, here's what it currently looks in Ubuntu. (I use windows and ubuntu and imho on both it regressed, cannot say anything about macOS)
(In reply to Tim Nguyen :ntim from comment #3)
> Dão, what do you think should be done here ?

Not sure. Back out your patch? Get UX input? FWIW, I'm pretty sure Gecko intentionally flips these colors on dark backgrounds to increase contrast.
Flags: needinfo?(dao+bmo)
Hi Amy,

In bug 1475509, we removed the custom background/text color for selections to match the native highlight color, which made the highlight look like this on Windows/Linux.

How should the highlight look on the dark theme ?
Flags: needinfo?(amlee)
(In reply to Tim Nguyen :ntim from comment #6)
> Hi Amy,
> 
> In bug 1475509, we removed the custom background/text color for selections
> to match the native highlight color, which made the highlight look like this
> on Windows/Linux.
> 
> How should the highlight look on the dark theme ?

Hi, 

The highlight colour for text should match the highlight colour around the search box. "awesomebar_before.png" is correct. This colour rule should be applied to the Ubuntu version :-)
Flags: needinfo?(amlee)
Priority: -- → P5
Summary: Highlight background of autocompletion is white not blue in address bar → Address bar text selection colors are reversed in Dark theme
P5, removing release tracking flag.
63 is affected nevertheless.
Attachment #8996687 - Flags: review?(dao+bmo)
Comment on attachment 8996687 [details]
Bug 1476524 - Fix selection colors on dark theme.

https://reviewboard.mozilla.org/r/260764/#review268422

It's not quite clear to me that we should do this for all dark themes. Like I said Gecko intentionally adjusts the selection colors to increase contrast.

Have you figured out why this isn't working on Mac?
Attachment #8996687 - Flags: review?(dao+bmo)
Assignee: ntim.bugs → nobody
Bug 1475509 causes these regressions on Windows and Linux and as pointed out in Comment 10 also MacOS. These regressions are very noticable because they affect the address bar highlighting. Due to autocompletion and auto-selection of the address bar I notice this bug like a dozen times during a normal 1h browsing session. When I regressed I almost immediately "eye-catched" this bug, the wrong selection colors make it hard to read and really look wrong.

As it looks all the NIs said they "do not know", Tim has unassigned. What now? 

Could Bug 1475509 be backed-out at least until it's known on how to advance here? Looks like it causes more harm to keep it in at the moment imho.
Flags: needinfo?(dao+bmo)
Florens, since the macOS issue affects web content independently from bug 1475509, can you please file a separate bug on that?
Flags: needinfo?(dao+bmo)
Duplicate of this bug: 1486204
Blocks: 1486204
No longer blocks: 1486204
See Also: → 1486204
Depends on: 1486204
(In reply to Tom Schuster [:evilpie] from comment #26)
> This is pretty major regression, can this be addressed?

I'm fixing macOS in bug 1486204.

We use EnsureSufficientContrast [0] on Windows (attachment 8992879 [details])/Linux (attachment 8993066 [details]), which give the colors with the most contrast, but also not very eye-pleasing results.

I think it'd be reasonable to match Chrome or Edge behaviour for dark web content, or only match their behaviour for the default theme, and keep the old Firefox behaviour for high-contrast themes, not sure...

In any case, I don't have time to fix Win/Linux, but [0] should be a good starting point to change.

[0]: https://searchfox.org/mozilla-central/rev/d5fc6f3d4746279a7c6fd4f7a98b1bc5d05d6b01/layout/generic/nsTextFrame.cpp#3797
It's not clear to me that anything needs fixing on Windows and Linux, since the current behavior is intended by Gecko. We may want to change this behavior, but this doesn't seem like a pressing issue.
Flags: needinfo?(dao+bmo)
Updating tracking flags as we get closer to the 64 release, fix-optional on 65 as this is a P5.
Duplicate of this bug: 1569693

I'm getting an improved result on macOS 10.15 with Firefox 73 and 74 (Nightly).

The text selection color (for both chrome and content) is correctly inherited from system settings and seems to be applied with a partial opacity which gives good results on both light and dark backgrounds. (Don't know if it's just opacity or if there's some color math going on.)

For macOS, I'd consider this fixed.

I believe the macOS version of this bug is this https://bugzilla.mozilla.org/show_bug.cgi?id=1486204

Interesting, after seeing Comment 35 by :fvsch I tested again on Ubuntu 19.10: There the issue is also fixed. That is, the background color is Ubuntu's organge (like the input border), so similar to how it's now on MacOS. Sorry, I have no screenshot at the moment.

Testing on Windows 10 it is however still the white background color, see attachment.

OS: Unspecified → Windows
Summary: Address bar text selection colors are reversed in Dark theme → Windows: Address bar text selection colors are reversed in Dark theme

(In reply to Jens from comment #37)

I tested again on Ubuntu 19.10: There the issue is also fixed. That is, the background color is Ubuntu's orange

That is most likely because you are using a dark GTK theme with Firefox Default theme, if you switch to Firefox Dark theme (the title of this bug) you should see the same as in Windows.

OS: Windows → Unspecified
Summary: Windows: Address bar text selection colors are reversed in Dark theme → Address bar text selection colors are reversed in Dark theme

Kestrel, you are right. My Gnome theme was set to Yaru-dark. With Yaru (light) the bug is still present in Ubuntu too.

You need to log in before you can comment on or make changes to this bug.