I upgraded my Rawhide box today and got GTK+ 3.15.4. With this GTK+, the text on lots of Firefox UI elements is white, which makes it close to unreadable as the background is usually light grey. This affects at least tab titles, various buttons, and the right-click menu. mclasen says: <mclasen> in any case, firefox is not using gtk as a tookit; and if it is randomly poking at the theme for colors, too bad i.e. he doesn't consider it a bug in GTK+ (and indeed I don't see anything similar in more 'typical' GTK+-based apps), so filing against Firefox. I confirmed that downgrading to GTK+ 3.15.3 'fixes' this.
Fwiw, I do consider it worth investigating, and we should figure out a fix, of course.
I have seen this also in menu bar and bookmarks Toolbar
have you tried Disabling the " Gnome-Shell Integration " in Firefox Plugins, an restarting the Browser.
(In reply to Greg` from comment #3) > have you tried Disabling the " Gnome-Shell Integration " in Firefox > Plugins, an restarting the Browser. or try FF 36 Beta's an see if you can reproduce the problem
Proposing as F22 Alpha blocker, or potentially Beta: "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. " https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Required_applications
I'm running 'xfce4' - so no Gnome at all - and I also get white menu (and within menu it's showing white text on white background) on today's Rawhide upgrade: firefox-35.0-7.fc22.x86_64 gtk3-3.15.4-1.fc22.x86_64 And in fact my Gnome shell integration plugin is in the mode 'Ask to Activate'. Luckily when the mouse is moved across a menu item it uses blue background so the white text is then for the individual item readable.
"or try FF 36 Beta's an see if you can reproduce the problem" that's not really practical; you can't just download an upstream build and try, because upstream builds are (AFAIK) i) statically linked ii) not GTK+ 3-based. And you can't really expect people to be able to bump the Fedora firefox package to 36 beta and build it. I'll check it without the 'shell integration' plugin though.
The GNOME Shell integration plugin state (ask to activate, enabled, disabled) doesn't seem to make any difference at all.
(In reply to Adam Williamson (Red Hat) from comment #7) > "or try FF 36 Beta's an see if you can reproduce the problem" > > that's not really practical; you can't just download an upstream build and > try, because upstream builds are (AFAIK) i) statically linked ii) not GTK+ > 3-based. And you can't really expect people to be able to bump the Fedora > firefox package to 36 beta and build it. > > I'll check it without the 'shell integration' plugin though. one could argue a Vanilla build of Firefox works a lot better than a bogged down Fedora build. i remember Remi used to build Vanilla firefox builds in his own Repo for Fedora ages ago an worked much better than a Fedora build
one can argue whatever one likes, but it doesn't have squat to do with this bug report.
I appear to be seeing similar corruption with a wxPython 3 application on KDE. Downgrading to gtk3 3.15.3 fixed it as well. I don't know if that's enough to make this a gtk3 bug.
Sure, that's a "bug" in Firefox. It's caused by changes in color themes used by Firefox for those elements.
Do you run the default Dark theme? And does Firefox pick it? I see a bug on rawhide when menu background color is white when the dark theme is used. So it's white text on wtihe background then.
hm, I was confused by terminal which runs in dark theme even when rest of the system does not.
It's because Gtk3 gives us wrong colors. Or there may be a different way how to get them. There's the diff between F21 and Rawhide: --- gtk3-3.14.6.txt 2015-01-29 14:55:00.012759426 +0100 +++ gtk3-3.15.4.txt 2015-01-29 08:57:00.000000000 +0100 @@ -1,21 +1,21 @@ -R:224 G:224 B:224 A:255 : sMozScrollbar +R:000 G:000 B:000 A:000 : sMozScrollbar -R:237 G:237 B:237 A:255 : sMozWindowBackground +R:233 G:233 B:233 A:255 : sMozWindowBackground -R:046 G:052 B:054 A:255 : sMenuText +R:255 G:255 B:255 A:255 : sMenuText -R:046 G:052 B:054 A:255 : sButtonText -R:046 G:052 B:054 A:255 : sButtonHoverText +R:255 G:255 B:255 A:255 : sButtonText +R:255 G:255 B:255 A:255 : sButtonHoverText -R:046 G:052 B:054 A:255 : sMenuBarText -R:046 G:052 B:054 A:255 : sMenuBarHoverText +R:255 G:255 B:255 A:255 : sMenuBarText +R:255 G:255 B:255 A:255 : sMenuBarHoverText
Created attachment 985621 [details] testcase It gets the colors the same way as Firefox does.
Comment on attachment 985621 [details] testcase build by: gcc -o wrong-colors -g -O0 wrong-colors.c `pkg-config --libs --cflags gtk+-3.0`
Why does the summary relate to Chrome when all comments do refer to FF? This is a bit misleading when searching for this issue on bugzilla.
It doesn't refer to "Chrome", it refers to "chrome" - which is what FF (and others) calls various graphical decoration.
Discussed at 2015-02-02 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-02-02/f22-blocker-review.2015-02-02-17.06.log.txt . Accepted as a Final blocker: we agreed that this is a conditional violation of the Alpha criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments.", but it's not serious enough to block Alpha, as you *can* use Firefox, it's just rather ugly and inconvenient. We solidly agreed it's serious enough to block Final. We weren't totally sure about Beta, so we decided we'd decide that if we need to - we're expecting it should be fixed much sooner (ideally for Alpha) so we don't have to decide that.
this is is fixed upstream
New GTK+ release should be coming soon, right?
Fix confirmed in 3.15.6, thanks.