Bug 1185999 - [Gtk3] Text on various bits of chrome (tab titles, menus, buttons...) is white with GTK+ 3.15.4
[Gtk3] Text on various bits of chrome (tab titles, menus, buttons...) is whit...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gtk3 (Show other bugs)
rawhide
x86_64 Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F22FinalBlocker
  Show dependency treegraph
 
Reported: 2015-01-26 14:23 EST by Adam Williamson
Modified: 2015-02-10 23:56 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-10 23:37:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
testcase (6.68 KB, text/plain)
2015-01-29 09:02 EST, Martin Stransky
no flags Details

  None (edit)
Description Adam Williamson 2015-01-26 14:23:05 EST
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.
Comment 1 Matthias Clasen 2015-01-26 15:28:13 EST
Fwiw, I do consider it worth investigating, and we should figure out a fix, of course.
Comment 2 satellitgo 2015-01-26 17:38:35 EST
I have seen this also in menu bar and bookmarks Toolbar
Comment 3 Greg` 2015-01-26 19:37:44 EST
have you tried Disabling the " Gnome-Shell Integration "  in Firefox Plugins, an restarting the Browser.
Comment 4 Greg` 2015-01-27 03:09:58 EST
(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
Comment 5 Kamil Páral 2015-01-27 05:11:37 EST
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
Comment 6 Zdenek Kabelac 2015-01-27 05:25:33 EST
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.
Comment 7 Adam Williamson 2015-01-27 16:32:11 EST
"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.
Comment 8 Adam Williamson 2015-01-27 17:40:11 EST
The GNOME Shell integration plugin state (ask to activate, enabled, disabled) doesn't seem to make any difference at all.
Comment 9 Greg` 2015-01-27 17:48:44 EST
(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
Comment 10 Adam Williamson 2015-01-27 18:00:48 EST
one can argue whatever one likes, but it doesn't have squat to do with this bug report.
Comment 11 Orion Poplawski 2015-01-27 18:54:34 EST
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.
Comment 12 Martin Stransky 2015-01-28 07:14:58 EST
Sure, that's a "bug" in Firefox. It's caused by changes in color themes used by Firefox for those elements.
Comment 13 Martin Stransky 2015-01-29 07:58:30 EST
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.
Comment 14 Martin Stransky 2015-01-29 08:08:19 EST
hm, I was confused by terminal which runs in dark theme even when rest of the system does not.
Comment 15 Martin Stransky 2015-01-29 09:00:24 EST
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
Comment 16 Martin Stransky 2015-01-29 09:02:07 EST
Created attachment 985621 [details]
testcase

It gets the colors the same way as Firefox does.
Comment 17 Martin Stransky 2015-01-29 09:02:48 EST
Comment on attachment 985621 [details]
testcase

build by: gcc -o wrong-colors -g -O0 wrong-colors.c `pkg-config --libs --cflags gtk+-3.0`
Comment 18 Joachim Frieben 2015-01-31 10:18:26 EST
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.
Comment 19 Orion Poplawski 2015-01-31 10:22:39 EST
It doesn't refer to "Chrome", it refers to "chrome" - which is what FF (and others) calls various graphical decoration.
Comment 20 Adam Williamson 2015-02-02 12:53:12 EST
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.
Comment 21 Matthias Clasen 2015-02-08 09:27:11 EST
this is is fixed upstream
Comment 22 Adam Williamson 2015-02-08 11:22:51 EST
New GTK+ release should be coming soon, right?
Comment 23 Adam Williamson 2015-02-10 23:56:47 EST
Fix confirmed in 3.15.6, thanks.

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