Skip to content
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

Merged
merged 8 commits into from
Jul 14, 2023

Conversation

worldomonation
Copy link
Contributor

@worldomonation worldomonation commented Jul 5, 2023

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:

  1. CircleCI builds were all successful;
  2. locally built Apple Silicon builds launched as expected, and it was assumed that CI-produced builds will be the same;

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:

  • CircleCI > wp-desktop-mac
  • CircleCI > wp-desktop-linux
  • CircleCI > wp-desktop-windows

Additionally, download the x64 and arm64 produced binaries from CircleCI and ensure it functions as expected.

Pre-merge Checklist

  • Has the general commit checklist been followed? (PCYsg-hS-p2)
  • Have you written new tests for your changes?
  • Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
  • Have you checked for TypeScript, React or other console errors?
  • Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
  • Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-ajp-p2)?

@worldomonation worldomonation self-assigned this Jul 5, 2023
@matticbot
Copy link
Contributor

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.

Copy link
Collaborator

@wp-desktop wp-desktop left a 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.

@@ -51,6 +50,7 @@
"webpack-cli": "^4.9.2"
},
"dependencies": {
"@electron/rebuild": "3.2.13",
Copy link
Contributor

@nsakaimbo nsakaimbo Jul 5, 2023

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.

@worldomonation
Copy link
Contributor Author

Status update, as of July 6, 2023:

Build

  • resolved the issue with entitlement file structure, the build can now complete.
  • E2E tests still can't run, likely related to the issue below.

Configuration:

  • electron 25.2.0
  • electron/rebuild 3.2.13
  • electron-builder 23.0.3

Issue
The app loads a white screen of death.
image

@wp-desktop wp-desktop dismissed their stale review July 6, 2023 05:29

wp-desktop ci passing, closing review

@@ -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' ];
Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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).

Copy link
Contributor Author

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.

@worldomonation worldomonation marked this pull request as ready for review July 6, 2023 05:54
@worldomonation worldomonation changed the title Desktop/fix electron crash Desktop App: fix crash on Apple Silicon caused by 8.0.0. Jul 6, 2023
@worldomonation worldomonation added the [Feature] WordPress Desktop App Features and improvements related to the WordPress Desktop App. label Jul 6, 2023
"copy-webpack-plugin": "^10.1.0",
"electron": "24.0.0",
"electron": "25.2.0",
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted in 3e0a8ece862d8eb2f51604ff715eea2a7515c195.

Copy link
Contributor

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.

desktop/package.json Outdated Show resolved Hide resolved
Copy link
Collaborator

@wp-desktop wp-desktop left a 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.

@worldomonation
Copy link
Contributor Author

worldomonation commented Jul 11, 2023

@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.

@wp-desktop wp-desktop dismissed their stale review July 11, 2023 15:20

wp-desktop ci passing, closing review

@nsakaimbo nsakaimbo self-requested a review July 11, 2023 18:53
@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jul 11, 2023
Copy link
Contributor

@nsakaimbo nsakaimbo left a 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.

Copy link
Collaborator

@wp-desktop wp-desktop left a 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.

@wp-desktop wp-desktop dismissed their stale review July 12, 2023 08:34

wp-desktop ci passing, closing review

@worldomonation
Copy link
Contributor Author

worldomonation commented Jul 12, 2023

@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:
image

When building two arches:
image

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
Two arches: https://app.circleci.com/pipelines/github/Automattic/wp-calypso/184425/workflows/b35a8043-c225-4df8-963a-0cc8eb09d75e/jobs/1123016/artifacts
One arch: https://app.circleci.com/pipelines/github/Automattic/wp-calypso/184577/workflows/420582f2-7535-4b74-85a8-b8d8c20edb19/jobs/1123102/artifacts

@nsakaimbo
Copy link
Contributor

nsakaimbo commented Jul 12, 2023

I noticed the artifact list isn't as descriptive as it used to be when building two arches:

Good catch, but yes this is by design. If you look at the existing artifacts being persisted for business-as-usual jobs in trunk right now, they would match the smaller artifact set (i.e. the app zip and contents of the results/ folder). The full artifact set should be persisted only at release time. My guess is there are probably a few more places in the build scripts that would need to accommodate two architectures being more cleanly persisted for non-release jobs. In addition, it seems the SHA of the "two arches" CI job you shared doesn't seem to be available any longer - it's possible that version of the branch had some changes in desktop/package.json or yarn.lock, either of which would trigger a full artifact build. However the important thing is the artifact set looks correct when isolated to a single architecture. Hope that makes sense.

As a sanity check, if you like you can temporarily set ELECTRON_BUILDER_ARGS to an empty string and isReleaseBuild to true in the mac release script to compare what artifacts will be persisted at release time (in this case, the artifact set should look more like the "full" set you noted). The electron builder args are set here, and a full build is invoked when dependencies change or the version number is bumped. (Therefore most jobs in trunk will have the smaller artifact set, except when dependencies change, which should be much less frequent.)

Thanks for being so thorough!

@worldomonation
Copy link
Contributor Author

Confirmed that if I set ELECTRON_BUILDER_ARGS = '' and isReleaseBuild = true in the script, the longer artifact list is produced:
image

With that, I think it's good to go. I will merge this after dropping the experimental changes.

- 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.
@worldomonation worldomonation merged commit a38cdf5 into trunk Jul 14, 2023
22 checks passed
@worldomonation worldomonation deleted the desktop/fix-electron-crash branch July 14, 2023 02:24
@github-actions github-actions bot removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Jul 14, 2023
worldomonation added a commit that referenced this pull request Jul 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] WordPress Desktop App Features and improvements related to the WordPress Desktop App.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

WordPress Desktop app 8.0.0: crash while trying to open it on Apple Silicon
4 participants