The rewrite rules catch the original link on the way back out too, so in the browser they are installed in, "Open on <platform>" redirects straight back here. Fixed by handing the address to a different browser through its own URL scheme.
/ gets a picker for which browser, revealed only once the script runs (the choice does nothing without it):
Browser
macOS
iOS
Chrome
googlechromes://…
googlechromes://…
Edge
microsoft-edge:https://…
microsoft-edge-https://…
Orion
orion://open-url?url=…
orion://open-url?url=…
Firefox
—
firefox://open-url?url=…
Firefox on macOS registers no scheme, so it is only offered on iOS; Safari Technology Preview likewise, and Safari itself is the browser being escaped. iPadOS reports itself as MacIntel, so the two are told apart by touch points rather than the platform string.
Notes
Until a browser is chosen there is no "Open on …" button. The plain address is the one thing it must not offer, since following it only comes back here. The link ships hidden and the script reveals it along with the scheme — so with JavaScript off, or the default left alone, the copy button and the selectable URL are the whole of it, which is all that was ever load-bearing.
Stored in localStorage, per the issue — not a cookie and not synced. Which browsers are installed is a fact about the device, and the phone's answer is not the Mac's.
A schemeless or unknown choice keeps the button hidden. A dead custom scheme opens nothing at all, so there is nothing worth showing.
The scheme table is public/browsers.js rather than more of app.js so test/browsers.test.ts can pin it; that is what the allowJs line in tsconfig.json is for.
Verified end to end by driving the real page in Chromium under both a macOS and a spoofed iOS navigator: the picker reveals with the right options, the choice survives navigation, the button appears and disappears with it, and the hrefs come out as the table above. npm test (133) and npm run typecheck pass.
The rewrite rules catch the original link on the way back out too, so in the browser they are installed in, **"Open on \<platform\>" redirects straight back here**. Fixed by handing the address to a different browser through its own URL scheme.
`/` gets a picker for which browser, revealed only once the script runs (the choice does nothing without it):
| Browser | macOS | iOS |
| --- | --- | --- |
| Chrome | `googlechromes://…` | `googlechromes://…` |
| Edge | `microsoft-edge:https://…` | `microsoft-edge-https://…` |
| Orion | `orion://open-url?url=…` | `orion://open-url?url=…` |
| Firefox | — | `firefox://open-url?url=…` |
Firefox on macOS registers no scheme, so it is only offered on iOS; Safari Technology Preview likewise, and Safari itself is the browser being escaped. iPadOS reports itself as `MacIntel`, so the two are told apart by touch points rather than the platform string.
### Notes
- **Until a browser is chosen there is no "Open on …" button.** The plain address is the one thing it must not offer, since following it only comes back here. The link ships hidden and the script reveals it along with the scheme — so with JavaScript off, or the default left alone, the copy button and the selectable URL are the whole of it, which is all that was ever load-bearing.
- **Stored in `localStorage`**, per the issue — not a cookie and not synced. Which browsers are installed is a fact about the device, and the phone's answer is not the Mac's.
- **A schemeless or unknown choice keeps the button hidden.** A dead custom scheme opens nothing at all, so there is nothing worth showing.
- The scheme table is `public/browsers.js` rather than more of `app.js` so `test/browsers.test.ts` can pin it; that is what the `allowJs` line in `tsconfig.json` is for.
Verified end to end by driving the real page in Chromium under both a macOS and a spoofed iOS `navigator`: the picker reveals with the right options, the choice survives navigation, the button appears and disappears with it, and the hrefs come out as the table above. `npm test` (133) and `npm run typecheck` pass.
Closes #7
The StopTheMadness rules are indiscriminate, which is the point, but they
catch the link on the way back out as well: in the browser they are
installed in, "Open on <platform>" redirects straight back here. The one
button meant to reach the app is the one that cannot.
Handing the address to a different browser is the way past it, and the only
way to do that from a page is that browser's own URL scheme. `/` gets a
picker for which one; the choice lives in that browser's localStorage,
because which browsers are installed is a fact about the device and the
phone's answer is not the Mac's.
The scheme table is its own module so a test can pin it -- every browser
spells it differently, and Edge differs between macOS and iOS. Firefox has
no scheme on macOS, so it is only offered on iOS, and an unknown or
schemeless choice keeps the plain link rather than producing a dead one.
The markup still carries the plain https address and the script swaps it
afterwards, so nothing changes without JavaScript. Once a browser is
chosen the button says which, since a scheme for a browser that is not
installed opens nothing and the tap would otherwise be silent.
Closes#7
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01KF5YF3iZVKbezwALap8LYd
The plain address is the one thing that button must not offer -- followed
in the browser the rewrite rules are installed in, it comes straight back
here -- so there is nothing to show until there is a browser to hand it to.
The copy button and the selectable URL were always the part carrying the
weight; the open link now ships hidden and the script reveals it along with
the scheme.
That also settles what the button should say. It went back to "Open on
<platform>": the browser's name was there to explain a tap that went
nowhere, and a button that is not shown until it works needs no such
explanation.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01KF5YF3iZVKbezwALap8LYd
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The rewrite rules catch the original link on the way back out too, so in the browser they are installed in, "Open on <platform>" redirects straight back here. Fixed by handing the address to a different browser through its own URL scheme.
/gets a picker for which browser, revealed only once the script runs (the choice does nothing without it):googlechromes://…googlechromes://…microsoft-edge:https://…microsoft-edge-https://…orion://open-url?url=…orion://open-url?url=…firefox://open-url?url=…Firefox on macOS registers no scheme, so it is only offered on iOS; Safari Technology Preview likewise, and Safari itself is the browser being escaped. iPadOS reports itself as
MacIntel, so the two are told apart by touch points rather than the platform string.Notes
localStorage, per the issue — not a cookie and not synced. Which browsers are installed is a fact about the device, and the phone's answer is not the Mac's.public/browsers.jsrather than more ofapp.jssotest/browsers.test.tscan pin it; that is what theallowJsline intsconfig.jsonis for.Verified end to end by driving the real page in Chromium under both a macOS and a spoofed iOS
navigator: the picker reveals with the right options, the choice survives navigation, the button appears and disappears with it, and the hrefs come out as the table above.npm test(133) andnpm run typecheckpass.Closes #7