GNOME Bugzilla – Bug 771112
some applications windows to grow on startup (with CSD)
Last modified: 2017-10-04 08:29:53 UTC
With gtk3-3.21.4-2.fc25.x86_64, everything worked fine. With gtk3-3.21.5-1.fc25.x86_64, certain applications (I noticed it with virt-manager) grow larger and larger with every start. Every time you start it, it's a bit wider and taller, until after ~5 starts it covers full screen width/height. This only happens on Wayland, but not in X11, and did not happen in previous gtk version (tested with downgrade). See the video to showcase the problem. gtk3-3.21.5-1.fc25.x86_64 virt-manager-1.4.0-3.fc25.noarch Fedora 25
I can't upload a 4 MB video as an attachment here, but you can see it here: https://www.youtube.com/watch?v=NO6Wlaoq0x8
Also happens e.g. with wireshark-gtk or meld.
Reproduces with GDK_BACKEND=x11 GTK_CSD=1 so changing component and title.
(In reply to Kamil Páral from comment #0) > With gtk3-3.21.4-2.fc25.x86_64, everything worked fine. Nope, I can reproduce with 3.21.4 as well so it's not a regression between 3.21.4 and 3.21.5
I can even reproducer with gtk+3.20.x so that made me wonder, I see no reagression here, but an application issue. I checked meld code, and it saves the window size using the GtkWindow API and set its back using the GtkWidget API. As former takes client side decorations into account and the later doesn't, the size changes and grows overtime.
If you link to a howto how this should be done, I can report bugs against individual applications that show this behavior and ask them to adjust their code. However, is it really intentional that querying for window size and then setting _the same value_ changes the actual window size? That sounds like a very confusing API decision.
(In reply to Kamil Páral from comment #6) > If you link to a howto how this should be done, I can report bugs against > individual applications that show this behavior and ask them to adjust their > code. https://wiki.gnome.org/HowDoI/SaveWindowState > However, is it really intentional that querying for window size and then > setting _the same value_ changes the actual window size? That sounds like a > very confusing API decision. Querying the window size and then setting it with GtkWindow API is perfectly fine. Querying the window size with GtkWidget API and then setting it with GtkWindow API, *or* querying the window size with GtkWindow API and then setting it with GtkWidget API, is *not* okay, and only worked up until now with server-side decorations only on X11.
(In reply to Olivier Fourdan from comment #4) > (In reply to Kamil Páral from comment #0) > > With gtk3-3.21.4-2.fc25.x86_64, everything worked fine. > > Nope, I can reproduce with 3.21.4 as well so it's not a regression between > 3.21.4 and 3.21.5 To explain this for anyone reading this, .4 release did not use CSD by default (at least in Fedora 25), so the problem did not occur by default. But if you started the app with GTK_CSD=1 envvar manually, then yes, the same bug occurred even with .4 release. (In reply to Emmanuele Bassi (:ebassi) from comment #7) > Querying the window size with GtkWidget API and then setting it with > GtkWindow API, *or* querying the window size with GtkWindow API and then > setting it with GtkWidget API, is *not* okay, and only worked up until now > with server-side decorations only on X11. Oh I see the difference now. Thanks for clarifying and for the link, I'll report a bug against the affected applications.
I individually reported the issue in apps where I spotted the problem: https://bugzilla.gnome.org/show_bug.cgi?id=771290 https://bugzilla.gnome.org/show_bug.cgi?id=771292 https://bugzilla.gnome.org/show_bug.cgi?id=771293 https://bugzilla.gnome.org/show_bug.cgi?id=771295 https://bugzilla.redhat.com/show_bug.cgi?id=1375178 https://bugzilla.redhat.com/show_bug.cgi?id=1375175 https://bugzilla.gnome.org/show_bug.cgi?id=771288
(In reply to Kamil Páral from comment #9) > I individually reported the issue in apps where I spotted the problem: > https://bugzilla.gnome.org/show_bug.cgi?id=771290 > https://bugzilla.gnome.org/show_bug.cgi?id=771292 > https://bugzilla.gnome.org/show_bug.cgi?id=771293 > https://bugzilla.gnome.org/show_bug.cgi?id=771295 > https://bugzilla.redhat.com/show_bug.cgi?id=1375178 > https://bugzilla.redhat.com/show_bug.cgi?id=1375175 > https://bugzilla.gnome.org/show_bug.cgi?id=771288 FYI half of these apps do not have active maintainers so the bugs won't be fixed unless somebody volunteers patches. In the case of Epiphany, I can't reproduce the issue.
(In reply to Emmanuele Bassi (:ebassi) from comment #7) > Querying the window size and then setting it with GtkWindow API is perfectly > fine. > > Querying the window size with GtkWidget API and then setting it with > GtkWindow API, *or* querying the window size with GtkWindow API and then > setting it with GtkWidget API, is *not* okay, and only worked up until now > with server-side decorations only on X11. In the current GtkWindow docs for gtk_window_get_size(), the second and fourth notes directly contradict each other, and I'm pretty sure the first paragraph is now also incorrect. I don't know what these other apps do, but Meld's implementation here listens for configure-event and uses those sizes, which is pretty much exactly what the first note there tells you to do. Pushing this issue on to applications by suggesting that they've been doing something unsupported this whole time is not a very reasonable position to take.
(In reply to Kai Willadsen from comment #11) > Pushing this issue on to applications by suggesting that they've been doing > something unsupported this whole time is not a very reasonable position to > take. Stuff like this has been par for the course for GTK+ 3 thus far. It just needs a docs update. But see: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ TL;DR GTK+ 3.22 will be stable LTS, and breaking changes like this will no longer be allowed in GTK+ 3... starting next week.
(In reply to Michael Catanzaro from comment #12) > Stuff like this has been par for the course for GTK+ 3 thus far. It just > needs a docs update. Sadly, I'm all too familiar... > But see: > https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise- > in-gtk/ > > TL;DR GTK+ 3.22 will be stable LTS, and breaking changes like this will no > longer be allowed in GTK+ 3... starting next week. Thanks for that pointer. I wasn't aware that that the actually-stable release had been moved up to 3.22 since the hackfest discussions.
(In reply to Kai Willadsen from comment #11) > (In reply to Emmanuele Bassi (:ebassi) from comment #7) > > Querying the window size and then setting it with GtkWindow API is perfectly > > fine. > > > > Querying the window size with GtkWidget API and then setting it with > > GtkWindow API, *or* querying the window size with GtkWindow API and then > > setting it with GtkWidget API, is *not* okay, and only worked up until now > > with server-side decorations only on X11. > > In the current GtkWindow docs for gtk_window_get_size(), the second and > fourth notes directly contradict each other, and I'm pretty sure the first > paragraph is now also incorrect. Indeed; the documentation was likely written for GTK+ 2.x or even before that, when we did not have support for Wayland or for client-side decorations. > I don't know what these other apps do, but > Meld's implementation here listens for configure-event and uses those sizes, > which is pretty much exactly what the first note there tells you to do. Yep, and that's really not how you should do this; the configure-event signal is an X11-ism, even though GTK+ tries to map it to other windowing systems. The appropriate way to get a notification of a size change in a widget is to use the GtkWidget::size-allocate signal. For top-levels, though, especially the ones using client-side decorations, you cannot use the allocation that you get from GtkWidget because that does not include the client-side decorations. If it did, all code running on Wayland would break, since the decorations are added automatically by GTK+ itself. For this reason, you need to use GtkWindow-specific API to get the size of the window, in order to store it. I'll make sure to change the documentation of GtkWindow.get_size() so that it reflects reality. > Pushing this issue on to applications by suggesting that they've been doing > something unsupported this whole time is not a very reasonable position to > take. Sadly, we're in a bit of a "rock/hard place" situation, here; if we didn't do this, we would break other, existing code, when running using client-side decorations, both when manually added by the application developers, and when added automatically by GTK+, for instance when running on Wayland. We attempted that, and the resulting complexity and layering violation ended up ballooning out of control. In the end, we opted for asking application developers — who most likely have to deal with ensuring their applications are already Wayland-ready — to change their code to deal with client-side decorations.
> you cannot use the allocation that you get from GtkWidget because that does not include the client-side decorations. Sorry, this sentence contains an additional "not"; the problem is that the allocation *has* to contain the size of the client-side decoration, but since those decorations may be automatically added by the toolkit depending on the windowing system, they should not contribute to the logical size of the window. If they do, then you get the issue of this bug, i.e. ever-growing windows.
It looks like there's not any actual bug here. The outstanding one was probably the concerns about the docs mentioned in Comment 11, but Emmanuele seems to have fixed that the next day with commit 08e443e0db6f74ade5836f8028073aeac14aab38. So, resolving as NOTABUG (in GTK+) (anymore)!