Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window is not resizable in 1.11.80 build #477

Open
tomhughes opened this issue Oct 14, 2024 · 8 comments
Open

Window is not resizable in 1.11.80 build #477

tomhughes opened this issue Oct 14, 2024 · 8 comments

Comments

@tomhughes
Copy link

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
Copy link
Collaborator

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
Copy link
Author

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

image

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
Copy link
Collaborator

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
Copy link
Collaborator

SISheogorath commented Oct 14, 2024

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
Copy link
Author

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
Copy link

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
Copy link
Author

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

@konomikitten
Copy link

Is this possibly related to electron/electron#43714?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants