GNOME Bugzilla – Bug 743395
Regression in gnome-terminal starting with gtk commit 27285f1 ' cssstyle: Have a default style'
Last modified: 2015-12-02 12:10:40 UTC
After rawhide updated gtk3 to 3.15.4, there seems to be a regression in gnome-terminal where the terminal windows shrinks on every newline in the vte widget. Bisected this to commit 27285f1f0fb00bb4507a8bf3e426bef940ae41af Author: Benjamin Otte <otte@redhat.com> Date: Mon Jan 5 16:13:18 2015 +0100 cssstyle: Have a default style This way we can initialize the default style info with a style and ddon't need to special case NULL everywhere. Doesn't seem to be easily revertible so I can't quite confirm.
Upon further investigation: - The shrinking on just enter in the bash prompt stops if I unset __vte_prompt_command as found in the distribution /etc/profile.d/vte.sh - The shrinking on focus / unfocus of the window remains
Created attachment 295310 [details] [review] window: Track padding for geometry Changes in padding need to cause an update of geometry. And with GTK 3.15 padding actually does change causing shrinkage of the window when (un)focusing.
Thanks. This fixes the (un)focus and newline shrinkage here. There is still shrinking in the case of opening a new terminal tab (Ctrl-Shift-T)
(In reply to comment #2) > with GTK 3.15 padding actually does change This sounds like a terrible idea to me what should be fixed in the first place. Could you please elaborate on this? Is my window size going to change when (un)focusing because... because why?
Because gnome-terminal assumes that padding never changes. And up to that change it has been lucky. But padding is a CSS property and can be changed by any theme for any reason it wants - most commonly state changes, but you could probably also trigger it by switching themes to one that utilizes different padding. The commit in GTK changes behavior of GTK by making it more predictable. GTK styles have forever only been correctly updated when a widget was visible on screen. However, GTK needs to return some values if it gets queried before being shown. Before this change we would just build the values from the state the style context was in when it was first queried. This point in time could of course change at any time when somebody added or removed code in superclasses that queried the context. Now GTK will always return a "default" style that is identical for every widget as long as it isn't shown. Unfortunately that default style has a different padding than the actual style used later.
I understand that technically gnome-terminal forgets to do something that it should do. Normally, it'd be a low priority bug somewhere way down our priority list, somewhere next to the similar bug 735079, and probably staying unfixed for long years. A focus in/out shrinking the window makes it a critical bug, rendering the app pretty much unusable. What I'm curious about: Why is there any Gtk+ theme which thinks changing the padding on focus in/out is a good idea? Doesn't it lead to a terrible user experience? I definitely wouldn't want to see my window change size just because I (un)focused. What happens to all other apps that somehow rely on the window size and position, e.g. window maager's snapping feature and such, how are they going to work? (Note: I don't have Gtk+ git master build to try out the behavior, and would rather not bother installing one if avoidable.) Also, independently of the current gnome-terminal bug, let me point you to bug 677329 (Gtk+ sometimes forgets to send focus in/out events to the apps). If you decide to ship a theme where the padding depends on focus events, you most definitely need to fix that bug first! As for now, while I understand that there's a bug in gnome-terminal, could you please make it a low priority bug by not shipping any theme that changes the padding? Or, fix the missing focus in/out bug and explain the design rationale behind shipping a theme with focus-dependant padding?
Nobody is changing the padding after startup. The problem is that the padding given to gtk_window_set_geometry() is inconsistent with the padding queried by GTK when determining the size. And that causes the size computation to determine that the current size is wrong and shrink it a bit *every time it is run*. And it is run whenever the style of the toplevel window changes - and that happens on focus out/in.
Thanks for the explanation, I begin to get a feeling (I'm not familiar with this part of the code or Gtk's behavior). However: - Isn't there one initial shrinkage (e.g. 79x23 original size instead of 80x24)? - I wonder how come that according to comment 3 Ctrl--Shift-T still shrinks with your patch...
I confirm yanko's and egmont's findings: * The patch solves the shrink on window switch * With the patch, Terminal still opens one unit smaller in either direction (79x23 instead of 80x24 in my case) * With the patch, there is still shrinkage when opening and closing tabs. It seems I lose one unit in each direction each time I open a tab *after the first time*. The *first* time I close a tab when I have more than one open, I lose another unit in each direction; there's no shrinkage with subsequent tab closes until I open another new tab, whereupon the next close results in a shrink. It's a tad hard to pin down, but it's along those lines, anyway.
(In reply to comment #9) > * With the patch, Terminal still opens one unit smaller [...] > * With the patch, there is still shrinkage when opening and closing tabs [...] The first one was a guess only :) Proud but unhappy that I guessed it right. @Benjamin, could you please guide us on how these two issues should be solved (or even better: update your patch)?
*** Bug 742532 has been marked as a duplicate of this bug. ***
Comment on attachment 295310 [details] [review] window: Track padding for geometry Thanks, chpe. I took the liberty to commit this because it is too annoying at the moment.
For the shrinkage on new/close tab, can you try sth like this in terminal_window_init(): + /* Need to update window geometry when showing/hiding the tab bar */ + g_signal_connect_swapped (priv->mdi_container, "notify::show-tabs", + G_CALLBACK (terminal_window_update_geometry), window); (or maybe terminal_window_update_size as callback) ?
Neither seem to help here. Still shrinking on new tab.
I've pushed a fix to master that should restore the behavior of GTK 3.14. Fixing this perfectly is actually pretty much impossible with the way GTK works at present, so once you've confirmed GTK works, I guess you can close this bug.
That would be https://git.gnome.org/browse/gtk+/commit/?id=473ab791ff10c46426c2aab4cd8c3fe8d77a8925 ? Does it require the previous commit as well? Thanks!
Yeah, it requires at least the previous commit as well. In case you're thinking about backporting it to rawhide: Matthias said he wanted to do a GTK release soon, so you might wanna wait for that.
Thanks - but even just to test it, the way I do that is just to rebuild the package (it's just my preferred workflow, I don't use jhbuild or anything, whenever I want to test any change, I apply it to the package).
Let's close this, then.
The bug seems to have been reintroduced in latest GNOME Terminal (3.19.1) and GTK+ (3.19.3). Symptoms (and workarounds) are exactly the same as reported by Yanko.
I think it's more likely now due to bug 757282.
I'm definitely seeing the symptoms again in Rawhide, whatever's causing it.
I'm also seeing this in Fedora Rawhide. Can we re-open the bug, please?
I see no evidence that the fix to this bug has regressed. Just because you see the same symptoms does not mean that the cause is the same, esp. since we *know* that geometry is broken in gtk+ 3.19 due to bug 757282.