Repository navigation
fix: gate pods on WebAssembly JSPI and drop the iOS user-agent check - #51
Merged
Merged
Conversation
BrowserPod 3.1.0+ starts its runtime through WebAssembly.promising, so browsers with Atomics.waitAsync but no JSPI (Safari 16.4-26, Firefox 145-152) passed podBlocker() and then failed during boot. Check for JSPI too, and state the real minimum versions in the overlay and the README. With the feature check deciding, the iOS user-agent check is redundant: iOS 26 and older now fail it, and the global modal also wrongly blocked Java projects, which run on CheerpJ and need neither JSPI nor cross-origin isolation. The README and embedding guide now say Java embeds don't need the isolation headers. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Deploying browsercode with
|
| Latest commit: |
b306b7d
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://82778c18.browsercode.pages.dev |
| Branch Preview URL: | https://fix-browser-checks.browsercode.pages.dev |
Testing the JSPI gate on an iPhone running iOS 27.0.1 showed Safari 27 supports JSPI, so iOS passes podBlocker() and the pod boots. Process execution is what fails: agents hang forever on "Starting Claude..." at bootCLI's pod.run, and the IDE errors at the dev server stage. The cause is unknown, suspected to be an iOS memory limit rather than a missing WebAssembly feature, so no feature check can stand in for it yet. Bring isIos() back as an 'unsupported-platform' blocker, checked before the feature detection because iOS clears all of it. The check lives in podBlocker() rather than in a global modal, so CheerpjRuntime.blocker() still returns null and Java projects keep running on iOS, which is what dropping the modal was for. The overlay gets its own branch: falling through to the JSPI text would tell an iOS 27 user to upgrade to Safari 27. Marked a stopgap in the doc comment, to remove once pods run there. Also corrects the comment above the AgentShell gate, which still explained it in terms of SharedArrayBuffer alone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
BrowserPod 3.1.0+ starts its runtime through
WebAssembly.promising(JSPI) with no fallback (bfe367fin BrowserPod).podBlocker()only checkedAtomics.waitAsyncand isolation, so browsers without JSPI passed the check and then broke partway through boot.podBlocker()now also requiresWebAssembly.promising. Safari 16.4–26 and Firefox 145–152 get the "Incompatible Browser" overlay instead of a broken pod.agents/boot.ts.podBlocker()instead: Safari 27 does support JSPI, so iOS clears the feature check, boots a pod, and then fails atpod.run— agents hang on "Starting Claude...", the IDE errors at the dev server stage.isIos()now returns an'unsupported-platform'blocker, checked before the feature detection, with its own overlay branch. A stopgap until the cause is known (suspected memory limits). Java keeps working on iOS, sinceCheerpjRuntime.blocker()still returns null.Plus README updates.