Created attachment 7388 Fullscreen problem I migrated to xfwm4-git (g80453816, Xpresent and Epoxy enabled) and Terminal does not go fullscreen anymore. See attached screen capture. This is an Arch system, using up-to-date XFCE 4.12 stack (xfce4-terminal 0.8.6 compiled with VTE3/GTK3). Intel GM45, Xorg modesetting driver. Besides appearance tweaks (font, colors), the only customization I have is GTK_OVERLAY_SCROLLING=0.
Sounds like an xfwm4 bug to me.
Does gnome-terminal have the same fullscreen problem under xfwm 4.13? Does fullscreen work as expected under xfwm 4.12?
(In reply to Igor from comment #2) > Does gnome-terminal have the same fullscreen problem under xfwm 4.13? Sorry, I am using the wrong word! Fullscreen (F11) is working. This is when I maximize the window. Other apps like Chromium, Firefox, Mousepad, Thunar, Ristretto are fine. Yes, GNOME Terminal is also exhibiting similar problem when maximized (capture attached). > Does fullscreen work as expected under xfwm 4.12? Yes, XFCE Terminal window was fine when maximized in xfwm 4.12.
Created attachment 7389 GNOME Terminal maximized
I have updated my Arch system to the latest git version of xfwm4, and both fullscreen and maximized modes are fine here. $ xfwm4 --version This is xfwm4 version 4.13.0git.80453816 (revision 80453816) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.31, using GTK+-2.24.31. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes
Actually, I think I know what you're talking about: I can see small gaps between the panel (which I have at the bottom of the screen) and the lower border of the terminal window, as well as between the right side of the screen and the right window border. The bottom gap is bigger when the terminal window has only one tab, and is really tiny with two tabs. The same happens when maximizing gnome-terminal and xterm windows. I'm not sure whether there is something that can be done from the terminal side.
In xfwm 4.12 there was no gap at all. What changed in xfwm 4.13?
Created attachment 7391 Video showing the problem
> What changed in xfwm 4.13? Apparently it started to respect geometry hints (resize increments) in maximized mode rather than ignoring it. I don't find this a wise idea, I think it's better if it ignores the geometry hints in maximized mode (there's a reason it's called "hints" and not "rules") and truly maximizes the window. > I'm not sure whether there is something that can be done from the terminal side. Not really, I'm afraid.
> > What changed in xfwm 4.13? > Apparently it started to respect geometry hints (resize increments) in > maximized mode rather than ignoring it. I don't find this a wise idea, I > think it's better if it ignores the geometry hints in maximized mode > (there's a reason it's called "hints" and not "rules") and truly maximizes > the window. Yeah, that would explain why tilix is not suffering from this problem - because it isn't setting geometry hints. > > I'm not sure whether there is something that can be done from the terminal side. > Not really, I'm afraid. If only unset geometry hints when going into maximized mode... don't think I like this idea, though.
(In reply to Igor from comment #10) > Yeah, that would explain why tilix is not suffering from this problem - > because it isn't setting geometry hints. Which totally makes sense for them. As soon as you have anything more complex layout than a single terminal, or a few terminals next to each other (all along one axis) all having the same font size, geometry hints can no longer be properly defined. > If only unset geometry hints when going into maximized mode... don't think I > like this idea, though. We're just working on fixing gnome-terminal for wayland/gnome-shell/mutter, there's tons of bugs with geometry there. See e.g. https://bugzilla.gnome.org/show_bug.cgi?id=789356 and tons of other bugs linked from there. I can't yet see what solution we'll settle with. Once we figure out, you might want to consider following us. Eventually at some point perhaps people will start using xfce4-terminal over wayland/gnome-shell/mutter/etc. (rather than xfce4 environment). During these discussions I was surprised to learn that it _is_ communicated to the app (xfce4-terminal) if it's in maximized state. So technically yup you could uninstall geometry hints then and restore again when unmaximized. What I'm not sure about is whether it's too late then or not. E.g. it could be that xfwm4 maximizes leaving that gap, then you remove the geometry hints, but then it doesn't decide to enlarge it even further to fill the gap. Don't know, you should try, and of course expect anything you change to fix the behavior in a few window managers and in the mean time break it in some others :P I can fully understand you if you don't feel like killing time with this. I guess xfwm4 developers should be looped in here whether it was an intentional change on their side, what was its rationale, and whether they'd be okay with reverting.
This isn't new at all, xfwm4 has always supported geometry hints of course, but it would ignore resize increment for maximized or fullscreen windows, on purpose, precisely to avoid this issue... So this is a regression, most likely introduce by commit aee8b25 (https://git.xfce.org/xfce/xfwm4/commit/?id=aee8b25). Can you try w/out this commit?
Reverting aee8b25 solves the issue!
Yes, reverting the specified commit seems to have fixed the issue for me. Thanks, Olivier. Marcos, thanks for reporting this!
(In reply to Egmont Koblinger from comment #11) > We're just working on fixing gnome-terminal for wayland/gnome-shell/mutter, > there's tons of bugs with geometry there. See e.g. > https://bugzilla.gnome.org/show_bug.cgi?id=789356 and tons of other bugs > linked from there. I can't yet see what solution we'll settle with. Once we > figure out, you might want to consider following us. Eventually at some > point perhaps people will start using xfce4-terminal over > wayland/gnome-shell/mutter/etc. (rather than xfce4 environment). Egmont, thanks for referring to this bug. I'll need to find some time to read through it and related bugs.
Olivier Fourdan referenced this bugreport in commit 54db88acb7e1988d5c39722d639a0347c99fd7b0 Fix maximized size increment regression https://git.xfce.org/xfce/xfwm4/commit?id=54db88acb7e1988d5c39722d639a0347c99fd7b0
Commit 54db88ac does not fix it completely. Sometimes (let's say 2 in 10 attempts) I need to click twice on the maximize button, see attached video. This is xfwm4 version 4.13.0git.6a44ecc3 (revision 6a44ecc3) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-3.22.26, using GTK+-3.22.26. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No
Created attachment 7475 Video showing the problem 2
Olivier Fourdan referenced this bugreport in commit 87cbe0e3d01d467c14aa2bb4d3656bf6b39a4247 client: Make sure to redraw when removing maximized https://git.xfce.org/xfce/xfwm4/commit?id=87cbe0e3d01d467c14aa2bb4d3656bf6b39a4247
For some reason, I fail to reproduce the issue here. But from the screencast, that looks like the client is issuing a ConfigureRequest by itself, which lead to the window being un-maximized. I think this particular issue is a client issue, not related to commit aee8b25. But that shows another issue with repainting the frame...
Thank you, Olivier. Now the window is not glitched anymore. Igor, what do you think? I still get erroneous behaviour (last screencast) sometimes, not always.
xfce4-terminal itself only configures size hints once. Then GDK makes XResizeWindow call each time window gets maximized which probably causes ConfigureRequest. I'm not sure GTK developers can do anything with this.
> For some reason, I fail to reproduce the issue here Running xfwm4 4.13.0git.02a795fc and xfce4-terminal 0.8.6, the problem is reproducible only sometimes (perhaps a race condition?). For me this works to reproduce the issue: 1. Open a new terminal window 2. Maximize it 3. Restore it 4. Repeat steps 2. and 3. At some point (usually after 5-6 iterations) the problem will appear.
P.S. VTE3 version is 0.50.2 and GTK3 version is gtk3 3.22.26+47+g3a1a7135a2.
I(In reply to Andrey Vihrov from comment #23) > 1. Open a new terminal window > 2. Maximize it > 3. Restore it > 4. Repeat steps 2. and 3. > > At some point (usually after 5-6 iterations) the problem will appear. I can confirm the issue on my Arch machine with xfwm4-git and xfce4-terminal-git.
Olivier Fourdan referenced this bugreport in commit 11421dc28cf3a4ea6598eb32f48dc39da2c078db client: Make sure to redraw when removing maximized https://git.xfce.org/xfce/xfwm4/commit?id=11421dc28cf3a4ea6598eb32f48dc39da2c078db
I'm still experiencing maximize/unmazimize problems with xfwm4 4.13.0 and 4.13.1. When opening a new terminal window and starting to maximize/unmaximize it, after a number of repetitions (from 2 to say 10 or 15) the window wouldn't unmaximize. This happens with the current versions of xfce4-terminal and gnome-terminal. Reverting to xfwm4 4.12.5 solves the issue.
Created attachment 8199 video showing this bug on b1248a7
Created attachment 8200 this patch fixes bug, applied to b1248a70
I still have this bug with xfwm4 from master running on Arch Linux. I fixed it by reverting changes in client.c file made in aee8b25a ( Do not prevent ALT+Mouse resizing for borderless maximized windows. ). I sent video showing the bug and patch file which is completely fixing this bug on my machine.
Except that attachment 8200 is not correct, it's reverting partially commit aee8b25a so it will most deny resize for bordeless maximized windows. I suspect we're fighting against a broken client which sends us configure requests when maximizing because of size increments or something. I reiterate my call to drop size increments in xfce4-terminal. Can you reproduce with, say, konsole?
Olivier, xfce4-terminal isn't the only one doing that - gnome-terminal is another example. I don't agree the behavior is "broken" - this is something that terminal emulators have been doing for years, and xfwm4 used to support that.
xfwm4 still supports that, but the client is sending us a ConfigureRequest which means basically “resize me”, in which case xfwm4 rightfully removes the maximized state whenn a client resize itself. The behavior described is typical of a race condition when clients fight against the window manager. Previously, we would simply deny the resize for maximized windows, whereas now with aee8b25a we allow the client to resize itself, so this bug shows.
You could narrow the scope to find the culprit: Does it show with xterm? Does it show with gnome-terminal? Does it show with tilix? If it shows with gnome-terminal and xfce4-terminal, but not in tilix then it's probably a bug related to vte and the use of size increments. If the bug shows in xterm, then it's a bug in xfwm4.
Tilix and Konsole don't do any geometry hints, thus should be irrelevant. VTE doesn't do any geometry hints either anymore, GTK+ removed the possibility of a widget defining resize hints. All that VTE does is that it provides the necessary information (cell size and count) towards the terminal emulator application, which then adds the chrome size and sets up the hints accordingly for the window. So as far as let's say xfce4-terminal and gnome-terminal are concerned, VTE being a common part of them is most likely irrelevant, what could matter is that they both use GTK+ to set up the hints. Maybe it could provide more information and more basis for bisecting to check the behavior of non-GTK-based apps that do geometry hints, such as xterm, urxvt, terminology, st.
Olivier Fourdan referenced this bugreport in commit 3751c2c716714f84dd3d527b60f3543e96fac54e events: ignore client configure requests when maxized https://git.xfce.org/xfce/xfwm4/commit?id=3751c2c716714f84dd3d527b60f3543e96fac54e
Thank you, Olivier!
@Olivier, @Igor it seems the issue has been settled, can we close this bug?
Sure.
Olivier Fourdan referenced this bugreport in commit 34ff3e1fe027b4005c284fcaf5235e6686cf35fc client: ignore configure requests when maximized https://git.xfce.org/xfce/xfwm4/commit?id=34ff3e1fe027b4005c284fcaf5235e6686cf35fc