-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Desktop App: fix crash on Apple Silicon caused by 8.0.0. #78969
Conversation
This PR does not affect the size of JS and CSS bundles shipped to the user's browser. Generated by performance advisor bot at iscalypsofastyet.com. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WordPress Desktop CI Failure for job "wp-desktop-mac".
@worldomonation please inspect this job's build steps for breaking changes at this link. For temporal failures, you may try to "Rerun Workflow from Failed".
Please also ensure this branch is rebased off latest Calypso.
b36f665
to
a4ce80c
Compare
desktop/package.json
Outdated
@@ -51,6 +50,7 @@ | |||
"webpack-cli": "^4.9.2" | |||
}, | |||
"dependencies": { | |||
"@electron/rebuild": "3.2.13", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
electron-rebuild
should be a dev dependency, and not a direct dependency of the app.
88c61cf
to
3ca024d
Compare
Status update, as of July 6, 2023:
Configuration:
|
014b364
to
5abe782
Compare
desktop/bin/build-mac-ci.js
Outdated
@@ -13,7 +13,8 @@ const circleTag = process.env.CIRCLE_TAG; | |||
const isReleaseBuild = | |||
process.platform === 'darwin' && !! circleTag && circleTag.startsWith( 'desktop-v' ); | |||
|
|||
const arches = isReleaseBuild ? [ 'x64', 'arm64' ] : [ 'x64' ]; | |||
// Always build both Intel and Apple Silicon versions. | |||
const arches = [ 'x64', 'arm64' ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've elected to remove the conditional and thus always build both the Intel and Apple Silicon binaries.
I am thinking that as more of the world moves to Apple Silicon, making sure the arm64 build doesn't break is going to be important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've elected to remove the conditional and thus always build both the Intel and Apple Silicon binaries.
I would suggest not doing this, and limiting the build to only one or the other (preferably the arm64 build, as we should be deprecating the Intel build soon anyway).
From the CI run (link), it's unclear which architecture the end-to-end tests were ran against (as far as I can tell it wasn't both). It's nice that the test script can find either the Apple Silicon or Intel binaries, but you still have to specify which of the two builds to use during a test run (or if you really want to build both, then amend the CI script to execute against both):
jest-haste-map: Haste module naming collision: WordPressDesktop
The following files share their name; please adjust your hasteImpl:
* <rootDir>/release/mac/WordPress.com.app/Contents/Resources/app/package.json
* <rootDir>/release/mac-arm64/WordPress.com.app/Contents/Resources/app/package.json
PASS test/e2e/specs/login.js
User Can log in
✓ Log in (950 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 3.645 s
Ran all test suites.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you really want to build both, then amend the CI script to execute against both
To clarify, the proposed choices are either trim it back to building and testing a single architecture (like the status quo), or build both and run tests for both binaries.
Edit: I saw this comment and it sounds like you're in favor of cutting it back to a single arm64 build for non-releases.
If so, I can look at getting this out, but with a high-visibility project today and tomorrow I am not sure how much time I have to work on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it sounds like you're in favor of cutting it back to a single arm64 build for non-releases.
Yes - I would lean towards a single architecture for non-release builds:
const arches = isReleaseBuild ? [ 'x64', 'arm64' ] : [ 'arm64' ];
I would consider the Intel build less important going forward (perhaps it's something we can eventually drop completely).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, will make the change.
desktop/package.json
Outdated
"copy-webpack-plugin": "^10.1.0", | ||
"electron": "24.0.0", | ||
"electron": "25.2.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick questions: Why is the bump to electron version necessary? If we maintain the same dependencies, the changes to the entitlement files should be sufficient for this fix, no?
In general, we should be a little more cautious when bumping major electron versions, as the process needs to be a little more comprehensive. For starters, you would need to evaluate any breaking API changes as described in Electron's breaking changes docs, and smoke-test the app on all platforms as there are things that definitely won't be caught by CI (for example menu items, keyboard shortcuts, the auto-updater). With the exception of the Apple Silicon build, I did verify these things when updating to version 8.0.0. Unless you're willing and able to verify all these items again (on all platforms), I would suggest maintaining the electron version and other dependencies. The less frequently we have to perform this sort of manual verification/smoke-testing, the better IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the packages initially as part of our private conversation about using the up-to-date version of electron-related packages.
Though I didn't check all of the breaking changes doc, I did get my teammates to check macOS builds and I checked Windows myself. Is there more in-depth checks required if bumping electron versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted in 3e0a8ece862d8eb2f51604ff715eea2a7515c195.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there more in-depth checks required if bumping electron versions?
I tried to enumerate them in this preliminary PR from a while ago. Aside from smoke-testing, the auto-updater is a critical component. Included in manual smoke-testing is ensuring keyboard shortcuts and menu items continue to work as expected.
3e0a8ec
to
98cd59f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WordPress Desktop CI Failure for job "wp-desktop-mac".
@worldomonation please inspect this job's build steps for breaking changes at this link. For temporal failures, you may try to "Rerun Workflow from Failed".
Please also ensure this branch is rebased off latest Calypso.
98cd59f
to
9a1226b
Compare
@nsakaimbo One of the reverted changes ended up causing the build to break. I'll have to investigate, but can we settle on an acceptable solution to get the fix out for users complaining about the crashes? Edit: investigated arm64 build on Apple Silicon, we're back to a white screen of death. Edit Edit: fixed the issue, the core fix for the crash/white screen got dropped when I rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work, and way to go in identifying that entitlements fix. 👍🏽 For a quick sanity check I tested the x64 artifact as generated by the M1 image and confirmed it worked correctly. 🎉
I would suggest limiting builds to a single architecture for non-release builds, but ultimately that's up to you and LGTM otherwise.
d1cfe7a
to
28581c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WordPress Desktop CI Failure for job "wp-desktop-mac".
@worldomonation please inspect this job's build steps for breaking changes at this link. For temporal failures, you may try to "Rerun Workflow from Failed".
Please also ensure this branch is rebased off latest Calypso.
@nsakaimbo Thanks for the review! This PR is ready to go, with all builds building correctly and passing. One other thing I had to fix was the artifact path for yet another step: Persist Mac Executable. After fixing the path, I noticed the artifact list isn't as descriptive as it used to be when building two arches: From comparing the artifact list to other trunk builds, it seems like normally the "less descriptive" artifacts are captured, but I want to make sure this looks alright before merging the fix. Links |
Good catch, but yes this is by design. If you look at the existing artifacts being persisted for business-as-usual jobs in As a sanity check, if you like you can temporarily set Thanks for being so thorough! |
- remove electron-rebuild
- fix test path to handle both Apple Silicon and Intel by checking the arch. bin/build-mac-ci.js - build both x64 and arm64.
- add new key to permit jit
- remove commented out code. - add comment. test/e2e/specs/login.js - remove debugging code. - add comments.
- fix command for windows (unrelated to crash fix for Apple Silicon)
- only build arm64 by default
- add wildcard for the Persist Mac Excutable step to be able to locate the default arm64 build.
a23a2bc
to
95ea157
Compare
)" This reverts commit a38cdf5.
Fixes #78884.
Proposed Changes
This PR adds fixes to the Entitlements list that caused the Apple Silicon build of the app to either crash or display a white screen on startup.
This PR also adds a fix for the failing Window build.
What went wrong?
The previous release of WordPress.com Desktop App 8.0.0 caused crashes on users on the Apple Silicon architecture.
After almost a week of investigations, debugging and trial I found the culprit is because we jumped from Electron 12.x.x to Electron 24.x.x.
More specifically, Electron has required (since 20.x.x) that additional entitlement be added in the form of
com.apple.security.cs.allow-jit
.This issue was not caught in #78098, because:
As it turns out, the CI-produced builds involve the Apple signing process, which is where the Entitlements come into play. Because the Entitlements didn't change from Electron 12.x.x, when the binary was signed additional privileges required to run Electron >= 20.x.x was not granted, hence the app crashed on all Apple Silicon users.
Testing Instructions
Ensure the following build configurations are passing:
Additionally, download the x64 and arm64 produced binaries from CircleCI and ensure it functions as expected.
Pre-merge Checklist