In Fennec (and Firefox's responsive design view), attempts to set location.href to an unknown protocol such as bilibili://whatever result in the tab switching to an error page.

In Chrome Mobile, a warning is instead logged to the console and the attempt is ignored: Navigation is unreachable: bilibili://video/43248171?h5awaken=<snip>%3D%3D&page=0

This results in a broken experience on bilibili.com for Firefox users, which has a load listener that attempts such a redirect, breaking the experience for users (though it can take a long time for the page to fire the load event).

(Note that Chrome desktop will trigger an XDG prompt to let the user open the redirected URL to another program, but likewise will not actually change to an error page).

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

See bug 1547409. Migrating whiteboard priority tags to program flags.

This also affects meta redirects. For instance Deezer has one of these, breaking at least some of their pages on Firefox (but not Chrome, which seems to just ignore meta redirects to unknown protocols, not indicating anything in the web console or the network devtools panel).

See also Bug1484609 Comment #1

We still wanted to show the error page for URLs manually entered by the user through the browser chrome. Unfortunately the protocol handling code currently doesn't have a good way of finding out who caused the URL load, so as a workaround we suppress the error page if the load happened within one second of some user input within the web content (bug 1278581). This handles cases where the user directly clicks on some link with an unknown protocol, but of course doesn't work if the page itself tries to open an unknown protocol without any user interaction.

Zhihu (the most popular QA site in China) has joined the club to present Firefox users this error page by redirecting to zhihu:// on load :-(.

Thomas, do you know if there is some usecase for the weird unknown protocol loads?
But basically, should we not show error page for unknown protocol case?

(I don't know what "This results in a broken experience on bilibili.com for Firefox users, which has a load listener that attempts such a redirect, breaking the experience for users (though it can take a long time for the page to fire the load event)." means)

I don't see any mystery involved; it's just to get native apps to open when they are installed.

In this case, the browser would presumably offer to open the Bilibili video player native app to view the given video by URL, if it has been installed and registered as the protocol handler for bilibili:// URLs.

I'm guessing that since Chrome essentially just ignores the attempt if there is no protocol handler, and there is no way for sites to confirmed for themselves whether it's acutally registered, some just spam the attempt just in case it happens to work. And of course, Firefox users end up suffering for it.

I'm honestly not even sure if there's a compelling reason to show an error page here if the protocol is unknown. If it's just for informational purposes for developers, then logging the attempt to the console like Chrome does seems sufficient to me (but I've been known to be wrong).

I guess this is an issue on desktop as well per https://github.com/webcompat/web-bugs/issues/50679... Is there anything here that the spec enforces? Or should we potentially also ignore navigations to unknown protocols?

Through navigation this eventually ends up at https://html.spec.whatwg.org/#process-a-navigate-url-scheme which allows for both behaviors, though at point some events related to unloading might have been dispatched already I think. I think it's reasonable to make changes here, both in implementation and specification, but ideally any such effort involves a bunch of testing of the details of Chrome and Safari's behavior. E.g., what if a https:// redirects to a bilibili:// URL. Are there differences between top-level and frame-level navigations? Is most of the navigation algorithm bypassed or do the various events end up dispatching?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8637a314534eca31bc34a7b817ac948b017d504e has a potential patch for this.

Pages apparently do this to try to open to native apps, and that on Firefox
causes an error page to be shown if the app is not installed, which is pretty
bad.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cdc4e58995adaf0ce4daf13023d55fe6e332082a (it's green and I think it's the behavior we want).

Backed out changeset 8aeb06899b10 (bug 1528305) for failures on test_location_href_unknown_protocol.html.

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Csuperseded%2Ctestfailed%2Cbusted%2Cexception%2Crunnable&searchStr=linux%2C18.04%2Cx64%2Cquantumrender%2Cdebug%2Cmochitests%2Cwith%2Cfission%2Cenabled%2Ctest-linux1804-64-qr%2Fdebug-mochitest-plain-fis-e10s-16%2Cm-fis%2816%29&revision=8aeb06899b10db711638442fd53c0302163d1e82&selectedJob=295004263

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=294997926&repo=autoland&lineNumber=11432

Backout: https://hg.mozilla.org/integration/autoland/rev/2998408f57b103e0ca4256d55bca54c1f046aca6

Will follow-up in bug 1625530.

https://hg.mozilla.org/mozilla-central/rev/795fea584885

Posted site compatibility note.

I've added a note to the MDN Fx 76 rel notes to cover this:

https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/76#DOM

Do you think this needs anything else? I could perhaps add a data point to the browser compat data for localtion.href and <meta>?

Yeah, I don't think it does, thanks!