mullvad / mullvadvpn-app

The Mullvad VPN client app for desktop and mobile
https://mullvad.net/
GNU General Public License v3.0
4.67k stars 330 forks source link

Support Wayland natively #3062

Open faern opened 2 years ago

faern commented 2 years ago

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.

johns2s commented 2 years ago

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

faern commented 2 years ago

Thanks for reporting this! Do you have links to the upstream issues?

lkcv commented 2 years ago

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.

johns2s commented 2 years ago

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

pinballmachine commented 2 years ago

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!

faern commented 2 years ago

Thanks for reporting! Most of the Wayland compatibility is probably in Electron and Chromium itself. We basically just have to wait and see.

faern commented 2 years ago

Looks like Electron 17 might improve the Wayland support. But another flag is needed: https://github.com/signalapp/Signal-Desktop/issues/3411#issuecomment-1026971390

pinballmachine commented 2 years ago

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.

ghost commented 2 years ago

Any update ? Xwayland work well but the security concern over X remain (much more on critical security app like VPN).

raksooo commented 2 years ago

@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.

ghost commented 2 years ago

@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)).

raksooo commented 2 years ago

@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.

gwk2112 commented 2 years ago

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.

faern commented 2 years ago

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

johns2s commented 2 years ago

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

raksooo commented 2 years ago

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:

faern commented 2 years ago

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.

ghost commented 2 years ago

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.

aruiz commented 2 years ago

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.

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.

raksooo commented 2 years ago

@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.

faern commented 1 year ago

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.

MahouShoujoMivutilde commented 1 year ago

@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
johns2s commented 1 year ago

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:

Screenshot from 2022-10-15 23-46-00

Wayland:

Screenshot from 2022-10-15 23-46-56

raksooo commented 1 year ago

@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.

raksooo commented 1 year ago

@MahouShoujoMivutilde Hyprland has now been added to the list of compatible compositors. This will be part of the next release of the app.

nokia8801 commented 7 months ago

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.

tim-hm commented 7 months ago

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
LinuxEnthusiast99 commented 2 months ago
/opt/Mullvad\ VPN/mullvad-vpn --ozone-platform=wayland
/opt/Mullvad\ VPN/mullvad-vpn --ozone-platform=wayland --enable-features=WaylandWindowDecorations
/opt/Mullvad\ VPN/mullvad-vpn --enable-features=UseOzonePlatform --ozone-platform=wayland
/opt/Mullvad\ VPN/mullvad-vpn --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations

All result in my minimise, maximise, and close buttons being in the top right corner of the window name, instead of the top left corner, Ubuntu 24.04, "Ubuntu on Wayland"

With Ubuntu 24.04, "Gnome Classic on Wayland" this doesn't happen, and it shows correctly.

Titaniumtown commented 2 months ago

@LinuxEnthusiast99 what WM/DE are you using?

LinuxEnthusiast99 commented 2 months ago

@LinuxEnthusiast99 what WM/DE are you using?

This was on Ubuntu 24.04, Gnome 46. I tried on Fedora 40, KDE Plasma 6, and it works fine with no extra flags, stock configuration from install, there is no issue.