1056860 - Improve registerProtocolHandler()

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Anne (:annevk)]

Per http://annevankesteren.nl/2014/08/registerprotocolhandler there seems to be some potential to make this feature more attractive to developers. In particular, if we are willing to invest in:

* Implementing `unregisterProtocolHandler()`
* Improving the UI (e.g. make the dialog box more like Chrome)

The cautionary tale is that only Chromium seems to have interest in this feature. However, if tel: and such become more common this might work.

Comment 1

[Anne (:annevk)]

To elaborate on the UI issues:

* We should remove "title" as it allows spoofing. We should probably remove that argument entirely from the method if people agree and coordinate with WHATWG.
* We allow selecting from multiple handlers, but there is no way there to remove a handler there. Even rightclick does nothing. Removing handlers is absurdly hard from the UI.

Comment 2

[Tantek Çelik]

There are other potential uses of this API and related calls.

See research on more such URLs here:

http://tantek.com/2014/084/b1/urls-people-focused-mobile-communication

for this UI/UX use-case:

http://tantek.com/2013/338/b1/people-focused-mobile-communication-experience

which I'm currently attempting to build *without* use of registerProtocolHandler et al - however, those APIs *could* improve the UI/UX beyond what I can build without them, e.g. hide communication methods (or link to an installer) if the user lacks a handler for them (and thus avoid the ugly "unsupported URL" dialogs).

Comment 3

[Karl Dubost💡 :karlcow]

Some questions around it:

As a developer, how do I send the information that my webapp can take care of multiple formats ['image/png', 'image/webp', 'image/jpg', …] by just providing an array?
As a developer, how do I send the information that my webapp can take care of multiple protocols ['http', 'https', …] by just providing an array?
As a user, how do I open a link (href), object (image), selection (text) with a specific webapp listed among others (think contextual menus or modal box of desktop with the usual ones and the others in grey)?
As a user, how do I send multiple objects to the webapp in one shot. (think for example context of multiple selections on a operating system, or multiple text selections in Mozilla browser.)?
As a developer, how do I receive multiple objects?

Comment 4

[Anne (:annevk)]

dveditz, what are your thoughts on comment 1 bullet point 1?

Comment 5

[Andrew Overholt [:overholt]]

needinfo for comment 4

Comment 6

[Daniel Veditz [:dveditz]]

I agree that showing the title in a dialog is too spoofy and Chrome's approach is better. I'll let you guys argue in WHATWG whether that means simply ignoring the value or fighting to drop it from the spec. At https://html.spec.whatwg.org/scratch that Hixie is proposing a 4th optional "disposition" argument, but I don't know if that's an active proposal or something long dormant.

The Firefox implementation does not match the spec wrt the whitelist of schemes. We are using the network.protocol-handler.external. prefs to blacklist known-dangerous schemes, and everything else is allowed because network.protocol-handler.external-default is set to true. These prefs were originally created for the external helper app service and we can't just tweak them to match the registerProtocolHandler spec without breaking the ability to load unknown schemes with services installed on your computer.

In particular this means it's possible to register the url-looking scheme mail.google.com as described at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032974.html

Comment 7

[Anne (:annevk)]

The /scratch proposal is not being actively developed. Filed a bug on removing the title argument and your suggestion we cannot match the specification:

* https://www.w3.org/Bugs/Public/show_bug.cgi?id=26876
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=26877

Comment 8

[Daniel Veditz [:dveditz]]

I'm saying the current code does not match the spec, not that we can't fix it. We can't fix it by flipping the prefs the current code uses because they're shared, but there's no reason we can't change the code. And we should -- the spec is much more thought through than our implementation.

Comment 9

[Nancy Grossman]

Could `moz-extension` template URLs be allowed (bug 1271553)? Currently only `http` and `https` handlers are allowed (bug 354316 comment 14). This would remove an obstacle to migrating several popular add-ons to WebExtensions (bug 1296885 comment 11). Chrome extensions can register `chrome-extension` handlers from the same origin, so this may also remove an obstacle to porting Chrome extensions to Firefox.

Only extension URIs that are marked "web accessible" in the manifest can be loaded by web pages or by other extensions. (I mean Chrome extensions and WebExtensions; I don't know about the others.)

Also, `navigator.registerProtocolHandler` and the Preferences>Applications UI behave oddly in several ways. (a) An origin can register 2+ handler URLs for one scheme. (b) An origin can't remove its handlers. (c) `http://example.com` can register a scheme for `https://example.com` and vice versa. (d) A scheme persists in Preferences>Applications after its last handler is removed. (e) I can register "urn", "Urn", "uRn", and "urN" as different schemes. All are listed in Preferences>Applications, though the "Launch Application" dialogue only "sees" the all-lowercase registration.

Can these be fixed if they're wrong, or else documented with an explanation if they're right?

Chromium's behaviour, for comparison: (a) One handler per scheme per origin. A new registration replaces the site's existing handler. (b) `navigator.unregisterProtocolHandler` is implemented. (c) Disallowed; DOMException. (d) Scheme is dropped from Content settings>Handlers when the last handler is removed. (e) Coerces the scheme to lowercase (or fails if the "web+" prefix has capitals, but that's probably unintended).

Comment 10

[Daniel Veditz [:dveditz]]

I don't see a problem allowing moz-extension. Presumably, though, a web extension might rely on their handler being actually installed so going through the usual "ask the user" prompt could be problematic. Also might be better to use an alternate way to declare protocol handlers in the manifest rather than use the dom API. Would this require permissions? This all seems like a better question for bug 1271553.

The other issues you describe sound like bugs in our implementation, and probably handled best as a separate bug rather than this which is more of a feature request (for unregister and better UI).