Repository navigation
macOS: open magnet links from browsers in Frame Player - #65
Conversation
Review fixes on top of the contributor's commit: - `magnet` leaves the deep-link plugin's `schemes`: the NSIS template turns that list into Software\Classes keys, which would take magnet: from the viewer's torrent client at every install and update and delete it on uninstall. Info.plist alone declares it on macOS. - The native magnet inbox goes: the plugin already re-emits every URL of the Apple Event and keeps it for getCurrent, so each link arrived twice and a two-second window was deduplicating them. - A magnet raises the link box with the link typed in and leaves "Open" to the viewer, as an invitation does: a page can fire the scheme without a click once the browser always allows it, and opening on arrival stopped the film and joined a swarm the page chose. - No second magnet parser: the contents go through submitLink like a pasted link and fail there in the same words, so the technical error string goes. - The rule is written down in sources-and-privacy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Thanks for this, clicking a magnet in the browser and landing in the player is a real improvement. I pushed one commit on top of yours instead of asking for another round. Three changes:
The native inbox is gone. On macOS the plugin already passes on every URL from the Apple Event and keeps it for The magnet now opens the link box with the link already filled in, and the user starts it with Open or Enter. Room invitations work the same way. A web page can trigger the scheme without a click once the browser allows it, and opening on arrival would stop playback and announce the user's IP to a swarm the page picked. The link goes through the same path as a pasted one, so the separate validation and its error string aren't needed anymore. If you can, please try the branch on your Mac with a real browser click, both with the player closed and with it already running. |
The player is entered as one candidate for `magnet:` rather than its owner: a ProgId of its own (`FramePlayer.Magnet`) named in `Software\FramePlayer\Capabilities\URLAssociations` and listed in `RegisteredApplications`. `Classes\magnet` — the viewer's torrent client — is never touched, so the player appears in Default apps and the open-with picker and changes nothing until it is chosen. The installer writes the keys and the uninstaller removes them (not in update mode, and only while they still point at its own executable); a portable copy's handler switch writes and gives back the same keys. The scheme is not the deep-link plugin's, so its own argv check passes over it: a link reaching a running player is forwarded by `deliver_deep_links`, and a cold start is fetched once with `take_launch_magnet`. Both land in the same `offer` path as on macOS. Refs risenxxx#68 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
What this does
Frame Player already plays magnets pasted into Open link, but macOS does not register
magnet:in the app bundle. Clicking a magnet link in a browser therefore cannot open it directly in Frame Player. Just declaring the scheme is not enough: resolving torrent metadata takes time and without the link dialog the user sees the unchanged start screen.This PR:
magnet:alongsideframeplayer:in the macOSInfo.plistand Tauri deep-link configuration.RunEvent::Openedmagnet URLs in a native inbox and drains it after the webview/player is ready (cold and warm launches; deduplicates plugin and native event delivery).openTorrentpath with the Link dialog visible, showing metadata-lookup progress and any failure instead of an apparently idle start screen.No AppleScript, helper app, or Accessibility permissions required. No changes to torrent downloading internals.
Verification
magnet:delivery intosubmitLink/openTorrentand the corrected dialog behavior locally.bun run gatespasses (45 test files / 711 tests), including type check, import/rune checks and changelog checks.