Closed Bug 1255344 Opened 8 years ago Closed 8 years ago

Runtime support for gtk+ 3.19/3.20 is not complete

Categories

(Core :: Widget: Gtk, defect)

46 Branch
All
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1234158
Tracking Status
firefox46 + ---

People

(Reporter: ricotz, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160304115459

Steps to reproduce:

Running the current beta branch with gtk+ 3.19.11+ results in visually broken menus and tooltips.

Besides that there are multiple warnings like this one:
"Gtk-WARNING **: State 0 for GtkSeparatorMenuItem 0x7f6d704240a0 doesn't match state 128 set via gtk_style_context_set_state ()"


Actual results:

Menus and toolstip should be themed correctly.
No warnings regarding "gtk_style_context_set_state ()".


Expected results:

The 46 beta branch should not default to gtk3 yet while the stable gtk+ release at the time 46 will be released is going to be 3.20.x.
OS: Unspecified → Linux
Hardware: Unspecified → All
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
[Tracking Requested - why for this release]:
Read "Expected results" above.  Makes sense to me.
Blocks: gtk3
Do we  need to disable this in beta? We could take a fix for beta 3.
Flags: needinfo?(karlt)
In some ways, holding back release of the gtk3 port because gtk+ 3.20 will
break backward compat again would be like holding back win 8.1, and 10
support because it looks bad on win 11.  What's difficult in the decision
is that, although our xp support looks ancient on all platforms, it may look
better on win 11 than the win 8 support.

I doubt a fix for this is something we'd want to uplift to beta.

While we could argue that GTK3 is not yet stable enough to build Gecko
against, I think these issues will not go away until there is a GTK4.  We are
not going to be able to release a gtk3 port regression-free as long as the
target keeps moving on us.  We just need to pick the time when the benefits
outweigh the regressions.  There are honestly too many different variables in
the equation for me to be able to claim to know that is true for the
overwhelming majority of possible configurations, but we do have many
developers working on Linux with GTK3 builds, and the rate of reported Gecko
bugs (excluding bugs in platform libraries) has reduced.

My gut feeling is that we need to move forward and we'll just have to deal
with future broken GTK versions as best as we can.

Even if we hold off building against GTK3 again, distributions will still
build against GTK3.  Fedora, Arch, at least, do so already.
Flags: needinfo?(karlt)
I am in favor of moving forward. The fact that we keep blocking GTK3 has become something of a running joke within the user community. With each release, the GTK2 builds become less and less tested themselves and more of a liability given that developers mostly live in GTK3 themselves (and for the users? Well, do we just let them eat cake, eh?), and at some point that is going to bite us.
I have a patch for Gtk3.20, the patch is already in Fedora 24 which ships gtk3.20 (3.19.x recently). Next step is to make this patch compatible with olded Gtk3 versions which is what I'm working on now.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.