Open
Conversation
mitchchn
force-pushed
the
mitch/tech-talk-wayland
branch
from
51d773c to
7fc056e
Compare
bnb
reviewed
Mar 9, 2026
mitchchn
force-pushed
the
mitch/tech-talk-wayland
branch
from
8e95d9d to
7c08b43
Compare
erickzhao
reviewed
Mar 9, 2026
blog/tech-talk-wayland.md
Outdated
| @@ -0,0 +1,111 @@ | |||
| --- | |||
| title: 'Tech Talk: How Electron went Wayland-native (and how it affects your apps)' | |||
| date: 2026-03-10T00:00:00.000Z | |||
Member
There was a problem hiding this comment.
Putting a note to change this date for when we actually publish. Ideally it wouldn't be tomorrow as that collides with the 41 stable release
mitchchn
force-pushed
the
mitch/tech-talk-wayland
branch
from
47fdc35 to
3bb5004
Compare
bnb
approved these changes
Mar 10, 2026
erickzhao
reviewed
Mar 11, 2026
| tags: [techtalk, internals] | ||
| --- | ||
|
|
||
| _Tech talks are a new blog post series where we share glimpses into our work on Electron. If you find this work interesting, please consider [contributing](https://github.com/electron/electron/)!_ |
Member
There was a problem hiding this comment.
Consider adding an admonition here (this should render as a blue info admonition in Docusaurus).
Suggested change
| _Tech talks are a new blog post series where we share glimpses into our work on Electron. If you find this work interesting, please consider [contributing](https://github.com/electron/electron/)!_ | |
| > [!IMPORTANT] | |
| > Tech talks are a new blog post series where we share glimpses into our work on Electron. If you find this work interesting, please consider [contributing](https://github.com/electron/electron/)! |
|
|
||
| But a platform migration isn't complete without apps, and the Linux app ecosystem went through a rapid Wayland transition last August after Chromium [turned on Wayland support by default](https://chromium-review.googlesource.com/c/chromium/src/+/6819616). That move brought along the Electron framework and dozens of Linux desktop apps built on top of it. | ||
|
|
||
| ## The third impact: Electron goes Wayland-native |
Member
There was a problem hiding this comment.
Keep the rest below the fold in the /blog homepage:
Suggested change
| ## The third impact: Electron goes Wayland-native | |
| <!--truncate--> | |
| ## The third impact: Electron goes Wayland-native |
|
|
||
| These rules are understandable; no one likes it when misbehaving apps steal focus or draw halfway off the screen. But for a cross-platform framework like Electron, Wayland's design philosophy makes it harder for developers to achieve consistency. | ||
|
|
||
| In practice, Electron apps have more restrictions on Wayland than they do on X11 and other platforms. Some widely used APIs, like [`BrowserWindow.setPosition(x, y)`](https://www.electronjs.org/docs/latest/api/base-window#winsetpositionx-y-animate), simply don't work on Wayland. |
Member
There was a problem hiding this comment.
Suggested change
| In practice, Electron apps have more restrictions on Wayland than they do on X11 and other platforms. Some widely used APIs, like [`BrowserWindow.setPosition(x, y)`](https://www.electronjs.org/docs/latest/api/base-window#winsetpositionx-y-animate), simply don't work on Wayland. | |
| In practice, Electron apps have more restrictions on Wayland than they do on X11 and other platforms. Some widely used APIs, like [`win.setPosition(x, y)`](https://www.electronjs.org/docs/latest/api/base-window#winsetpositionx-y-animate), simply don't work on Wayland. |
suggestion: we usually document instance functions like so, so it's slightly easier to follow IMO (couple other instances of this)
|
|
||
|  | ||
|
|
||
| On the other hand, some capabilities work better on Wayland, especially around colors, transparency, and hardware-accelerated rendering. APIs like [`setOpacity(n)`](https://www.electronjs.org/docs/latest/api/base-window#winsetopacityopacity-windows-macos) do not currently work on Linux, but they are now more feasible to support. |
Member
There was a problem hiding this comment.
Suggested change
| On the other hand, some capabilities work better on Wayland, especially around colors, transparency, and hardware-accelerated rendering. APIs like [`setOpacity(n)`](https://www.electronjs.org/docs/latest/api/base-window#winsetopacityopacity-windows-macos) do not currently work on Linux, but they are now more feasible to support. | |
| On the other hand, some capabilities work better on Wayland, especially around colors, transparency, and hardware-accelerated rendering. APIs like [`win.setOpacity(n)`](https://www.electronjs.org/docs/latest/api/base-window#winsetopacityopacity-windows-macos) do not currently work on Linux, but they are now more feasible to support. |
|
|
||
| In practice, Electron apps have more restrictions on Wayland than they do on X11 and other platforms. Some widely used APIs, like [`BrowserWindow.setPosition(x, y)`](https://www.electronjs.org/docs/latest/api/base-window#winsetpositionx-y-animate), simply don't work on Wayland. | ||
|
|
||
| Exact outcomes can vary by compositor. On KDE (KWin), for example, an app that tries to focus one of its windows with [`BrowserWindow.focus()`](https://www.electronjs.org/docs/latest/api/browser-window#winfocus) will flash its icon in the panel instead. |
Member
There was a problem hiding this comment.
On first read, I got a bit lost here. Are compositors specific to each Desktop Environment?
Also, should this be KDE Plasma?
|
|
||
| But to have full coverage for CSD, Electron also needed to keep track of a new kind of boundary: | ||
|
|
||
| - “widget bounds”, the size of the underlying transparent surface which draws everything inside of it, including the window frame, but also external decorations like drop shadows and resize targets. |
Member
There was a problem hiding this comment.
Suggested change
| - “widget bounds”, the size of the underlying transparent surface which draws everything inside of it, including the window frame, but also external decorations like drop shadows and resize targets. | |
| - **“widget bounds”**, the size of the underlying transparent surface which draws everything inside of it, including the window frame, but also external decorations like drop shadows and resize targets. |
bold this like the ones in the paragraph above for consistency
|
|
||
| - “widget bounds”, the size of the underlying transparent surface which draws everything inside of it, including the window frame, but also external decorations like drop shadows and resize targets. | ||
|
|
||
| Effectively, CSD makes it so that the “real” window (represented internally as a Chromium “accelerated widget”) is larger than the opaque window which developers and users see and interact with. That part — the “logical” window — is inset inside the transparent widget. So a window that visibly measures 800x600 needs to be set inside a larger, transparent window that might measure something like 844x644 (depending on the GTK theme). |
Member
There was a problem hiding this comment.
Any breadcrumbs for people who are curious about the Chromium internals?
|
|
||
| We're actively looking for Linux contributors and maintainers. Electron powers many of the most popular desktop apps across platforms, so getting involved is a great way to help make desktop Linux even more viable for more people. | ||
|
|
||
| We're actively looking for Linux contributors and maintainers. Electron powers many of the most popular desktop apps across platforms, so getting involved is a great way to help make desktop Linux even more viable for more people. |
Member
There was a problem hiding this comment.
Suggested change
| We're actively looking for Linux contributors and maintainers. Electron powers many of the most popular desktop apps across platforms, so getting involved is a great way to help make desktop Linux even more viable for more people. |
Duplicated paragraph!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Change
Added our second tech talk about the recent work to better support Wayland and CSD on Linux.
Checklist