Chromium: prompt user to approve protocol handler registration

[lidel]

Firefox supports preregistration of handlers via protocol_handlers in webextension Manifest, but Chromium does not:

(github) The title of the Chromium issue was confusing, so to clarify: https://bugs.chromium.org/p/chromium/issues/detail?id=64100#c59 ; basically the owner of the extension code had concerns about the approach with protocol_handler in the manifest and what ended up being implemented in Chrome is giving special power to registerProtocolHandler in web extensions.

Talked with Igalia today, and we will ask Google to reconsider protocol_handlers support in Chromium: landscape is bit different, Microsoft Edge's improves the way PWA and we may find alignment / deduplication of efforts around this.

That being said, these things take way more time that we initially anticipated, so it may be useful to implement a stop-gap solution, as protocol_handlers ETA in Chromium is unknown.

First, understand what is possible

https://bugs.chromium.org/p/chromium/issues/detail?id=64100 is unclear if 3) Allowing extensions to redirect to a third-party domain (instead of chrome-extension://<id>/...) was implemented.

My suggestion is to make a PoC first that tries to register handler via registerProtocolHandler from browser extension's background page:

1. https://dweb.link/ipfs/?uri=%s
2. chrome-extension://<id>/dist/router.html#uri=%s

This will inform our next step.

Ideally, we would point at (1), if we can't then we would create a router page (2) which has JS that reads URI from window.location.hash and performs window.location.replace to the correct destination.

Proposed implementation

• Create utility function that checks if ipfs:// and ipns:// handlers are registered via registerProtocolHandler, and if not, attempt to register a handler.

  • If possible, we want to register a public gateway as a handler (https://dweb.link/ipfs/?uri=%s).
    This way it works when local node is off or redirect is disabled, IPFS URIs still resolve, but we need to work with whatever is actually possible in Chromium.

• When user installs IPFS Companion OR toggles global redirect, we run the check again.

  • This should be good enough to ensure user has opportunity to approve handler registration via user gesture if they missed this after initial install.

cc @autonome @whizzzkid ipfs/in-web-browsers#168 #164

[lidel]

Discussed this with Javier from Igalia and we should be able to trigger registation of handler that points at dweb.link because our host_permissions are broad enough.

The caveat is that registerProtocolHandler can't be called from service worker, and we need to open HTML in a new tab – let's try reusing our existing post-install welcome page for this.

@whizzzkid this is not blocked by MV3, we could do this in MV2 – code remains the same. Will you have time to give this a try before digging deep into MV3?

[lidel]

Note from meeting with Igalia

• we need this as a PoC to demonstrate downsides of the UX proposed by Chromium maintainers, and argue for better approach
• if handler is missing, prompting user every time peerCount > 0 is a good way to demonstrate how annoying this API is

[SgtPooki]

seems related: https://github.com/little-bear-labs/ipfs-chromium/blob/jt/working_with_planb_changes/README.md

[lidel]

also related: #164 (comment) (no ETA, so this issue remains useful and open).