Electron apps with --ozone-platform-hint=auto report incorrect frame sizes (causes smaller window / large border)

[trolljoe]

Describe the bug
Almost all electron apps (discord, vscode) have a huge border around them, unlike on firefox, which is the normal size

To Reproduce
Steps to reproduce the behavior:

1. Open an electron app
2. See the border

Expected behavior
The border should follow the same size as firefox or any app.

Screenshots


The first image shows how it's supposed to look like (on the firefox tab), second image shows how it's actually looking like

System information:
Distribution: Void Linux x86_64 glibc
GNOME Shell: 46.2
Display server: Wayland
PaperWM version: 46.17.0
Enabled extensions:

• paperwm@paperwm.github.com
• arcmenu@arcmenu.com
• dash-to-panel@jderose9.github.com
• appindicatorsupport@rgcjonas.gmail.com

[Plyply99]

Why is Discord app smaller? What you are seeing is the border that goes behind window. For what ever reason your Discord app is smaller. I checked Discord on my system and it's fine.

[trolljoe]

Why is Discord app smaller? What you are seeing is the border that goes behind window. For what ever reason your Discord app is smaller. I checked Discord on my system and it's fine.

even when fullscreened, and no other apps opened, discord still has the huge border around it. i don't think my discord app is "smaller", if you mean the zoom i did by pressing ctrl +, that shouldn't be an issue anyways

and if you looked at my issue, i mentioned that this isn't just discord, all electron apps are behaving the same.

[trolljoe]

my current "workaround" for this is to just disable window borders, but even then, the discord window has a lot of free space remaining compared to firefox

[jtaala]

my current "workaround" for this is to just disable window borders, but even then, the discord window has a lot of free space remaining compared to firefox

Hey @trolljoe - I can't reproduce this and am not seeing this for any of my electron based apps.

This appears more like an app scaling issue rather than a border issue (e.g. borders are just a coloured background clutter element that well-placed behind an application). A couple of questions to see if we can isolate this one:

• are you running a hidpi display (e.g. dpi scaling other than 100%?);
• do you have any chromium flags (e.g. any ozone params in chromium-flags.conf etc.?) - or any ozone or xwayland related config that could impact electron apps?

That last one, reminds me of #905 (in that one, chromium itself isn't honouring it's own window.frame dimensions that paperwm uses in sizing windows).

Let us know when you can re any of the above.

@Lythenas - you ever see something like this for electron apps on your setup?

[trolljoe]

hey, i'm not running a hidpi monitor, but i'm running an ultrawide, no scalling. i can't tell for sure if i have chromium flags since it's a flatpak. i cannot check right now but i'll edit once i can. and yeah, seems similar to #905, even mentioned he's also running ultrawide.

EDIT: flatpak passes these flags to discord: Passing the following arguments to Electron: --enable-speech-dispatcher --ozone-platform-hint=auto. i have since fixed the issue by using flatseal to force run on x11.

[trolljoe]

i still don't know if this is a viable workaround though, so i won't close it yet unless you guys decide to.

[jtaala]

The flatseal approach is certainly a good workaround for flatpak apps that have (still) misbehaving wayland integration in Gnome.

Disabling socker=wayland forces it to run in xwayland - which is/has been the default. Looks like some apps in gnome still have issues with native wayland app modes.

Main issue is that some apps (chromium, vesktop) when run in native wayland mode (not xwayland) are reporting incorrect window frame sizes (which PaperWM) uses.

[jtaala]

Note: so far with my electron apps only, vesktop is affected by this (likely because of flatpak passing those ozone args) - but given this, it's likely to impact other apps.

P.S. this seems quite related to flatpak apps (passing those args) for some apps that aren't quite ready for native wayland mode (as opposed to xwayland) in gnome. I'll update the title and might pin this.

[jtaala]

@trolljoe - is this happening for any of your (if you have them) non-flatpak electron apps?

[trolljoe]

@trolljoe - is this happening for any of your (if you have them) non-flatpak electron apps?

nope, all non flatpaks render fine. i don't think it's vesktop exclusive as the official discord client also gave weird borders unless on xwayland. so i assume it's an issue with flatpak passing those flags

[trolljoe]

@trolljoe - is this happening for any of your (if you have them) non-flatpak electron apps?

nope, all non flatpaks render fine. i don't think it's vesktop exclusive as the official discord client also gave weird borders unless on xwayland. so i assume it's an issue with flatpak passing those flags

ok so i double checked, and i installed vscode from the official void linux repo, and the issue is not present there.

[jtaala]

Thanks @trolljoe - doesn't just affect paperwm, even in vanilla gnome the window (with those flags passed) acts very strangely - like it has invisible border that stop it from being moved to the top of screen, e.g:

Screencast.from.2024-09-04.07-27-28.webm

Definitely an upstream issue - hopefully Gnome 47 might address or improve the situation with applications running in native wayland (not xwayland) in mutter / gnome.

Closing this one.

P.S. I've pinned this issue as it contains a valid workaround until the upstream situation improves.

[trolljoe]

i have actually found another workaround which works on wayland natively, but it's specific to discord.

if on vesktop, you can go to settings > vesktop settings > enable discord frame

that fixes the border issue, but doesn't follow adwaita