Window is not resizable in 1.11.80 build

[tomhughes]

I updated to the 1.11.80 build and found the window now appears to have a fixed size (roughly 1200x800) and can't be resized.

Downgrading to the previous build has restored the ability to resize.

I would also note that even the previous version has a weird issue with resizing where it won't let you move an edge too close to the edge of a monitor - it has some sort of buffer strip that it won't allow you to move into. That started happening a couple of months ago.

[SISheogorath]

Is it similar to #332 or is different?

Could you provide some details like your desktop environment along with versions and maybe a screenshot to make the problem more visual?

[tomhughes]

I'm running Fedora 40 with the default Gnome Wayland desktop. The border issue basically comes down to this:

which is as close as I can drag any edge of the element window to the edge of the monitor.

In 1.11.80 there are simply no drag handles at all when I hover over the window edge, but only in the flatpak version - if I use the tar ball version that it is resizable as normal.

[SISheogorath]

Mhm, interestingly enough, running the latest Fedora Silverblue 40, I can't reproduce this, but I also can't resize the window (which I usually also don't test before merging) 👀 So something is off.

[SISheogorath]

I think you can probably change window behaviour drastically, when you disable wayland using tools like flatseal.

You can also temporarily test if it fixes the issue using:

flatpak kill im.riot.Riot
flatpak run --nosocket=wayland im.riot.Riot

This also explains, why it's a non-issue with upstream, since upstream doesn't enable wayland by default. You can see we jump through some hops to make it happen in the flatpak:

im.riot.Riot/element.sh

Lines 3 to 14 in d32d14a

	FLAGS=''
	if [[ $XDG_SESSION_TYPE == "wayland" && -e "$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" ]]
	then
	FLAGS="$FLAGS --enable-wayland-ime --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations,WebRTCPipeWireCapturer"
	if [ -c /dev/nvidia0 ]
	then
	FLAGS="$FLAGS --disable-gpu-sandbox"
	fi
	else
	FLAGS="$FLAGS --enable-features=WebRTCPipeWireCapturer"
	fi

[tomhughes]

The interesting thing is that I also use a (non-flatpak) vs code and I pass --ozone-platform-hint=wayland --enable-features=WaylandWindowDecorations to that to get wayland support and it doesn't have any of these issues.

[konomikitten]

On Debian Unstable under GNOME 47 running with Wayland if I use flatpak run im.riot.Riot --ozone-platform=x11 the problem goes away. If I use flatpak run im.riot.Riot --ozone-platform=wayland --enable-features=WaylandWindowDecorations the problem occurs. My flatpak version of Element is 1.11.81.

Could people please specify their Distro, Desktop Environment and Element versions so we can better understand what circumstances are causing this bug?

[tomhughes]

I can confirm that matches what I see on Fedora 40 with Gnome 46 and Element 1.11.80 or newer.

[konomikitten]

Is this possibly related to electron/electron#43714?

[tomhughes]

I'm now seeing this in vs-code since a recent update so it seems likely it is indeed an electron issue.