mullvadvpn-app
mullvadvpn-app copied to clipboard
mullvad
Support Wayland natively
Wayland is more and more replacing X. More and more people want to run a Wayland native desktop. Most Linux GUI programs run well under Wayland these days. This issue is for tracking the Wayland support in the Mullvad VPN app GUI.
Current status
The latest stable release, 2021.5, runs on Electron 11. There is no Wayland support in Electron 11, it was introduced in Electron 12.
The master branch in this git repository is using Electron 15. So the next release we make will support Wayland. However, you will need to supply some rather long arguments to the app to make it start in native Wayland mode:
/opt/Mullvad\ VPN/mullvad-vpn --enable-features=UseOzonePlatform --ozone-platform=wayland
Goal
In a future release we hope to modify /opt/Mullvad VPN/mullvad-vpn in such a way that it will automatically detect if Wayland is being used, and then automatically add the arguments needed to run the app in native Wayland mode.
On F35/GNOME 41, using fractional scaling: Works fine, but titlebars missing and cursor way too small, both of which are already being worked on upstream IIRC https://imgur.com/7WFlRk6
I believe the missing titlebars is related to this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 GNOME Wayland doesn't support server-side decorations, so if client-side decorations aren't implemented in an application running in that environment, the titlebar will be missing.
I believe the missing titlebars is related to this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 GNOME Wayland doesn't support server-side decorations, so if client-side decorations aren't implemented in an application running in that environment, the titlebar will be missing.
Yeah, looks like support is being worked on in election itself though. https://github.com/electron/electron/pull/29618
I am having some small and strange difficulties using the Mullvad GUI app with Wayland on KDE (KDE Plasma version 5.23.5, KDE Frameworks version 5.90.0, Qt version 5.15.2) on OpenSUSE Tumbleweed (rolling release up to date, kernel 5.16) I know Wayland is not officially supported yet, and on top of that I am running the .rpm on OpenSUSE instead of Fedora, but here goes:
With the titlebar on the bottom of the screen, as is standard for most systems and people, clicking the systray icon to open the app works fine. However, when moving the taskbar to the left side of the screen, this almost never works. Only rarely it works and I can't explain why. When it doesn't work, you can still see the icon being depressed visually, so the click is registered at that place, but opening the app doesn't happen. Opening it via the regular KDE launcher menu works fine always. Even stranger: sometimes when you click the application launcher ('start') menu (top left, while the systray is bottom left), it opens the Mullvad app instead of the menu. It appears as if there is some invisible yet clickable layer over the launcher button which opens the Mullvad app. Again, this does not happen consistently... Quite frustrating when it happens, and also to reproduce. However it does happen on two machines of mine with totally different hardware (Intel with iGPU, and Ryzen with Radeon GPU), so it's not completely random.
Once open everything in the app works fine by the way.
I understand that this is not something you can fix now, fix easily, or maybe you can't fix it at all, but all I ask is that when making the transition to a Wayland-compatible GUI, you test the clicking of the icon in the systray with the taskbar in various locations of your screen. That would be much appreciated!
Thanks for reporting! Most of the Wayland compatibility is probably in Electron and Chromium itself. We basically just have to wait and see.
Looks like Electron 17 might improve the Wayland support. But another flag is needed: https://github.com/signalapp/Signal-Desktop/issues/3411#issuecomment-1026971390
Good news. In case various flags are needed for Wayland support of the app, I hope this will be well documented when the next version is released.
Any update ? Xwayland work well but the security concern over X remain (much more on critical security app like VPN).
@BirdInFire As faern wrote in the initial message, the current app version supports Wayland but you'll have to supply some arguments.
As for the issue https://github.com/electron/electron/pull/32650, which to my knowledge is the only thing blocking us from making it deafult, it's now merged and released as part of Electron 17 but we haven't updated yet. We'll hopefully update pretty soon.
@BirdInFire As faern wrote in the initial message, the current app version supports Wayland but you'll have to supply some arguments.
As for the issue electron/electron#32650, which to my knowledge is the only thing blocking us from making it deafult, it's now merged and released as part of Electron 17 but we haven't updated yet. We'll hopefully update pretty soon.
Thanks do you have an idea of witch version will have this ? (the one in beta or the next one ? (or yet another)).
@BirdInFire The current beta does not have Electron 17 and therefore doesn't have the window decorations fix. We haven't started updating to Electron 17 yet. If everything goes smoothly it shouldn't be a big project but we've been blocked from updating in the past due to bugs in Electron and I don't know yet whether or not this version will work smoothly for us.
I'm trying to evaluate Mullvad, but I'm unable to get the app to work at all in Fedora 35 Gnome with Wayland. It works fine if I don't use Wayland. I just get a black box where the app should be. I've tried two betas and every workaround I could find here and it still isn't working. It sounds like others are having minor issues, but for me it doesn't work at all even with the latest beta I could find (2022.1-beta1). So when you have a new beta with Electron 17 I'd like to try it. Or if there are other workarounds to get current Fedora 35 with Wayland to work I'd love to try them.
We recently upgraded to Electron 17 in our master branch (#3388). But now Wayland support seems completely broken. I suspect this is the issue: https://github.com/electron/electron/issues/32436
We recently upgraded to Electron 17 in our master branch (#3388). But now Wayland support seems completely broken. I suspect this is the issue: electron/electron#32436
It looks like this is fixed in 17.3.1 and 18.0.1
We've now update the master-branch to Electron 18.0.3 which means that Wayland support is working again. There are still a bunch of issues that prevents us from making it default when running Wayland unfortunately, here's the two issues I ran into in the short time I tested it:
- On Fedora KDE the GPU process crashes, but the app continues running fine
- In Gnome on Debian there's no titlebar.
The master branch works well in Wayland under some window managers now. The only flag needed is --ozone-platform=wayland. However, we still can't make it use Wayland by default, since it's not looking pretty under some window managers.
We've now update the master-branch to Electron 18.0.3 which means that Wayland support is working again. There are still a bunch of issues that prevents us from making it default when running Wayland unfortunately, here's the two issues I ran into in the short time I tested it:
- On Fedora KDE the GPU process crashes, but the app continues running fine
- In Gnome on Debian there's no titlebar.
For Gnome title bar often : --enable-features=WaylandWindowDecorations do the jobs.
The
masterbranch works well in Wayland under some window managers now. The only flag needed is--ozone-platform=wayland. However, we still can't make it use Wayland by default, since it's not looking pretty under some window managers.
Couldn't we detect which ones do work en enable wayland by default on runtime?
The XDG_SESSION_DESKTOP environment variable is useful for this.
@aruiz ~Currently Electron isn't working well enough on Wayland to make it the default for everyone running Wayland, see this pull request: https://github.com/mullvad/mullvadvpn-app/pull/3145. But eventually when everything works as expected we will make it run on Wayland by default.~
We'll investigate which compositors Electron works well on and see if we can add the flags automatically based on a blocklist/allowlist.
We just merged the PR to enable native Wayland by default on window managers known to work well only. We took a quite conservative approach. Since we know the Electron + Wayland support is pretty unstable on some WMs/DEs we only enable it on a specified allowlist. We started with just sway and river as the known good WMs.
If you run this app in another WM as native Wayland (manually adding --ozone-platform=wayland --enable-features=WaylandWindowDecorations) and it works well, please report to this issue! Please report the values in your environment variables XDG_CURRENT_DESKTOP and XDG_SESSION_DESKTOP.
@faern Hi, I used the app for about a week with manually added flags mentioned above, it seems to work fine on Hyprland.
XDG_CURRENT_DESKTOP=Hyprland
XDG_SESSION_DESKTOP= #empty
2022.5 works on GNOME 43 using Fedora 37 beta! The only minor issue is that the window is smaller on Wayland than on Xwayland. I'm using 125% fractional scaling.
Xwayland:
Wayland:
@MahouShoujoMivutilde @johns2s We're currently in the process of upgrading to Electron 21 which has improved Wayland support. When that's done we'll look into enabling it for all compositors. If that isn't possible we'll try to add Hyprland and Gnome to the list.
@MahouShoujoMivutilde Hyprland has now been added to the list of compatible compositors. This will be part of the next release of the app.
I'm running the .desktop file with --ozone-platform=wayland --enable-features=WaylandWindowDecorations variables on GNOME 45 Wayland and everything seems fine. xeyes can't follow the cursor on the GUI anymore.
Running successfully on Ubuntu 23.10 using flags --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations. Confirmed by checking the absenese of mullvad in the output of xlsclients. I'm not sure when the switch to --ozone-platform-hint=auto occurred but I believe its replaced the previous switches.
XDG_CURRENT_DESKTOP=ubuntu:GNOME # GNOME 45.1
XDG_SESSION_DESKTOP=ubuntu
