1541909 - registerProtocolHandler URI scheme character whitelist is too limited

Status: RESOLVED INVALID

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

Description

[izquxnuhb]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

Navigate to a website, example.com will do.
Open console, execute the following:

navigator.registerProtocolHandler("web+scheme-test",
				"https://example.com/%s",
				"Scheme test");

Actual results:

Protocol registration prompt does not appear. Permission denied error is logged in the console.

Expected results:

Protocol registration prompt should appear - as it does when using "web+" followed by lowercase ASCII characters only. This used to work cca 2 months back, I guess on version 65, so it was likely broken by a recent change. A quick look at https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml suggests that at least dash, dot, plus and numbers should be added to the whitelist.

Comment 1

[David Sacal]

Hi,
i wasn't able to reproduce this behaviour on Ubuntu 18.04 64 or Windows 10 Pro 64 using Firefox 65.03 or Nightly 67.09 following the described steps. Instead i'm getting the "registerProtocolHandler is not a function" error in both cases. Please try to reproduce the error on the latest nightly available in here https://nightly.mozilla.org/ and reach us out back.

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

(In reply to David Sacal from comment #1)

Hi, i wasn't able to reproduce this behaviour on Ubuntu 18.04 64 or Windows 10 Pro 64 using Firefox 65.03 or Nightly 67.09 following the described steps. Instead i'm getting the "registerProtocolHandler is not a function" error in both cases.

I think that's because registerProtocolHandler is only available in secure context (e.g. https://example.com).

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

Running a mozregression to see when it regressed

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

Here's the result of mozregression:

Last good revision: 7ce9fdbbc4b09fbecb57d9856471a2f34234d9b1
First bad revision: 13078c094de950add52190be0e8f8752339c2bc9
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7ce9fdbbc4b09fbecb57d9856471a2f34234d9b1&tochange=13078c094de950add52190be0e8f8752339c2bc9

Gijs, since you're the author of the patches of Bug 1499092, could you have a look please? Thanks!

Comment 5

[:Gijs (he/him)]

I believe this is correct per spec:

https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers

From the "scheme" section:

A scheme, such as "mailto" or "web+auth". The scheme must be compared in an ASCII case-insensitive manner by user agents for the purposes of comparing with the scheme part of URLs that they consider against the list of registered handlers.

The scheme value, if it contains a colon (as in "mailto:"), will never match anything, since schemes don't contain colons.

If the registerProtocolHandler() method is invoked with a scheme that is neither a safelisted scheme nor a scheme whose value starts with the substring "web+" and otherwise contains only ASCII lower alphas, and whose length is at least five characters (including the "web+" prefix), the user agent must throw a "SecurityError" DOMException.

So '-', '.', '+' and numbers are not allowed.

If other browsers do allow them and we're the odd one out, then the spec, its wpt tests, and our behaviour need updating. If we're aligned with everyone else, and you think some of these characters need allowing, that seems like a discussion that needs to happen at the spec level.

Anne, can you doublecheck my reading of the spec here?

Comment 6

[:Gijs (he/him)]

Looks like Chrome at least allows '-', numbers and '.', I haven't tested any other browsers.

Comment 7

[Anne (:annevk)]

Yeah, Chrome appears to use https://url.spec.whatwg.org/#url-scheme-string instead ('+' on top of what you found). Pretty sure Safari doesn't support it.

I filed https://github.com/whatwg/html/issues/4524 to track this.

I don't really feel opinionated on who should change their implementation here.

Comment 8

[Anne (:annevk)]

Resolving as INVALID as Chromium is fixing this on their side (to be as restrictive as the HTML Standard requires): https://bugs.chromium.org/p/chromium/issues/detail?id=1019995.