After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731137 - Spurious SIGWINCH in maximized window with tabs of different font sizes
Spurious SIGWINCH in maximized window with tabs of different font sizes
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
3.13.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-06-03 01:25 UTC by Egmont Koblinger
Modified: 2021-06-10 20:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2014-06-03 01:25:18 UTC
Maximized gnome-terminal window, two tabs using different font sizes.

Switch tabs: both VTEs receive back-n-forth window size change events, temporarily switching to the size of the other tab.

One way to catch the window change signal: run bash <= 4.2 (beware, bash 4.3 delays handling the trap, it's not good) or zsh, and execute
trap 'stty size' SIGWINCH

Found here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503280
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649579
Comment 1 Egmont Koblinger 2014-06-03 10:21:58 UTC
This is even better for debugging:
  trap 'date; stty size' SIGWINCH
This reveals that back-n-forth resizing always happens when switching *to* the particular tab, not when switching away from it.

With rewrapping, drawbacks of the back-n-forth resize include:
- Noticeable slowdown (rewrapping is a CPU-heavy operation, and is executed twice although it wouldn't be necessary at all).
- Loss of some of the scrollback data

g-t tries to maintain the same logical size (col×row) for all the tabs, even if they have different fonts.  Probably what happens with maximized/fullscreen g-t is that it tries to ask for the previous tab's logical size according to the new tab's font size, and later asynchronously the WM overrides it.

In case of fullscreen g-t:  It could pre-calculate the proper size on its own since g-t knows it's fullscreen.

In case of maximized g-t:  Does g-t know that it's maximized?  Is this a concept that apps know about, or is this a private business of the WM?  If the latter then I'm afraid there's not much we could do.  Maybe, as a heuristic working in the vast majority of the cases, if the window size is set to something disobeying the grid hints then g-t could assume it's maximized and retain this assumption until the window is resized.  Chances of using two different fonts, both perfectly fitting whole cells without extra padding is extremely small.

Or we could start thinking of a brand new model to handle tabs with different font sizes.  Maybe on switching tabs g-t could force to stay at the same pixel size, resulting in different logical size, plus the window size not obeying the new grid hints (how do WMs react to that?).  Not sure this would be any better.
Comment 2 Egmont Koblinger 2015-01-30 15:06:23 UTC
Another idea, perhaps the best compromise so far:

Gnome-terminal could maintain a mapping from font sizes to logical terminal sizes.

When switching between tabs of the same font size, obviously the desired behavior is not to resize the terminal. When creating a new tab or closing an old one, or when changing the font size (possibly via a profile change) the behavior could stay as what we have currently.

However, when changing from one tab to another which has a different font, instead of trying to maintain the same logical size g-t could rather look at the mapping to see what was the last logical size used for that font size, and switch to that.

This would get rid of the back-n-forth resizes for the maximized/fullscreen case.

Users of non-maximized window with multiple font sizes would see a change in behavior, I'm not sure if they'd like it or not; I hope using different font sizes in non-maximized windows is quite rare anyways.
Comment 3 Josh Triplett 2015-09-15 17:49:40 UTC
(In reply to Egmont Koblinger from comment #2)
> Another idea, perhaps the best compromise so far:
> 
> Gnome-terminal could maintain a mapping from font sizes to logical terminal
> sizes.
> 
> When switching between tabs of the same font size, obviously the desired
> behavior is not to resize the terminal. When creating a new tab or closing
> an old one, or when changing the font size (possibly via a profile change)
> the behavior could stay as what we have currently.
> 
> However, when changing from one tab to another which has a different font,
> instead of trying to maintain the same logical size g-t could rather look at
> the mapping to see what was the last logical size used for that font size,
> and switch to that.
> 
> This would get rid of the back-n-forth resizes for the maximized/fullscreen
> case.
> 
> Users of non-maximized window with multiple font sizes would see a change in
> behavior, I'm not sure if they'd like it or not; I hope using different font
> sizes in non-maximized windows is quite rare anyways.

Why not just remember the exact terminal width/height associated with the terminal in each tab, and never send terminal resizes unless the window actually resizes or the font changes?

If I have a fullscreen/maximized terminal with two tabs, at different fonts and thus different sizes, each one should know how big it is and maintain that size, independently of the other.  And no SIGWINCHes should occur at all when switching between them.
Comment 4 Josh Triplett 2015-09-15 17:53:04 UTC
I can reliably reproduce this with gnome-terminal 3.16.2, with the added
complication that sometimes the spurious size changes don't actually
result in the right updates in the programs running in the terminal.
Exact steps to reproduce:

1) Open gnome-terminal.
2) Maximize the gnome-terminal window.
3) Open a program that cares about screen size, such as vim.  To make it
   more obvious what vim thinks the screen size is, you may want "set
   laststatus=2" to create a status line above the command area;
   however, you can also just type ':' to leave a prompt on the last
   line.
4) Open a second tab.
5) In the second tab, increase the font size by a few steps with Ctrl-+.
6) Switch back to the first tab.

Notice that the terminal-oriented application in the first tab thinks
the screen has gotten smaller, to the width and height of the second
tab.

This reproduces 100% of the time for me, but in theory it *might* be a
race condition with the sending of multiple SIGWINCHes.  Nonetheless,
the right fix is still to stop resizing the terminal at all.
Comment 5 Egmont Koblinger 2015-09-16 07:19:42 UTC
(In reply to Josh Triplett from comment #3)

> [...] and never send terminal resizes [...]

Imagine what would happen to non-maximized terminals. The actual terminal size would shrink when you open the 2nd tab (or we'd have to force showing the tab bar even with a single tab). We'd no longer be able to align the window size to the grid (like konsole does with the continuous resize - for me it's a blocker issue).

(In reply to Josh Triplett from comment #4)

> [...] it *might* be a
> race condition with the sending of multiple SIGWINCHes.

It *is* a race condition on the app's side; not with sending but with receiving and handling multiple sigwinches. Please don't blame gnome-terminal for triggering those bugs; instead please go ahead and file bugs against them.

As long as gnome-terminal _ever_ initiates a window resize; there is a chance that the window manager kicks back reverting our change soon after and this will result in two consecutive resize events.

I understand the current situation is not perfect, but changing gnome-terminal never to initiate a resize would in my opinion be way worse.
Comment 6 Josh Triplett 2015-09-16 15:46:32 UTC
(In reply to Egmont Koblinger from comment #5)
> (In reply to Josh Triplett from comment #3)
> 
> > [...] and never send terminal resizes [...]
> 
> Imagine what would happen to non-maximized terminals. The actual terminal
> size would shrink when you open the 2nd tab (or we'd have to force showing
> the tab bar even with a single tab). We'd no longer be able to align the
> window size to the grid (like konsole does with the continuous resize - for
> me it's a blocker issue).

I meant "never send terminal resizes to existing terminals when switching tabs", not "never send resizes, period".  Sending a resize to deal with adding the tab bar to a maximized window (and thus losing a line or two), sure, that seems fine, and that wouldn't cause the problem reported here.  But sending two resizes to a tab when switching to it, one spuriously to shrink it to the size of the previous tab and another to switch it back to its current size, *that* makes no sense.  That's the behavior this bug is talking about, and that's what I'm asking if gnome-terminal could stop doing.

Does some fundamental architectural limitation make it difficult to remove the spurious resizes when switching tabs?

(Separate from that, I do think the current windowed behavior has some interesting quirks, such as resizing the window when switching tabs, but this bug doesn't talk about any of those.)

> (In reply to Josh Triplett from comment #4)
> > [...] it *might* be a
> > race condition with the sending of multiple SIGWINCHes.
> 
> It *is* a race condition on the app's side; not with sending but with
> receiving and handling multiple sigwinches. Please don't blame
> gnome-terminal for triggering those bugs; instead please go ahead and file
> bugs against them.

gnome-terminal shouldn't be sending spurious resizes/SIGWINCHes; that's still a bug, even if doing so also triggers bugs in other applications.

(And considering how signals work, and in particular the behavior when you attempt to send multiple instances of a signal before/during the handling of the first, that race condition seems rather non-trivial to avoid or fix.)

> As long as gnome-terminal _ever_ initiates a window resize; there is a
> chance that the window manager kicks back reverting our change soon after
> and this will result in two consecutive resize events.

That's not what's happening here, though.

> I understand the current situation is not perfect, but changing
> gnome-terminal never to initiate a resize would in my opinion be way worse.

Never initiating a resize (let alone two) when switching tabs seems reasonable; that doesn't relate to sending a legitimate resize when the size of the terminal really does change.
Comment 7 Egmont Koblinger 2015-09-17 19:47:29 UTC
(In reply to Josh Triplett from comment #6)

> (And considering how signals work, and in particular the behavior when you
> attempt to send multiple instances of a signal before/during the handling of
> the first, that race condition seems rather non-trivial to avoid or fix.)

Nope, it's in fact very easy to write a resize handler that's free of race condition.

First, quoting from sigaction() manual: "during execution of the signal handler [..] the signal which triggered the handler will be blocked, unless the SA_NODEFER flag is used". That is, unless you take explicit counter-action, the new WINCH which occurs while your handler is running will be delayed until after your handler has completed.

Second, even if that was not the case, or use used SA_NODEFER, that wouldn't be a problem. Why?

It's important to know that the signal handler must not do any heavy work. In particular, updating the UI definitely shouldn't be done from there. This is because many of the library methods it depends on is not reentrant. Imagine that you updated the UI from the signal handler, which can kick in at any time - even during a regular UI update. You have no clue where the cursor is (it's impossible to atomically update it along with anything you print during the app's regular operation), you have no clue what colors/attributes the terminal is currently at (same story), and you might even interrupt an escape sequence and interleave data in the middle, causing heavier corruption (especially when the handler returns and the normal paint procedure resumes).

So, the signal handler should be as trivial as possible. Preferably just updating a global boolean. The main code would (for pretty much every interactive app) normally sit in a select() code waiting for something external event to happen. Now if your signal handler only flips a bit, it doesn't really matter whether the signal is blocked or not during the execution of most of the source code you write - the only tricky part is to be able to check whether there's a pending resize and if not then enter the select() loop without losing a resize event happening between the two. And that's exactly what the pselect() call was invented for. But basically it's easier and cleaner to block the resize signal everywhere except that pselect.

Every app that doesn't follow this pattern (or something equivalent) is likely to already contain a race condition, and sure delivering two consecutive winch signals in a very short time might trigger this race way more often than it occurs normally. But any app that follows the right approach and has no race at all when handling a single winch probably doesn't have a race either with multiple winch signals.

So here's a pseudo code implementing robust resize without race condition:

resize_pending = 0;

void resize_handler() {
  resize_pending = 1;
}

int main() {
  // one-time setup
  sigprocmask (block winch);
  sigaction (install resize_handler function for winch);

  [...]

  // the main loop
  while (1) {
    [...]
    pselect(..., sigmask=<don't block winch>);
    [...]
    if (resize_pending) {
      new_size = termios(get window size);
      update_ui();
      resize_pending = 0;
    }
    [...]
  }
}

P.S. 1, just for fun: Because winch is blocked everywhere except within the pselect call, it's totally okay to reset resize_pending to 0 _after_ updating the UI, it doesn't introduce a race condition either. Or you could even do it right before pselect.

P.S. 2, again just for fun: You could even have a totally empty resize_handler(). But then you'd have to query the terminal size every the in the main loop and compare with the previously remembered value, which is a bit more expensive (and IMO a bit uglier) than checking a boolean.

Long story short: Don't blame gnome-terminal if an app does not correctly handle two consecutive resize events. It's a fault in that app. (That being said, in the mean time we should investigate if gnome-terminal could be improved not to do this.)
Comment 8 Egmont Koblinger 2015-09-17 20:03:04 UTC
(In reply to Josh Triplett from comment #6)

> I meant "never send terminal resizes to existing terminals when switching
> tabs", not "never send resizes, period".  Sending a resize to deal with
> adding the tab bar to a maximized window (and thus losing a line or two),
> sure, that seems fine, and that wouldn't cause the problem reported here. 
> But sending two resizes to a tab when switching to it, one spuriously to
> shrink it to the size of the previous tab and another to switch it back to
> its current size, *that* makes no sense.  That's the behavior this bug is
> talking about, and that's what I'm asking if gnome-terminal could stop doing.
> 
> Does some fundamental architectural limitation make it difficult to remove
> the spurious resizes when switching tabs?

What you clearly need to understand:

The first resize is _initiated_ by gnome-terminal. Why? Look at how gnome-terminal behaves when it's _not_ maximized, and you switch between two tabs of different font sizes.

I _think_ (I might easily be wrong here, though) gnome-terminal doesn't know about the concept of maximized size. It's just a private business of the window manager. Gnome-terminal just sees a size that it currently has. It doesn't know it's maximized, hence even when maximized, it tries to do exactly the same as it'd do if it wasn't: resize itself.

The second resize is _not_ initiated by gnome-terminal. There's no way gnome-terminal could foresee that the window manager would initiate another one, reverting the previous. But it's an asynchronous operation; by the time it happens gnome-terminal has already reported its desired new size to the application.

I'm not an expert on this topic at all, and you might point out that there is actually a way to know that we're maximized, in that case I'll revalidate my point and investigate if we could use that to improve gnome-terminal.

> Never initiating a resize (let alone two) when switching tabs seems
> reasonable; that doesn't relate to sending a legitimate resize when the size
> of the terminal really does change.

Here you meant "Never initiating a resize" as in the size measured in pixels, right? Take this approach: you'll fix this bug, but you'll introduce new ones (ones that I believe are worse for usability). The culprit is the grid size and the corresponding window manager hints. What should happen if the new font within the old window size just doesn't yield a whole number of cells? Whatever approach you chose, I'm afraid the result would be worse that the current bug.
Comment 9 Josh Triplett 2015-09-17 22:23:53 UTC
(In reply to Egmont Koblinger from comment #8)
> (In reply to Josh Triplett from comment #6)
> 
> > I meant "never send terminal resizes to existing terminals when switching
> > tabs", not "never send resizes, period".  Sending a resize to deal with
> > adding the tab bar to a maximized window (and thus losing a line or two),
> > sure, that seems fine, and that wouldn't cause the problem reported here. 
> > But sending two resizes to a tab when switching to it, one spuriously to
> > shrink it to the size of the previous tab and another to switch it back to
> > its current size, *that* makes no sense.  That's the behavior this bug is
> > talking about, and that's what I'm asking if gnome-terminal could stop doing.
> > 
> > Does some fundamental architectural limitation make it difficult to remove
> > the spurious resizes when switching tabs?
> 
> What you clearly need to understand:
> 
> The first resize is _initiated_ by gnome-terminal. Why? Look at how
> gnome-terminal behaves when it's _not_ maximized, and you switch between two
> tabs of different font sizes.

Ambiguous terminology, sorry.  Every time I said "resize" in my comment, I was referring to terminal $LINES/$COLUMNS and gnome-terminal sending SIGWINCH, *not* to the window pixel-size changing.

I'm aware of how gnome-terminal behaves when not maximized.  Personally, I find that behavior confusing, but nonetheless, I'm not attempting to change that here.

> I _think_ (I might easily be wrong here, though) gnome-terminal doesn't know
> about the concept of maximized size. It's just a private business of the
> window manager. Gnome-terminal just sees a size that it currently has. It
> doesn't know it's maximized, hence even when maximized, it tries to do
> exactly the same as it'd do if it wasn't: resize itself.

The terminal was previously maximized at a given font size.  It thus had a given number of terminal lines and columns.  The other tab was also maximized, at a different font size, so it had a different number of lines and columns.  However, those tabs are independent, and their terminal lines and columns shouldn't change when switching tabs.  Thus, gnome-terminal shouldn't send a SIGWINCH when switching tabs.  Furthermore, both windows are already maximized, so they shouldn't need to change their pixel size when switching tabs, because they already have the same size they previously had.

Also, windows can know they're maximized, by way of EWMH.  But even that shouldn't be necessary here.

> The second resize is _not_ initiated by gnome-terminal. There's no way
> gnome-terminal could foresee that the window manager would initiate another
> one, reverting the previous. But it's an asynchronous operation; by the time
> it happens gnome-terminal has already reported its desired new size to the
> application.
> 
> I'm not an expert on this topic at all, and you might point out that there
> is actually a way to know that we're maximized, in that case I'll revalidate
> my point and investigate if we could use that to improve gnome-terminal.

We could, but as far as I can tell it should suffice to notice that the terminal size already matches what it was the previous time the tab was active, and thus not attempt to change the pixel size of the window.  Thus, since it doesn't change the pixel size of the window, it shouldn't affect the number of lines or columns in the window, so it shouldn't send SIGWINCH.

> > Never initiating a resize (let alone two) when switching tabs seems
> > reasonable; that doesn't relate to sending a legitimate resize when the size
> > of the terminal really does change.
> 
> Here you meant "Never initiating a resize" as in the size measured in
> pixels, right?

No, not at all; I mean that switching tabs should never generate a SIGWINCH.  I don't want to attempt to change gnome-terminal's behavior with regard to pixel size here, other than to make sure it doesn't make spurious changes.
Comment 10 Egmont Koblinger 2015-09-17 22:32:38 UTC
(In reply to Josh Triplett from comment #9)

> The terminal was previously maximized at a given font size.  It thus had a
> given number of terminal lines and columns.  The other tab was also
> maximized, at a different font size, so it had a different number of lines
> and columns.  However, those tabs are independent

In current gnome-terminal those are not independent. If they were, the following would be the behavior, even with only a single font size:

I open a window, it opens at 80x24. I open some tabs, they also open at 80x24 logical size.

I switch to the first tab, and resize to let's say 100x50. Now I switch to the 2nd tab. Based on your logic, the window size should revert to 80x24 because...

> and their terminal lines
> and columns shouldn't change when switching tabs.  Thus, gnome-terminal
> shouldn't send a SIGWINCH when switching tabs.

...that's what you clearly wrote here. And then I also change the 2nd tab to 100x50-ish (maybe a little bit different), then switch to the 3rd tab to find out that that's also still at 80x24.

No, thanks!

It's still unclear to me how we could fix the bug we're talking about, and not break something else in the mean time.

> Also, windows can know they're maximized, by way of EWMH.  But even that
> shouldn't be necessary here.

I didn't know about it, I guess I should check it out.
Comment 11 Josh Triplett 2015-09-17 22:35:32 UTC
(In reply to Egmont Koblinger from comment #7)
> Long story short: Don't blame gnome-terminal if an app does not correctly
> handle two consecutive resize events. It's a fault in that app. (That being
> said, in the mean time we should investigate if gnome-terminal could be
> improved not to do this.)

I don't blame gnome-terminal for the apps not dealing with this.  But given that many commonly used apps currently *do* have such bugs, I do think it gnome-terminal should avoid sending two entirely unnecessary SIGWINCHes.  Which should be quite possible, as long as gnome-terminal recognizes when it doesn't need to change the pixel size of its own window.
Comment 12 Egmont Koblinger 2015-09-17 22:52:06 UTC
(In reply to Josh Triplett from comment #11)

> I don't blame gnome-terminal for the apps not dealing with this.  But given
> that many commonly used apps currently *do* have such bugs,

Please note that if you manually resize the window by dragging its edge, you're also sending SIGWINCHes (probably many more than 2) in a very short time. So app authors should just go ahead and fix their apps.

> I do think it
> gnome-terminal should avoid sending two entirely unnecessary SIGWINCHes. 
> Which should be quite possible, as long as gnome-terminal recognizes when it
> doesn't need to change the pixel size of its own window.

_If_ gnome-terminal can really safely reliably detect when it's maximized (which I'd have to study: how reliable is that EWMH, how much it's tied to old X, how about Wayland/Mir etc.) then this can be the key to a solution.

I guess we'd need to have two different resize policies:

(1) keep the current behavior (carrying the old tab's logical size to the new tab) if the window is not maximized;

(2) a new behavior that keeps the window size in pixels if the window is maximized.

Note that it would still be possible under certain circumstances that two resize events are sent in a very short time. Have a window that's not full size, and switch to another tab of bigger font size. This might become too large and the window manager might kick back requesting a smaller one that fits on the screen.
Comment 13 Egmont Koblinger 2015-09-17 22:56:56 UTC
Josh, while we're having this conversation, please please really do go ahead, and file bugreport for each app where the resize race condition causes problem for you, thanks! :)
Comment 14 Josh Triplett 2015-09-17 23:17:08 UTC
(In reply to Egmont Koblinger from comment #10)
> (In reply to Josh Triplett from comment #9)
> 
> > The terminal was previously maximized at a given font size.  It thus had a
> > given number of terminal lines and columns.  The other tab was also
> > maximized, at a different font size, so it had a different number of lines
> > and columns.  However, those tabs are independent
> 
> In current gnome-terminal those are not independent. If they were, the
> following would be the behavior, even with only a single font size:
> 
> I open a window, it opens at 80x24. I open some tabs, they also open at
> 80x24 logical size.
> 
> I switch to the first tab, and resize to let's say 100x50. Now I switch to
> the 2nd tab. Based on your logic, the window size should revert to 80x24
> because...

No, that's not what I'm suggesting at all.

> > and their terminal lines
> > and columns shouldn't change when switching tabs.  Thus, gnome-terminal
> > shouldn't send a SIGWINCH when switching tabs.
> 
> ...that's what you clearly wrote here. And then I also change the 2nd tab to
> 100x50-ish (maybe a little bit different), then switch to the 3rd tab to
> find out that that's also still at 80x24.
> 
> No, thanks!
> 
> It's still unclear to me how we could fix the bug we're talking about, and
> not break something else in the mean time.

Let's talk about a maximized window at the moment, though the logic should extend to any window.

Let's also assume that you have other tabs already open besides the two in question, so we don't have to think about the tab bar appearing or disappearing.

For simplicity, we'll say that at the first font size, a maximized tab fits C1xL1 columns/lines, and at the second font size, a maximized tab fits C2xL2 columns/lines.

You have a maximized window with multiple irrelevant tabs and a tab A.  The pixel size of the window is that of a maximized window.  The columns/lines of tab A are C1xL1.  You open a new tab, B.  Since the window is maximized, tab B's pixel size is also that of a maximized window.  The columns/lines of tab B start out at C1xL1.  You change the font size of tab B; its pixel size doesn't change, but its columns/lines become C2xL2.  (At that time, tab B gets a single SIGWINCH.)

Now, you switch back to tab A.  Tab A still has columns/lines C1xL1, and the window has the pixel size of a maximized window, which fits C1xL1 at tab A's font size.  So, gnome-terminal should not attempt to change the pixel size.  And since tab A's columns/lines don't change, tab A shouldn't get a SIGWINCH.

Why would the window's pixel size need to change when switching between two tabs whose current columns/lines fit the current pixel size?  gnome-terminal should never attempt a pixel size change in the first place, because it already has the correct pixel size for both tabs.

Now, let's talk about a non-maximized window.  Again, you have a pile of irrelevant tabs open so we don't have to think about the tab bar, and a tab A with size C1xL1.  You open a new tab B, which changes the window's pixel size to fit a terminal at the default size (e.g. 80x25) with the default font size.  Now you switch back to tab A.  gnome-terminal notices that the pixel size of the window doesn't match what C1xL1 at tab A's font size wants.  So, gnome-terminal changes the pixel size of the window back to the pixel size needed for tab A.  *However*, at no time does the columns/lines size of tab A need to change; tab A again should not need a SIGWINCH.

And, in fact, that matches the behavior I see from gnome-terminal for the non-maximized case: if I switch between tabs with different font sizes, and with different columns/lines, gnome-terminal changes the pixel size of the window to match what each tab needs for its font size and columns/lines, and never sends either tab a SIGWINCH.

But in the maximized case, gnome-terminal does send SIGWINCH when switching between tabs with different font sizes.  I assume this occurs because gnome-terminal doesn't recognize that it already has the right pixel size for the destination tab's font size and columns/lines, so it attempts a pixel size change, to which the window manager says "no, stay maximized" and changes the pixel size back.  Then gnome-terminal *also* doesn't notice that its new size results in the same columns/lines, so it sends a SIGWINCH.  Fixing either of those (the unnecessary pixel size change, or the unnecessary SIGWINCH for a WM pixel size change that doesn't change columns/lines) would address the issue, though it seems preferable to avoid the spurious pixel size change rather than just the spurious SIGWINCH.

> > Also, windows can know they're maximized, by way of EWMH.  But even that
> > shouldn't be necessary here.
> 
> I didn't know about it, I guess I should check it out.

See _NET_WM_STATE, and in particular _NET_WM_STATE_MAXIMIZED_VERT and _NET_WM_STATE_MAXIMIZED_HORZ.  But as explained above, you shouldn't need to care that the window is maximized; you just need to check whether the window already has the pixel size you need before changing that pixel size.
Comment 15 Josh Triplett 2015-09-17 23:29:02 UTC
(In reply to Egmont Koblinger from comment #13)
> Josh, while we're having this conversation, please please really do go
> ahead, and file bugreport for each app where the resize race condition
> causes problem for you, thanks! :)

Already doing that. See https://github.com/vim/vim/issues/424 in vim.
Comment 16 Egmont Koblinger 2015-09-18 06:58:50 UTC
Open a brand new gnome-terminal window (non-maximized), open a second tab. Now you have two tabs of the exact same logical size, same font, same pixel size.

Drag the corner of the window and resize it manually, make it let's say 100x50 (or whatever) instead of the original 80x24.

Now switch to the other tab. What do you expect to happen?
Comment 17 Egmont Koblinger 2015-09-18 07:07:18 UTC
> So here's a pseudo code implementing robust resize without race condition:

To be fair, let's mention this:

If you resize a window, and a while later resize it back to its previous size, it's fair if the inner contents slightly change. E.g. for a text editor/viewer the current scroll position might change. Maybe the cursor was near the bottom of the screen, and the window is made shorter in the first step. Then the viewport needs to be adjusted by the app so that the cursor is not offscreen. This obviously won't get restored if you later restore the window's previous size. Here it's irrelevant if restoring the previous size happens immediately afterwards or hours later. This is not different from any other apps (browser, word processor etc.)

So, upon a quick back-n-forth resize, it's acceptable from the app if it slightly changes its layout (typically the scroll position). But it should definitely not crash, not end up with a corrupt display etc.
Comment 18 Josh Triplett 2015-09-18 09:37:26 UTC
(In reply to Egmont Koblinger from comment #16)
> Open a brand new gnome-terminal window (non-maximized), open a second tab.
> Now you have two tabs of the exact same logical size, same font, same pixel
> size.
> 
> Drag the corner of the window and resize it manually, make it let's say
> 100x50 (or whatever) instead of the original 80x24.
> 
> Now switch to the other tab. What do you expect to happen?

I'd expect that when I manually resize the window, gnome-terminal recalculates the columns/lines of all tabs, and sends all those that change a SIGWINCH.  (The recalculation and SIGWINCH could either happen immediately or wait until the first switch to the tab; gnome-terminal appears to do the latter.)  And then when I switch between those tabs (after the first time if gnome-terminal delays the recalc and SIGWINCH), none of the tabs should change their columns/lines size (since the window already has the pixel size that satisfies every tab's font size and columns/lines), so none of them should send SIGWINCH.

Once a tab has adapted to its columns/lines size, subsequent switches to that tab should not send another SIGWINCH.
Comment 19 Egmont Koblinger 2015-09-18 09:53:01 UTC
Ok, I see.

Next question: what should happen if you have two tabs of different font sizes, and you resize the window manually? To what size should the other tab resize: to the same logical rowXcol size, or to the same physical size in pixels? (If the latter, what to do with the fact that probably the window size doesn't accomodate an integer number of cells without leaving a gap?)
Comment 20 Josh Triplett 2015-09-18 11:37:10 UTC
(In reply to Egmont Koblinger from comment #19)
> Ok, I see.
> 
> Next question: what should happen if you have two tabs of different font
> sizes, and you resize the window manually? To what size should the other tab
> resize: to the same logical rowXcol size, or to the same physical size in
> pixels? (If the latter, what to do with the fact that probably the window
> size doesn't accomodate an integer number of cells without leaving a gap?)

I don't care strongly about this one; I could see a case for either behavior there.

The only resizing-related behavior I care about there is that if I hit ctrl-plus in a non-maximized window, the pixel size should increase rather than staying the pixel size and having fewer columns/lines.  (I care about that case so that I can make an 80x25 terminal larger with ctrl-plus and have it stay 80x25.)
Comment 21 Egmont Koblinger 2017-10-26 14:12:30 UTC
In bug 789356 I just got to learn that – contrary to my earlier belief – gnome-terminal does actually know if it's maximized/fullscreen. (TODO: double check if it's true both for X11 and Wayland).

This means that I think it could implement different font sizing (or tab switching across different font sizes) strategy in that case, eliminating the back-and-forth SIGWINCH.
Comment 22 Simon McVittie 2017-10-26 14:23:27 UTC
(In reply to Egmont Koblinger from comment #21)
> In bug 789356 I just got to learn that – contrary to my earlier belief –
> gnome-terminal does actually know if it's maximized/fullscreen. (TODO:
> double check if it's true both for X11 and Wayland).

It does know this in both X11 and Wayland (grep for appropriate constants in Gdk), and there are also GTK+-specific hints/states for being tiled (half-maximized, or hypothetically, placed in a tiling window manager).
Comment 23 GNOME Infrastructure Team 2021-06-10 20:47:38 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7462.