wayland windows are resizable while explicitly disabled

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• First shot at using set_(min|max)_size (SDL-wayland-resizable-windows.diff, text/plain, 2019-11-15 05:34:58 +0000, 7665 bytes)
• updated patch (wayland.patch, text/plain, 2019-11-15 11:39:29 +0000, 7279 bytes)
• before trying to resize (sdl-before.png, image/png, 2019-11-15 11:42:45 +0000, 3126492 bytes)
• after trying to resize (sdl-after.png, image/png, 2019-11-15 11:43:32 +0000, 3705690 bytes)

Reported in version: 2.0.10
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2019-11-13 12:42:12 +0000, David Demelier wrote:

Hi,

On some window managers, using the Wayland backend the windows are resizable while it is explicitly disabled.

I've opened the issue at first on the sway repository because I thought the issue was in sway but with some discussion with developers they say that SDL lacks some internal information to disallow resizing in the sway compositor.

More information are available on the sway issue as well:

swaywm/sway#4710

On 2019-11-13 13:03:53 +0000, Kenny Levinsen wrote:

Just to clarify:

On Wayland when using xdg_shell surfaces, window size constraints are communicated to the compositor using set_min_size and set_max_size requests. Setting both min_size and max_size to the same positive non-zero value furthermore indicates that the window is non-resizable.

Based on debug logs from markands' application, it can be seen that these requests are never issued, which means that compositor will not impose any size constraints.

The symptoms of this issue differ between compositors. Windowed compositors like GNOME will present the option to resize, but it will never have effect. Tiling compositors like Sway will not use the appropriate fixed-size floating container, but instead use an always resizable tiling container (in which the content will just not resize with it).

If window size constraints are present, even for resizable windows, then min_size/max_size should be set appropriately. Based on how small the symptoms are under windowed compositors like GNOME, this is an understandable oversight.

Note that I have not verified the application that exhibited this issue, and cannot comment on its correctness with regards to use of SDL2's API. I am merely commenting on the Wayland protocol log, which lacked the necessary requests.

On 2019-11-15 05:34:58 +0000, Ryan C. Gordon wrote:

Created attachment 4048
First shot at using set_(min|max)_size

Here's a first shot at fixing this. I haven't even tried to compile this patch, so assume this isn't the final attempt on the topic.

This marks the min/max size of the window at creation time, if the window wasn't created with the SDL_WINDOW_RESIZABLE flag.

Since it uses the same interfaces, this also fills in Wayland support for SDL_SetWindowResizable, SDL_SetWindowMinimumSize, and SDL_SetWindowMaximumSize.

It's not clear to me if we have to wait for an initial configure event before setting a min/max, but I think not. We have code to deal with other details if this is necessary, but it's cleaner if we can just handle this in Wayland_CreateWindow() and be done with it.

Obviously this needs xdg_shell support (or zxdg_shell_v6 on older Wayland installs). If those are missing, SDL won't do anything here and you're at the mercy of the system.

--ryan.

On 2019-11-15 05:36:09 +0000, Ryan C. Gordon wrote:

I'm assigning this bug to myself, but I'd appreciate it if someone would try that patch and send in an update with any obvious mistakes fixed. :)

--ryan.

On 2019-11-15 11:39:03 +0000, David Demelier wrote:

Hello,

Your patch was almost correct, It looks like you forgot to use minw, minh, maxw, maxh because the compiler emitted some warnings. I fixed it. See the attached patch.

So it immediately opens in floating mode in sway which also indicate it's not resizable and I'm unable to resize it :-)

What's strange though, is that the configure shows a different size.

[ 76133.215] -> xdg_toplevel@25.set_min_size(500, 500)
[ 76133.224] -> xdg_toplevel@25.set_max_size(500, 500)
[ 76133.347] -> zxdg_decoration_manager_v1@11.get_toplevel_decoration(new id zxdg_toplevel_decoration_v1@26, xdg_toplevel@25)
[ 76133.360] -> zxdg_toplevel_decoration_v1@26.set_mode(2)
[ 76133.649] xdg_toplevel@25.configure(0, 0, array)
[ 76133.716] -> xdg_toplevel@25.set_title("test")
[ 76133.728] -> xdg_toplevel@25.unset_fullscreen()
[ 76161.773] xdg_toplevel@25.configure(500, 500, array)
[ 79188.413] xdg_toplevel@25.configure(496, 477, array)

In fact, I'm able to resize it a little bit to a smaller size which seems to be 496, 477. But after that I'm no longer able to resize it at all.

On 2019-11-15 11:39:29 +0000, David Demelier wrote:

Created attachment 4049
updated patch

On 2019-11-15 11:42:45 +0000, David Demelier wrote:

Created attachment 4050
before trying to resize

On 2019-11-15 11:43:32 +0000, David Demelier wrote:

Created attachment 4051
after trying to resize

On 2019-11-15 11:48:38 +0000, David Demelier wrote:

As you can see in the two screenshots. The first one is correct, the window has the good size and starts floating (which sway does when windows are not resizable).

On the second screenshot, you can see that the SDL view exceeds the sway window frame a little bit after have tried to resize it. And I suspect this is because there are different configured sized as shown in my previous comment (496x477 vs 500x500). Looking at the black borders exceeding the frame it looks to be the case. Afterwards, it's impossible to resize it at all.

[flibitijibibo]

Ended up implementing a patch similar to Ryan's in #4065.