1553754 - "Override the colors specified by the page with your selections above" doesn't work anymore, if, privacy.resistFingerprinting = enabled.

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[anon]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

Only updated to v67.

Actual results:

"Override the colors specified by the page with your selections above" doesn't work anymore.

Expected results:

Up to v66, under Fonts & Colors, when you set this option "Override the colors specified by the page with your selections above" to "only with High Contrast themes", Firefox would adapt to the colors of Windows High Contrast theme and turn the white background of newtab page and website colors to black.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
20190516215225

Works for me on this page. Setting platform to Windows 7.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Is there any chance you can find a regression range for this using mozregression? I don't have a windows build handy, but I'll try to reproduce it by hacking up the settings to return that I have accessibility enabled.

Comment 3

[anon]

(In reply to Gingerbread Man from comment #1)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
20190516215225

Works for me on this page. Setting platform to Windows 7.

It happens in Windows 10 1803 64bit, can not comment on Windows 7. Firefox v66 64bit release works as expected, v67 not.

Comment 4

[anon]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Is there any chance you can find a regression range for this using mozregression? I don't have a windows build handy, but I'll try to reproduce it by hacking up the settings to return that I have accessibility enabled.

I will try to get that. but I am 100% sure it happens after v67 64bit release. it worked as expected up to and including v66 64bit release.

OS: Windows 10 1803 64bit

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Ok, so I took a closer look, and I'm not sure how this could've ever worked for you.

I'm the most likely culprit for this since I moved around all this code in bug 1530193. We do always disable preference colors (foreground / background) when in high contrast, but keep the link colors:

https://searchfox.org/mozilla-central/rev/662de518b1686c4769320d6b8825ce4864c4eda0/layout/style/PreferenceSheet.cpp#60

But that change looks idempotent to me, we always disabled those colors with high-contrast before as well (useAccessibilityTheme is effectively "is high contrast enabled"):

https://searchfox.org/mozilla-central/rev/8e84ea1e71afeb2258643c45646b45067aed6716/layout/base/nsPresContext.cpp#389

So maybe something changed in how we detect high contrast? I ran mozregression --launch 66 --pref ui.useAccessibilityTheme:1 and I see the same behavior that 67 / current Nightly when I change all those colors and keep the "only with High Contrast themes".

Or maybe I understood your setup wrong. If you could run mozregression it'd be great.

Eitan, is this a behavior change you can see as well? (Asking since you added the probe for high contrast).

Comment 6

[anon]

I did some more comparisons with clean v66 & v67 profiles, and it turns out this problems occurs after you enable "privacy.resistFingerprinting" in v67.
and after you disable this setting, website colors & newtab background behave as expected and adapt to Windows High Contrast theme, except the background colors of about:config & about:preferences, which remain white even after you disable "privacy.resistFingerprinting", until you restart Firefox.

Comment 7

[Eitan Isaacson [:eeejay]]

Was about to do some bisecting, but there you have it. Looks like a regression in our fingerprint resistance.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

This looks like an intended effect from bug 1485266, but over to Gary to confirm.

Comment 9

[Gary Chen [:xeonchen]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

This looks like an intended effect from bug 1485266, but over to Gary to confirm.

It seems to me that is a reasonable behavior at first glance.
Tim, could you help me to confirm this?

Comment 10

[Tim Huang[:timhuang]]

(In reply to Gary Chen [:xeonchen] (PTO until Jun. 11) from comment #9)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

This looks like an intended effect from bug 1485266, but over to Gary to confirm.

It seems to me that is a reasonable behavior at first glance.
Tim, could you help me to confirm this?

Yes, this is intended behavior. In which case, the fingerprinter wouldn't be able to inspect the system native color through CSS. It was using a separated pref "ui.use_standins_for_native_colors" before, but we consolidate this pref into "privacy.resistFingerprinting" after 67. That's why this only happens after 67 even though we add this intended behavior a while ago.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:mats, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

I think this is working as intended, per comment 10. But reporter, if you disagree with the behavior and want more customizability, maybe it's worth filing a different bug as a feature request so that the Tor and privacy people can consider tweaking the behavior.