User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20151228134903 Steps to reproduce: Installed Firefox 44 beta 4. Actual results: Firefox 44 beta 4 has a totally broken appearance under Linux/CentOS 6.7 i686: 1. When using the address bar, drop down list entries are NOT highlighted when you select them. 2. Text selection is totally black (including the address/web search bars). 3. Preferences button shows some garbage - a transparent block with broken fonts. 4. The address and the search bars have a strange black margin. Expected results: Nothing. Some relevant libraries: gtk2-2.24.23-6.el6.i686 gtk2-devel-2.24.23-6.el6.i686 gtk2-engines-2.18.4-5.el6.centos.i686 gtk-nodoka-engine-0.7.5-5.el6.i686 My GTK2 settings: $ cat /home/birdie/.gtkrc-2.0 include "/usr/share/themes/Nodoka/gtk-2.0/gtkrc" gtk-theme-name="Nodoka" style "user-font" { font_name="Tahoma 9" } widget_class "*" style "user-font" gtk-font-name="Tahoma 9"

OK, I've removed my gtk2 settings file and nothing has changed - Firefox is a as broken as it was. Firefox 43.0.3 has exactly zero problems here. I'm using the official Mozilla binaries from https://ftp.mozilla.org/pub/firefox/releases/

Everything is quite the same in safe mode. I know you're deprecating GTK2 support, but that doesn't mean you have to intentionally break it for God's sake.

This build is not using GTK3, though it is quite possible that one of the changes for the GTK3 port has accidentally broken something for the GTK2 port. It might also be a graphics change that has caused the problem.

Would you be able to see if you can find a regression range, please, using the builds at https://archive.mozilla.org/pub/firefox/tinderbox-builds/elm-linux/ e.g. https://archive.mozilla.org/pub/firefox/tinderbox-builds/elm-linux/1442884682/firefox-44.0a1.en-US.linux-i686.tar.bz2 I'm not able to reproduce any of these issues with Nodoka installed on amd64 Gentoo.

OK, I've found out what breaks Firefox locally, it's these 4 settings: user_pref("ui.textHighlightBackground", "#EF0FFF"); user_pref("ui.textHighlightForeground", "#FFFFFF"); user_pref("ui.textSelectBackgroundAttention", "#38d878"); user_pref("ui.use_native_colors", false); I've no idea how I got them and for some reasons Firefox 43.x and earlier don't care about them, but Firefox 44 totally breaks.

Thanks. That's helpful. Perhaps the effect of ui.use_native_colors may have changed with changes in bug 232227. What actually changed there looks quite different from its bug description. I don't know what other than the tor browser may have set these.

(In reply to Artem S. Tashkinov from comment #1) > Firefox 43.0.3 has exactly zero problems here. That was a GTK3 build I think, but I don't know why that would make a difference.

Firefox 44, which has just been released, also suffers from this bug. I know no one really needs another confirmation, but it's strange that an easily reproducible bug report gets exactly zero attention from developers.

Let me add some more points: 5. I set "Shockwave Flash" to "Ask to activate" in the Plugins tab of Add-ons Manager. And this is the screenshot when I choose to enable a Flash movie - transparent like 3.

6. Disabled menu items are not grayed. In this attachment at least Edit->Undo and Edit->Redo should be grayed, but they're not.

7. General <select> in webpages suffer the problem in 1. too 8. Tooltip of links is also totally black, similar to 2. With ui.use_native_colors set to true, everything is solved. I'm using the official Arch Linux package firefox 44.0-1. The building scripts can be found at [1]. [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/pkgbuild?h=packages/firefox

Gijs, I remember there were some changes to default colors in the preferences. Does that ring a bell for you?

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #12) > Gijs, I remember there were some changes to default colors in the > preferences. Does that ring a bell for you? We changed how we showed them in the colorpicker, but those color prefs are different prefs from the prefs mentioned in comment #5. I don't think it's related. (In reply to Artem S. Tashkinov from comment #5) > OK, I've found out what breaks Firefox locally, it's these 4 settings: > > user_pref("ui.textHighlightBackground", "#EF0FFF"); > user_pref("ui.textHighlightForeground", "#FFFFFF"); > user_pref("ui.textSelectBackgroundAttention", "#38d878"); > user_pref("ui.use_native_colors", false); > > I've no idea how I got them and for some reasons Firefox 43.x and earlier > don't care about them, but Firefox 44 totally breaks. Well, Firefox seems to be doing what you told it to do and not using native theme colors for some things. Before bug 232227 we ignored that pref, which was wrong. From the screenshots, it seems there might be some system colors which aren't implemented in the fallback system, and so we're falling back to transparent and/or black. But the fact that some borders are solid black and/or ugly I don't think is a bug.

Dave, can you take a look?

I tested FF 44.0 (Mozilla build) and 45 beta (our ESR candidate) on RHEL6.7 (don't have CentOS handy) and I don't see any of the reported problems. Clear profile, no local modifications.

(In reply to Martin Stránský from comment #15) > I tested FF 44.0 (Mozilla build) and 45 beta (our ESR candidate) on RHEL6.7 > (don't have CentOS handy) and I don't see any of the reported problems. > Clear profile, no local modifications. It presumably takes at least setting ui.use_native_colors to false to reproduce this, per earlier comments...

Looks like bug 1247886 is a dupe. I resolved that as INVALID since I couldn't find documentation on whether ui.use_native_color:false is supported. If that's incorrect then I'll dupe that bug over here but it has a reproducible case which I confirmed in a Windows 10 VM.

ui.use_native_color are fixed by Bug 232227 (at least on Windows) and also fixes Bug 1208372. Not sure how ui.use_native_color cooperates with "browser.display.use_system_colors" which seems to be useless now (or used only for two colors).

(In reply to Martin Stránský from comment #18) > ui.use_native_color are fixed by Bug 232227 (at least on Windows) and also > fixes Bug 1208372. Not sure how ui.use_native_color cooperates with > "browser.display.use_system_colors" which seems to be useless now (or used > only for two colors). This is conflating 4 different concepts: 1) what colors do we report for native CSS keywords on the web 2) what colors do we use to style Firefox 3) what colors do we use when a web author has not specified a color (default foreground/background colors) 4) do we override colors used by the web author with those defaults use_system_colors addresses (3) very specifically, and the colours are used in lieu of user-defined ones for the foreground/background. They can then be made to override author-specified colors (4) using browser.display.document_color_use . use_native_color now does both (1) and (2), but the naming does not make that clear, and it arguably really shouldn't be doing (2) to begin with. How can we get this addressed? How are tor browser people even living with a barely-functional thing such as in the screenshot here and in bug 1247886 ? It doesn't look like Dave is responding to needinfo, so I'm pinging Jeff instead.

Then at least "browser.display.use_system_colors" is confusing here when it changes web page properties only.

(In reply to Martin Stránský from comment #20) > Then at least "browser.display.use_system_colors" is confusing here when it > changes web page properties only. It applies to chrome too, but we specify colors for most things... All it does is decide whether or not we use the default foreground/background color prefs, or if we use the system theme instead.

> 2) what colors do we use to style Firefox There's a problem which is addressed by Bug 1158076. When ui.use_native_color is false, picked colors are used instead of the system ones and those colors are selected as black-on-white. But the background color is not drawn as color but as a system widgets which follow the system theme settings no matter how ui.use_native_color is set. For dark themes we get black text on black buttons then. A solutions may be to disable themed widgets in HTML when ui.use_native_color is false or use the light theme as it's in Bug 1158076.

Btw. I believe that a patch from Bug 1158076 can be greatly simplified by ui.use_standins_for_native_colors and/or ui.use_native_color. When dark theme is enabled we may set ui.use_standins_for_native_colors and only draw the background widgets in light theme. Karl, what do you think?

just to clarify, ui.use_native_colors assigns native theme colors to the named CSS colors (e.g. ButtonFace) and is a known browser fingerprinting vector. The ui.use_standins_for_native_colors is a patch from the Tor project that hard codes the native colors to Windows XP/7 colors to mask the OS from fingerprinters. use_native_colors should be pref'd on by default and use_standins_for_native_colors pref'd off. i'll take a look and see if i can repro the breakage with use_native_colors off.

(In reply to Dave Huseby [:huseby] from comment #24) > just to clarify, ui.use_native_colors assigns native theme colors to the > named CSS colors (e.g. ButtonFace) and is a known browser fingerprinting > vector. The ui.use_standins_for_native_colors is a patch from the Tor > project that hard codes the native colors to Windows XP/7 colors to mask the > OS from fingerprinters. Right, and this all makes sense for content documents, but less so for chrome ones, and even if we do want it to apply to chrome ones, we should ensure popups and so on don't become transparent/unusable. > use_native_colors should be pref'd on by default and > use_standins_for_native_colors pref'd off. i'll take a look and see if i > can repro the breakage with use_native_colors off. OK, leaving needinfo for this.

(In reply to Martin Stránský from comment #23) > Btw. I believe that a patch from Bug 1158076 can be greatly simplified by > ui.use_standins_for_native_colors and/or ui.use_native_color. > > When dark theme is enabled we may set ui.use_standins_for_native_colors and > only draw the background widgets in light theme. Karl, what do you think? I prefer using native colors even in the light theme, which an approach like attachment 8753289 [details] [diff] [review] should provide.

This bug affects GTK3 enabled Firefox (version 46+) as well.

(In reply to Artem S. Tashkinov from comment #27) > This bug affects GTK3 enabled Firefox (version 46+) as well. I don't understand why you closed this if it's still broken. It sounds like it still needs to be fixed.