How to test for existing ipfs:// protocol handler in Firefox

[olizilla]

Firefox opens iframe with ipfs:// scheme src in a new window.

You can't use ipfs:// as an img src, as it fails with unknown protocol even if you have protocol handler for ipfs. (net::ERR_UNKNOWN_URL_SCHEME in Chrome. Silent fail in Firefox)

You can't simply ask the api. We lost navigator.isProtocolHandlerRegistered from the whatwg spec in https://github.com/whatwg/html/issues/630

Chrome does what you would expect with an ipfs:// scheme url. It tries to load it in the iframe or fails if there is no handler, so by targeting a known resource that uses window.parent.postMessage to let the parent window know it has loaded succesfully, you can verify the existence of a protocol handler.

but how for Firefox?

[olizilla]

@lidel pls do you have wisdom to share?

[lidel]

Hm.. this iframe escaping business sounds like old Firefox bugs listed in https://github.com/ipfs/ipfs-companion/issues/816#issuecomment-565446005 those got fixed around v78.

There are two MVPs for reproducing these old "iframe in a new window" bugs:

• when registering via page: https://bugzilla.mozilla.org/attachment.cgi?id=8649727 (run via npx serve)
• when registering via extension: iframe-escape-webext-protocol-demo.zip (run via npm start)

Both stay in iframe for me in Firefox v88 (so no bug), but just to be sure it is not macOS specific, can you check both?

Also, is the iframe escaping bug present only when Companion is around? Could be that handler works fine on its own, but when a gateway redirect from public to local gateway happens there is additional origin change that was not expected during QA, and Firefox makes that into a new tab (a new bug/regression).