Closed Bug 1528305 Opened 2 years ago Closed 7 months ago

Behavior on meta and location.href redirects to an unknown protocol can break pages.

Categories

(Core :: DOM: Navigation, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla76
Webcompat Priority ?
Tracking Status
firefox67 --- wontfix
firefox76 --- fixed

People

(Reporter: twisniewski, Assigned: emilio)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-needed, site-compat, Whiteboard: [webcompat])

Attachments

(1 file)

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).

Flags: webcompat?
Component: DOM: Core & HTML → Document Navigation

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

Webcompat Priority: --- → ?

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).

Summary: Behavior on location.href redirects to an unknown protocol can break pages. → Behavior on meta and location.href redirects to an unknown protocol can break pages.
Duplicate of this bug: 1484609

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.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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)

Flags: needinfo?(twisniewski)
Priority: -- → P3

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).

Flags: needinfo?(twisniewski)

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?

Flags: needinfo?(annevk)

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?

Flags: needinfo?(annevk)
Flags: needinfo?(emilio)

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.

Assignee: nobody → emilio
Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8aeb06899b10
Don't show an error page for unknown protocols for page-triggered navigations that replace a document. r=mattwoodrow
Backout by ncsoregi@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2998408f57b1
Backed out changeset 8aeb06899b10 for failures on test_location_href_unknown_protocol.html. CLOSED TREE
Blocks: 1625530

Will follow-up in bug 1625530.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/795fea584885
Don't show an error page for unknown protocols for page-triggered navigations that replace a document. r=mattwoodrow
Status: REOPENED → RESOLVED
Closed: 2 years ago7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76
Blocks: 1626068

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>?

Flags: needinfo?(emilio)

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

Flags: needinfo?(emilio)
Duplicate of this bug: 1623255
You need to log in before you can comment on or make changes to this bug.