Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Upgrade to Electron 4 #19373
This PR will track our progress upgrading to Electron 4.
We just upgraded to Electron 3, but we're experiencing a crash deep in the bowels of V8 (#19372). I'm interested in whether Electron 4 might fix this crash.
Issues to resolve
I was able to successfully build Atom by skipping the snapshot generation and using a patched version of fuzzy-native (to bypass node-pre-gyp), but starting Atom fails with "The specified procedure could not be found" when attempting to load nsfw
Edit: Making progress. I can get Atom to start now. Mostly by patching our native modules to get rid of
Check for regressions experienced in previous upgrades
See how to setup keyboard layouts.
What we can do now is to start showing now banners on Atom running on OSX 10.9 informing users that we're going to drop support for this operating system very soon (maybe we can add this banner to v1.39 or v1.40).
Regarding blocking 10.9 users from upgrading, this seems to be possible to do only by our
client side changes
In order to do so, Atom needs to pass the OS version to
In order to make everything work, though, we need to do this change at least one the version before we ship Electron v4, so older clients that do not need to get updated are already sending the OS version.
My suggestion is to make these changes as soon as possible and cherry-pick them to the current beta to get them to stable soon.
Then, we need to change
In order to explain the logic a little bit clearer, I'm going to assume that the new parameter is added on Atom v1.40 and Electron v4 is added on Atom v1.42:
The same logic should be applied to each release channel (stable, beta and nightly).
Good thing is that if we build this logic in a configurable way, later it's going to be trivial to block e.g older Windows versions from upgrading if Electron drops support for them.
This plan makes sense to me @rafeca.
One thing worth noting... Unless there's an API I don't know about, I think the best we'll be able to do is for determining the OS version is
While doing the regression testing I found an issue related to native tabs: when I enable them, doing operation with tabs becomes super slow and makes the editor unresponsive for ~5-10s. Same happens when doing operations with the native tabs (like merging different windows into a single window or splitting tabs into multiple windows).
I've created an issue to track it: #19611
Ok, it looks like all the identified blockers are solved. In order to reduce the risk we're going to wait to merge this PR until just after the Atom Railcar Release for 1.39 is done (which is expected on July 19th).
Until then, I'll be using a version of Atom built from this PR to see if I can find any other regression.