Fullscreen window gets tiled after show/hide

[burunduk3]

Problem Description

When using media viewer in Telegram Desktop for the first time, everything works fine. Media viewer is just a fullscreen window with, for example, a photo. For the second and following times xmonad instead of placing the media viewer window (which, again, is supposed to be a fullscreen one) above others puts it into the tiling, and that is an issue.

Unfortunately, it's not clear to me where the problems arises (in telegram itself, in Qt it uses, somewhere in X11 layer or really in xmonad, the latter means I've created this issue in the right place).

The tricky thing Telegram does is hiding/showing a media view windows instead of creating a new one from scratch every time. One may investigate how its media view overlay widget plays around isHidden. I'd expect this to result in calls to xcb_unmap_window/xcb_map_window, which is then transferred to xmonad as x11 events.. So looks like xmonad incorrectly deals with hiding/showing fullscreen windows.

I'm using gentoo with xmonad-0.15.

Configuration File

This is reproducible even on my minimal xmonad config:

import XMonad

main = xmonad defaultConfig {
  terminal = "konsole"
  , modMask = mod4Mask
}

I see from discussion in issue #54 that fullscreen windows may require some additional configuration, but the issue here is difference between first and latter appearances of the media viewer. If configuration was the issue, the first try will not work either.

Checklist

• [yes] I've read CONTRIBUTING.md

• [no, just a minimal config is enough] I tested my configuration with xmonad-testing

[geekosaur]

I wonder if this is related to the resize issue I've brought up (but don't see offhand in the issue tracker) about floating windows getting resized by the default border width by X.O.windows, so it's no longer exactly fullscreen on subsequent mappings.

[geekosaur]

To be more clear on this, xmonad automatically floats any window which is full screen. But if on a subsequent remapping it is not exactly fullscreen, this won't happen any more. This can sometimes be caused by xmonad, but also sometimes by applications which don't take the window border into account properly.

[burunduk3]

xmonad automatically floats any window which is full screen

How does it determines full-screenness of the window? According to xprop, the one from telegram has _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_MODAL, so the full screen flag is set. And this doesn't change between first and other shows of the window.

If the border makes a difference, does that mean that xmonad considers window as a full screen by its dimensions (so the it should be a rectangle (0, 0, resolution_x, resolution_y) or something like that)?

Also, where does this border comes from? Not sure what "X.O.windows" are. I'd expect that full screen windows don't have any borders.

Do I understand correctly that possible scenario is:

1. Telegram creates a new full-screen window.
2. From xmonad's perspective it's actually full-screen, according to the dimenstions.
3. Telegram hides that window.
4. Telegram shows the windows again.

And, somewhere before the step 4 window size was changed?

[geekosaur]

The built-in rule compares the pixel size of the window to the pixel size of the screen. Xmonad doesn't speak EWMH by default, so _NET_WM_STATE_FULLSCREEN requires XMonad.Hooks.EwmhDesktops configured including the fullscreen support.

Xmonad uses the internal window border to indicate that a window is focused. It does this even for full screen windows, although there are some ways around this — but I said "default border" for a reason, those ways won't help because the window's size is computed using the default border before anything can disable it.

X.O.windows is short for the function XMonad.Operations,windows which deals with this and other aspects of window placement and screen rendering.

[burunduk3]

Thanks for clarifying, @geekosaur!

Is there a way to check this? Like, for example, print windows size in some debug log when it appears?

[geekosaur]

I have a number of debugging functions available including one that captures manageHook and window data for the next window to be mapped in XMonad.Hooks.ManageDebug.

What this comes down to, however, is that we inherited maintenance of a window manager whose floating window story is an ugly hack that is quite brittle, and I'm not that surprised that it's breaking here.

[kanashimia]

Even using hook from XMonad.Hooks.EwmhDesktops doesn't seem to work.
Adding isFullscreen -?> doFloat to manage hook fixes the issue, definitely needs further investigation.

Window preview wobbling, while tiled, is an unrelated? issue caused by telegram desperately trying to stay in the full screen - when you try to resize it, it tries to resize that window back.

[burunduk3]

preview wobbling

Yep, that's exactly how I found the issue. Wobbling is telegram's weird reaction to resize/move of the window which meant to be fullscreen one.

So EwmhDesktops doesn't add this fullscreen hook by itself (via its config-patching ewmh function), right?

[liskin]

To prevent Telegram windows from moving themselves, one might use my floatConfReqHook which intercepts ConfigureRequestEvents and ignores them if they match a Query:

https://github.com/liskin/dotfiles/blob/home/.xmonad/xmonad.hs#L290-L295
https://github.com/liskin/dotfiles/blob/home/.xmonad/xmonad.hs#L265-L269
https://github.com/liskin/dotfiles/blob/home/.xmonad/xmonad.hs#L283

So EwmhDesktops doesn't add this fullscreen hook by itself (via its config-patching ewmh function), right?

Yes, fullscreen handling isn't enabled by default. I think we might reconsider that default, but then a lot of people actually don't want fullscreen requests to be honored, so we may just stick to keeping backward compat and just making it somewhat easier to enable correct fullscreen handling.

[kanashimia]

Yes, fullscreen handling isn't enabled by default. I think we might reconsider that default, but then a lot of people actually don't want fullscreen requests to be honored, so we may just stick to keeping backward compat and just making it somewhat easier to enable correct fullscreen handling.

Just to be clear:
EwmhDesktops has fullscreenEventHook (or even ewmh' def{ fullscreen = true } under the ongoing ewmh refactor), and problem is that it doesn't fix the behaviour for some reason?
But specifying manage hook, to explicitly float all fullscreen windows, works.🗿

Also there shouldn't be any concerns about backwards compatibility with ewmh' so maybe fullscreen = true should be the default for it?
But would cause confusion with having different defaults, indeed.

[liskin]

Just to be clear:
EwmhDesktops has fullscreenEventHook (or even ewmh' def{ fullscreen = true } under the ongoing ewmh refactor), and problem is that it doesn't fix the behaviour for some reason?
But specifying manage hook, to explicitly float all fullscreen windows, works.

Oh, that's a good observation! So I guess that Telegram isn't fullscreening an existing window but rather opening a new one, and then a manage hook is needed instead. Perhaps ewmh/ewmh' should set this manage hook, but then we'd need a way to disable that. But we should definitely do something: either set the hook or mention the manage hook in documentation. Thanks for the nudge. 👍

Also there shouldn't be any concerns about backwards compatibility with ewmh' so maybe fullscreen = true should be the default for it?
But would cause confusion with having different defaults, indeed.

I quite like this suggestion actually. :-)
We'd clearly say that ewmh is a legacy wrapper that preserves original syntax and behaviour, and set the new defaults to something sensible.

[kopr12]

I have this issue with mpv, you watch something and if you press 'f' or double click the window it goes fullscreen, but it's not a 'real' fullscreen, when you get out of it everything is well (before going FS it's float and exiting the FS it's float) , I mean in config I have set mpv to be float, also I have isFullscreen --> doCenterFloat hook, anyway I was bothered why it isn't a real FS, because I had that in dwm for example so I know it's not mpv, now I knew Xmonad is complicated regarding FS for some reason so I read man page for mpv and there's this option --x11-netwm=<yes|no|auto> , so if I give mpv that flag and set it to yes, then it's a real FS, but on exit the window gets tiled. Really weird.

btw man page for mpv and this option mention Xmonad, in bad way I think

--x11-netwm=<yes|no|auto>
(X11 only) Control the use of NetWM protocol features.

          This may or may not help with broken window managers. This provides some functionality that was implemented by the now removed --fstype option.  Actually, it is not known to the developers to which degree this  option
          was needed, so feedback is welcome.

          Specifically,  yes will force use of NetWM fullscreen support, even if not advertised by the WM. This can be useful for WMs that are broken on purpose, like XMonad. (XMonad supposedly doesn't advertise fullscreen sup‐
          port, because Flash uses it. Apparently, applications which want to use fullscreen anyway are supposed to either ignore the NetWM support hints, or provide a workaround. Shame on XMonad  for  deliberately  breaking  X
          protocols (as if X isn't bad enough already).

          By default, NetWM support is autodetected (auto).

          This option might be removed in the future.

[kopr12]

Also tried latest git and used ewmhFullscreen , same thing, except I don't need to use the switch with mpv

[kopr12]

I managed to get it kinda solved by changing in EwmhDesktops.hs this line windows $ W.sink win with windows $ W.float win $ W.RationalRect (1/6) (1/6) (2/3) (2/3), kinda because I already have mpv floating as a rule, problem is if you go fullscreen with some tiled window, then on exiting you will get centered floating window.

What this problem needs is storing the window state and x,y,w,h before going fullscreen and then restoring that on exiting the fullscreen

[mikenrafter]

This can (theoretically) be solved by using X.L.Magnifier, sinking the window, tagging it as floating before, then re-floating it upon an untag.
It won't remember the exact floating details from before, but I'm sure that could be added in semi-trivially.
This' all possible with a modified X.L.Magnifier, which I'm currently implementing.

EDIT: the magnifier portion is complete (mostly?) - now time for the floating tag and state.
EDIT2: magnifier and logHook complete, now time to save floating window rectangles in state, and handle the changes.