Winit: Gnome Wayland decorations behind system bar

[chrisduerr]

It seems like somewhere between the version glutin master currently uses (0.20.0-alpha4) and the latest master, the window decorations on Wayland with gnome have been broken.

Previously when starting a maximized window, the window bar would be visible, as it should be. However with the latest master, the window is 'offset', so the top of the screen is the top of the inner window (no decorations) and the decorations are behind the system bar.

This might be better explained with the screenshots from the original Alacritty issue: https://github.com/jwilm/alacritty/issues/3070

[Will-W]

I was the original reporter on alacritty and I'm happy to continue to help diagnose and try things.

[goddessfreya]

@Will-W Can we get a git bisect for which commit breaks stuff?

[real-or-random]

I have the same issue, and for me it really depends on the shape of the gnome bar. If I use a theme (like the default Adwaita) where the gnome bar is rectangular with no margin around it (i.e., it starts at 0,0 and fills an entire rectangle like an ordinary window, then alacritty's position is correct). If I use a theme where the gnome bar has round edges and is positioned in the middle with margin around it, then alacritty's position is behind it.

It's hard to tell from the screenshots here which theme is used. It could be the case that there are round edges too, and they're simply not visible due to a black background.

[real-or-random]

Sorry, ignore my comment. I was under a wrong impression. This happens independently of the theme.

[Will-W]

Sorry for the delay - I've been away. I've run a bisect and the offending commit is 72fc6a74ec3da62355bacf860950e03b42dbd11b "on Wayland, drop resize events equal to the current window size".

Makes sense how that might have broken it.

[goddessfreya]

cc @kchibisov.

[kchibisov]

I'll take a look on it during the week. You'll never know how GNOME WAYLAND surprises you next time...

[vberger]

Looking at this commit, I suspect the issue is that frame.resize(..) should be called in all cases, and not only when newsize != *size, as SCTK internally redesigns the window geometry and I would not be surprised if Gnome relied on this to check that the window correctly responded to the maximization request.

I don't have a Gnome session to test it though.

[almindor]

I was hoping I could maybe test this but the fullscreen example (not even sure if that's the correct thing tho) does not work for me at all with wayland. Bordeless gives me a running app but nothing visible at all.

UPDATE: I tried the glutin example for fullscreen but it's not fullscreen :D

[Will-W]

My original tests, and the bisect I ran used http://github.com/chrisduerr/glutin . That's a fork of rust-windowing/glutin that tracks more recent winit. I was using the window example adding a .with_maximized(true) to the builder. @almindor it's maximized not fullscreen that's relevant here.

I have just tried a similar thing with winit directly, but none of the examples I tried (modified or unmodified) produced any visible output. Something appears in the alt-tab menu, but no window that I could see. I don't know what the expected behaviour is (this is still Wayland/Gnome/Fedora, tested on both 29 and 30).

[almindor]

@Will-W thanks I'll test with that. NOTE: winit examples alone won't produce anything on wayland (this is apparently a known issue) you need to run something that draws to the window to get any output in wayland.

[almindor]

This is what I get when using the "window" glutin example modified to maximize. You can see that there's a bottom offset so different behavior but still wrong. NOTE: fullscreen examples are broken for me, I get a 1/4th-ish sized window on them instead, but since that's probablty a different issue I'll open a new one for that.

[Will-W]

From that screenshot, that looks like the same (incorrect) behaviour that I originally reported (screenshot). And thanks for the info about Wayland, that makes sense.

[kchibisov]

Just to confirm what I see according to my testing with Fedora 31 and 3.34.x. The issue is only about with_maximized(true), right? Since I can't trigger it after just by maximize/fullscreen, etc on window. It shows up only with with_maximized(true) (startup_mode: Maximized in alacritty).

[Will-W]

Yes, any later resize behaviour seems to work correctly. It's just the
attempt to start maximized that has an issue (in my testing).

On Tue, 17 Dec 2019 at 21:30, Kirill Chibisov [e-mail]
wrote:

Just to confirm what I see according to my testing with Fedora 31 and
3.34.x. The issue is only about with_maximized(true), right? Since I
can't trigger it after just by maximize/fullscreen, etc on window. It shows
up only with with_maximized(true) (startup_mode: Maximized in alacritty).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-windowing/winit/issues/1312?email_source=notifications&email_token=AAHTQ7HABHQ7M546NLRSQILQZFAIDA5CNFSM4JXBXTQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHEASLA#issuecomment-566757676,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHTQ7H3C33NVIEUXDBXWBLQZFAIDANCNFSM4JXBXTQA
.

[vberger]

It'd help to have a wayland trace of what happens, this can be done by setting the env variable WAYLAND_DEBUG=1, and the trace will be dumped to stderr.

[Will-W]

Here's the debug trace:
maximized.txt

And the same test but without with_maximized(true), in case that's of any use for comparison:
non_maximized.txt

Command run was WAYLAND_DEBUG=1 cargo run --example window > maximized.txt 2>&1 in master of https://github.com/chrisduerr/glutin .