MEGATHREAD: Unresolved issues in 1.131 and higher #1463
Description
The purpose of this issue is to summarize all the things that stopped working (for at least some people) with 1.131.0 or greater, since that's the first Electron 30 release. I'll try to keep this list updated in order to make it easier for users to understand when to add to existing issues and when to create new issues altogether.
As these issues are resolved, I'll remove them from this list.
.deb installation doesn't work, at least on Ubuntu >=24
#1462 is the bug; #1466 ought to fix it. Sorry for the hassle! We'll certainly fix this in time for the next regular release, if not sooner.
Some packages rely upon old require syntax
#1458 was the first to report this, but it won't be the only package affected: any package that uses require('shell') or require('clipboard') (or a couple others) will no longer work without patching. Technically, those need to become (e.g.) require('@electron/remote').shell, but for now it's enough to change it to require('electron').shell, since we shim that and delegate it to our own copy of @electron/remote. (See #1372 for context.)
If this is affecting you, #1458 also demonstrates the short-term workaround: edit the package locally and update the require call. This is not a great idea usually, but it'll get you unblocked.
We know that lots of people rely on packages that are no longer maintained. Hence we hope that this issue does not affect very many packages, and we can use this as an opportunity to fork old packages and find new maintainers, or else find people other (already maintained) packages that do the same thing.
But if we're wrong, we have recourse; we could intercept these calls to require (perhaps only in cases where they're about to fail) and supply the modules we know the package expects. We would prefer not to do this, but we'll do it if it makes sense.
In the meantime, if this issue affects you and you had to use a workaround, please let us know about it in #1458 so that we understand how widespread this problem is.
Buffer watching might not be as reliable on macOS
We have two filesystem-watching libraries and would like to reduce that to one in the long term. The one that the Atom team invented is called pathwatcher and is used by text-buffer to detect when the buffer changes. This is how we keep the contents of an editor in sync with what's on disk — even when some other program changes the editor contents (e.g., switching branches via git).
#1459 reports that this is no longer happening on macOS, at least for one user. On one of my macOS machines, I have noticed occasional failure to keep the buffer in sync; for me this is telegraphed by an exception that is thrown on window startup and visible in the console.
If this is widespread, it's not clear what the root cause is. The pathwatcher library did have to be rewritten entirely, and on macOS it's now using a different API — but a newer and more appropriate API (FSEvent rather than kqueue). It is possible for this API to fail if too many things are asking to watch the filesystem at once, but that limit is quite high and unlikely to be exceeded in regular usage. (If the limit is reached, you'll find logging to that effect in Console.app.)
Fixing this issue is high on my priority list, even if it affects only a small number of people. If you're affected by it, please comment on #1459 and elaborate.
Keyboard layout might be misinterpreted on Linux
Upgrading to Electron 30 made it much more feasible to run Pulsar in a Wayland desktop environment — which means we had to improve our Wayland support in general. We use keyboard-layout to detect the user's keyboard locale and keyboard layout; this is important for resolving keybinding because it's the only good way to detect exactly which keys were pressed, and not just the character that wants to be inserted.
On Linux, the desktop environment, believe it or not, is in charge of reporting details about the user's keyboard. When we added Wayland support to keyboard-layout, we tried to make it as unobtrusive as possible, with the goal that it would fall back to the existing X11 code path if the user is not in a Wayland environment.
However, #1460 makes it clear that keyboard layout handling has regressed for at least one user and their non-QWERTY keyboard. At first, I was certain that it was simply falling onto a bad code path and reporting the default values for keyboard layout/locale (QWERTY/en-US) — but that's not true! Both the old and new versions of keyboard-layout correctly identify the user's keyboard locale. Yet the new keyboard-layout module misinterprets Ctrl-Z as Ctrl-W for this user.
If you use a non-QWERTY layout and have noticed regressions in keybinding resolution, please weigh in on #1460. I am eager to fix this issue as well.
Potential editor crash when restoring project state
We fixed one major crasher (#1438) in 1.131.1, but this is something different.
Issue #1453 reports that the editor may crash when restoring project state, depending on which buffers are open. The reporting user is able to reproduce this with Markdown files especially. This (plus crashdump analysis) strongly implies a problem triggered by loading of Tree-sitter parsers via WebAssembly. The reporter is on Linux, but if the root cause is accurate, then it theoretically could happen on any platform.
I've had no luck so far reproducing this in a VM. But if it happens to you, please let us know! We don't want the editor to crash, but we probably can't fix it unless we are able to reproduce the crash first.
Potential editor crash related to Git operations during window unload
#1468 has evidence of a crash I experienced related to our git-utils library. As crashes go, this is unlikely to cause you any pain (since it crashes a renderer process that was already crashing, and since you explicitly told it to quit or reload the window). Still, we should be able to fix this by modernizing the git-utils bindings; that work has already been done and just needs to be adopted.