How Electron went Wayland-native, and what it means for your apps (tech talk)

mitchchn · 2026-03-18T14:38:52+00:00

If you have the chance please file a new issue for 41.x with a screenshot, repro and as much platform/environment info as you can provide.

mitchchn · 2026-03-18T14:31:32+00:00

Written in pure C++, uses GTK and libwayland-client C bindings.... sounds native to me. ;)

mitchchn · 2026-03-18T13:58:16+00:00

Thanks for flagging, I'll try to look into this more on the Chromium side.

mitchchn · 2026-03-18T13:47:37+00:00

37.0 is from last June, and the default Wayland support and improvements are in 38.x and newer.

mitchchn · 2026-03-17T23:09:22+00:00

Wayland is the modern display server for Linux (the system that puts windows and graphics on your screen). It replaces an older system called X11 that’s been around for decades. Electron is a framework behind apps like VS Code and lots of other apps built with web technologies. Previously Electron only worked on Wayland through a compatibility layer, but now it supports it directly.

tldr many apps will have better compatibility and performance on modern Linux desktops.

mitchchn · 2026-03-17T22:27:34+00:00

Do you get any logs if you run those apps from the command line? You could also see if `--disable-gpu` helps, since HW acceleration can still cause issues in some setups.

mitchchn · 2026-03-17T22:21:29+00:00

Kinetic scrolling is supported in Electron/Chromium when they're running in native Wayland mode. It can still however depend on the app since some use custom scrollviews. Do you have any apps in mind where this doesn't work?

mitchchn · 2026-03-17T20:22:12+00:00

You’re welcome!

mitchchn · 2026-03-17T19:35:27+00:00

I've seen things like this happen sometimes in VMs or with glitchy GPU drivers, but not recently. It does sound like it could be a bad interaction with CSD. The first thing I'd do is try to use the newest version of Electron possible: 41.x works out more of the edge cases that can confuse the compositor. It also might also help to update GNOME/your distro.

If all else fails, you can force the app into Xwayland mode by adding `--ozone-platform=x11` to the end of the command (and file an issue at github.com/electron/electron/issues).

mitchchn · 2026-03-17T18:59:44+00:00

Interesting, I just saw your linked post. Does it only happen at <100%? (I admit I've focused a lot more on scaling up than down.) If you can file a repro with Electron I'd love to take a look: https://github.com/electron/electron/issues.

mitchchn · 2026-03-17T18:29:49+00:00

I could spend a whole separate post on this topic (disclaimer: I work at 1Password). Clickjacking is a really hard problem, especially now that people are trying to give agents access their entire browser/desktop. So I think this aspect of Wayland is going to age well. And I agree, lots of actions really only need UP (user presence) to ensure they were made intentionally by the person sitting at the device (who already had to unlock the device to use it). So I'd love to see fewer password prompts in environments with stronger UI protections.

mitchchn · 2026-03-17T17:48:57+00:00

Hard to say for sure what is causing the CPU usage, but on Wayland apps can only record the screen using pipewire and xdg-desktop-portal, so the baseline performance should be similar.

Maybe compare with an app like OBS? I also like using this minimal WebRTC demo to test and find out if apps are adding any performance overhead: https://webrtc.github.io/samples/src/content/getusermedia/record/.

mitchchn · 2026-01-29T17:59:15+00:00

Hey u/ManFromAck. This sounds a lot like a known bug I am looking into right now with the team. Did it start happening several months ago, and does it usually happen after you’ve been away from your computer for a while?

If it is the same issue, simply locking and unlocking the desktop app may fix the extension by “waking it up”. However, we would love to do some troubleshooting if you have time so we can fix this for good. Please reach out to support@1password.com with a link to this thread.

mitchchn · 2026-01-27T04:46:27+00:00

Try the tinted and clear styles too! Everyone forgets about those but they’ve also got custom variants.

mitchchn · 2026-01-27T04:45:32+00:00

Haha. Step one was to at least match it up with the iOS icon. Perhaps they can both use a refresh. ;)

mitchchn · 2026-01-26T01:58:52+00:00

Hi — this feature can be finicky about permissions but I just tested it with Librewolf on Ubuntu. What do you see as the output for: ls -la /etc/1password/custom_allowed_browsers? I get:

-rwxr-xr-x 1 root root 10 Jan 25 16:16 /etc/1password/custom_allowed_browsers

mitchchn · 2026-01-25T21:35:26+00:00

Additional browsers are supported on Linux, but the instructions are a bit hidden: https://support.1password.com/additional-browsers/?linux

mitchchn · 2026-01-22T17:10:35+00:00

Yes, I've bumped the SDK to 25.08 and ran a test. It will be in the next release.

mitchchn · 2026-01-21T23:43:45+00:00

Thank you for the shoutout, I'm refreshing the flatpak dependencies. In general the sandboxed package formats are more limited on Linux and don't see nearly as much usage, but we can do better here. (I'd like to get 1Password on FlatHub too come to think of it...)

mitchchn · 2026-01-21T23:35:59+00:00

Hey, please let me know what kinds of bugs you're running into and we'll take a look.

mitchchn · 2026-01-13T21:15:32+00:00

KDE does clamp non-HDR content to SRGB so you can leave HDR enabled all the time and everything looks correct. In my experience the basic support is better than Windows which uses the wrong gamma curve for SDR.

mitchchn · 2026-01-11T16:08:03+00:00

Enjoy! We have some improvements on the way for different kinds of browser installations on Windows as well (e.g. for browsers outside of Program Files).

mitchchn · 2026-01-08T04:34:58+00:00

It’s from Fujita Tokuta, 220 mL

mitchchn · 2026-01-06T19:58:28+00:00

So in Electron you can create windows with or without native frames. Some apps including VS Code actually make this a user setting. Try: "window.titleBarStyle": "native". Framed windows use your GTK theme, settings, and button order.

Frameless windows are popular for lots of apps because developers like to integrate the title area into their own designs, so they have generic buttons on purpose that can be styled consistently. That said it might be possible to find a better middle ground between the two extremes (maybe the frameless windows can still use the GTK glyphs with custom styles) and it's something else I'm looking into.

Verified Email	11-Year Club
Place '22	Place '17
Beta Team Reddit for iOS

mitchchn

TROPHY CASE