Bug 1185999 - [Gtk3] Text on various bits of chrome (tab titles, menus, buttons...) is white with GTK+ 3.15.4
Summary: [Gtk3] Text on various bits of chrome (tab titles, menus, buttons...) is whit...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk3
Version: rawhide
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F22FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2015-01-26 19:23 UTC by Adam Williamson
Modified: 2015-02-11 04:56 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 04:37:17 UTC


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

Description Adam Williamson 2015-01-26 19:23:05 UTC
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 20:28:13 UTC
Fwiw, I do consider it worth investigating, and we should figure out a fix, of course.

Comment 2 satellitgo 2015-01-26 22:38:35 UTC
I have seen this also in menu bar and bookmarks Toolbar

Comment 3 Greg` 2015-01-27 00:37:44 UTC
have you tried Disabling the " Gnome-Shell Integration "  in Firefox Plugins, an restarting the Browser.

Comment 4 Greg` 2015-01-27 08:09:58 UTC
(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 10:11:37 UTC
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 10:25:33 UTC
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 21:32:11 UTC
"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 22:40:11 UTC
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 22:48:44 UTC
(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 23:00:48 UTC
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 23:54:34 UTC
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 12:14:58 UTC
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 12:58:30 UTC
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 13:08:19 UTC
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 14:00:24 UTC
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 14:02:07 UTC
Created attachment 985621 [details]
testcase

It gets the colors the same way as Firefox does.

Comment 17 Martin Stransky 2015-01-29 14:02:48 UTC
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 15:18:26 UTC
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 15:22:39 UTC
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 17:53:12 UTC
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 14:27:11 UTC
this is is fixed upstream

Comment 22 Adam Williamson 2015-02-08 16:22:51 UTC
New GTK+ release should be coming soon, right?

Comment 23 Adam Williamson 2015-02-11 04:56:47 UTC
Fix confirmed in 3.15.6, thanks.


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