Description

A user reports that TBB does not follow the current Windows theme. The user had set the Windows theme to be high contract black, which should equal a black background on input fields, buttons, and lists, with white text. However, the user is seeing a black background with black text.

Attached are two images; one showing normal Firefox the way it should look, the other showing TBB.

Child Tickets

Attachments (3)

Here is the proposed fix. The patch is for an ESR17 Firefox tree to which 0024-Do-not-expose-system-colors-to-CSS-or-canvas.patch has already been applied. If this looks good, we will produce a new, combined 0024- patch..

This is most likely a result of the patch for #6786. It turns out using/exposing system theme colors to the content window is a fingerprinting vector: the system theme colors can be queried by the content CSS and JS and recorded.

However, it is odd that the background is still set to black in those attachments. It was my understanding that we set these colors to a fixed map, so the system theme should have no effect on the content window at all.

Do we know if the user *also* mucked around with their Tor Browser Content preferences for Font and Colors, in addition to changing the Windows System Theme?

Adding Pearl Crescent to Cc, since they did the implementation of that patch.

We can reproduce this problem and we will investigate. Apparently, some special things happen in the browser with respect to CSS background images, background colors, etc., when the high contrast theme is enabled (high contrast is an accessibility thing).

OK, this is kind of messy. Through use of the debugger and reading the Firefox code, we discovered that in certain cases the substitute colors that we introduced to fix #6786 are not used. Instead, OS calls are used to draw the background for widgets (e.g., for an HTML input field). This happens with the classic themes on Windows and when the Windows accessibility control panel is used to enable "High Contrast Black." These colors are hidden from web apps (CSS computed styles continue to return our substitute colors).

The problem is, in some cases a system/native background is used (e.g., black) with a substitute foreground color (i.e., black). Hence, black on black. Our approach to fixing this is to use the system/native foreground color in this situation. We will post a patch soon.

Note that on Mac OS, "White on black" display is done in a different way that avoids this problem (I think the OS inverts colors during rendering). I am not sure about Linux, but our fix will apply for all platforms.

Here is the proposed fix. The patch is for an ESR17 Firefox tree to which 0024-Do-not-expose-system-colors-to-CSS-or-canvas.patch has already been applied. If this looks good, we will produce a new, combined 0024- patch..

Right now, testing this myself blocks on me having a Windows build machine that works. That's on the TODO list, but if you can verify the behavior on your machine with those test cases doesn't degrade or change regardless of your system theme, I'll go ahead and merge this.

The main question I have with this patch is the result it has on what colors Javascript perceives from getComputedStyles() and the test page from #6786 (which I think you've archived + updated).