Skip to content

implementation_plan.md

Latest commit

 

History

History
92 lines (71 loc) · 5.28 KB

implementation_plan.md

File metadata and controls

92 lines (71 loc) · 5.28 KB
Raw

Bad App / Damaged App Fix Plan

Goal

Fix the "App is damaged and can't be opened" error on macOS ARM64 builds of VRT, while ensuring the bundled Chromium browser doesn't cause code signing failures during the build process.

Root Cause

  1. "Damaged" Error: macOS Gatekeeper marks unsigned or improperly signed apps downloaded/created as "quarantined". On Apple Silicon (ARM64), code signing is enforced. If an app has no signature (identity: null), it is rejected immediately.
  2. Previous Signing Failure: The previous build failed signing because electron-builder tried to sign the bundled Chromium application, which has a complex internal structure (nested apps like Chromium Helper), and codesign choked on file paths or existing signatures.

Proposed Solution

1. Immediate Fix (For your current build)

Run the following command in the terminal to remove the quarantine attribute from the "damaged" app:

xattr -cr /path/to/VRT.app

2. Packaging Fix (For future builds)

We need to re-enable ad-hoc signing (which satisfies ARM64 requirements) but prevent the build from failing on the Chromium files.

Strategy A: Sign app but exclude Chromium from signing (if possible) vs Sign everything properly

Electron-builder tries to sign everything in the app bundle. The Chromium build we are copying contains its own valid signatures, but electron-builder tries to re-sign or timestamp them, causing conflicts.

Strategy B: Bundle Chromium as a ZIP (Recommended)

To avoid codesign trying to sign the thousands of complex files inside Chromium during the build:

  1. Compress: Zip the chromium-xxxx folder in prepare-browsers.sh.
  2. Package: Include the .zip file in extraResources instead of the raw folder.
  3. Runtime: In browser-installer.ts, check if the zip exists, and unzip it to userData on first run if needed (or keep it in resources and unzip to a temporary spot).
    • Actually, sticking to the current path structure is better. We can unzip on first run.
    • Wait, if we unzip at runtime, the unzipped app will still need to be valid. On ARM64, running an unsigned binary extracted from a zip might still trigger issues, but usually ad-hoc created files are okay locally.

Strategy C: Use identity: "-" (Ad-Hoc) explicitly

Instead of null, we use - which stands for ad-hoc signing. This is often the default if no ID is found, but setting null explicitly disabled it. We also need to see if we can tell electron-builder to ignore the playwright-browsers folder during signing. Configuration:

"mac": {
  "identity": "-", 
  "startOnLogin": false,
   ...
}

And potentially signIgnore if applicable? Electron-builder has forceCodeSigning.

Refined Plan:

  1. Restore Ad-Hoc Signing: Change identity in package.json to - (or remove null to let it default to ad-hoc/auto).

  2. Handle Chromium Signing Issues: The error we saw earlier was: Chromium Helper (Alerts).app: No such file or directory or replacing existing signature. This often happens because of deep path lengths or file attributes. We will modify package.json to use asar: true (it is already true) but ensure playwright-browsers is in extraResources (it is). extraResources are signed by default.

    We should try to configure customSign or signIgnore? electron-builder doesn't strictly have a signIgnore for extraResources easily exposed.

    Alternative: Copy the browser files after packaging? No, that's hard with electron-builder.

    Best Approach: Go with Strategy B (Zip it). It solves the "Build failed because of signing errors" issue completely. It solves the "File path too long" issues potentially. It keeps the package cleaner.

    We will:

    1. Update prepare-browsers.sh to zip the browser folder.
    2. Update package.json to copy the .zip file.
    3. Update browser-installer.ts to detect if the folder exists, if not check for zip, and unzip if needed.

    Wait, browser-installer.ts runs in the main process. Unzipping 300MB might take a few seconds on first launch. We can show a "Initializing..." status.

Implementation Steps

  1. Modify scripts/prepare-browsers.sh:

    • Find the browser.
    • Create a browsers.zip containing the chromium and ffmpeg folders.
    • Update package.json to include browsers.zip in extraResources.

  2. Modify src/main/browser-installer.ts:

    • Add logic to check if playwright-browsers is a directory.
    • If not, look for browsers.zip in resources.
    • Unzip it to app.getPath('userData')/playwright-browsers (Writability is guaranteed there!).
    • Update PLAYWRIGHT_BROWSERS_PATH to point to the userData location.

    Benefits:

    • Fixes the code signing build error (we just sign a zip file).
    • Fixes the "ReadOnly" issue completely because we execute from UserData.
    • Fixes the "Damaged App" issue because we can enable standard Ad-Hoc signing for the main app container without the inner Chromium signatures conflicting.

Verification

  1. Run npm run dist:mac.
  2. Verify build succeeds (no signing errors).
  3. Run the app (ARM64).
  4. Verify it launches (no "damaged" error).
  5. Verify it unpacks and finds the browser.