See bug 1528305 and the dev-platform thread.

My proposal (Anne deserves credit for the last bit) is:

• Make subframes never show the unknown protocol error.

• Make non-fetch protocols always force noopener. That way you can't observe what happened to a window.open'd url with these schemes.

It's not clear if we can do this for the case there's a redirect to that URI from an http(s) url, though?

I'd first like to take a step back to more fully capture the non-fetch scheme cases:

1. We know it and dispatch to an external application.
2. We know it and translate to an HTTP(S) URL. (I.e., registerProtocolHandler(); might be restricted to secure contexts these days.)
3. We do not know it.

2 is problematic for the first part of your proposal, unless we only handle them for top-level navigations and treat them as 3 in other contexts. I think only handling them for top-level navigations would be acceptable, for what it's worth, and I've been advocating that for a while.

For top-level navigations noopener was more of the effect I was after, bug 1613066 (COOP) offers the better primitive. This would

1. Close the current browsing context from the perspective of the opener.
2. Create a new browsing context to navigate to the non-fetch scheme.
3. Work for redirects as it's enforced as part of the response, not the request.

If we can make this work I suspect other browsers would be interested in following and standardizing upon this.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

To offer some context here:

Yes, registerProtocolHandler is restricted to secure contexts.

As discussed in https://github.com/whatwg/html/issues/5289 , not allowing external protocol links in iframes is a non-starter (cf. bug 1650162) but we can open them in a separate toplevel browsing context that isn't linked, and that should work.

With that, is fixing this "just" a question of implementing comment #0? I'd expect that not showing the error page would mean conditioning in the docshell code showing the error page based on whether we're in a toplevel frame, and forcing no-opener would have to ( /me handwaves) happen somewhere in the window.open code?

If navigating a subframe to a non-fetch scheme always ends up opening a popup it seems there would not be any error pages there except perhaps in these (noopener) popups.

Yes, I think that sounds about right. Forcing noopener for window.open() may want to be around here: https://searchfox.org/mozilla-central/rev/8f97d6d022bd18d4c3138bf5f13f4144ac334d82/dom/base/nsGlobalWindowOuter.cpp#7226

Not sure if following links and such follows that codepath though.

Reading through bug 1650162 again I'm wondering about two things:

1. Did Microsoft Teams and other sites navigate a frame from another origin or was it all same origin?
2. How can the frame's contents not have a global associated with it? That should only be possible if it's not in the document tree.

(In reply to Anne (:annevk) from comment #6)

Reading through bug 1650162 again I'm wondering about two things:

1. Did Microsoft Teams and other sites navigate a frame from another origin or was it all same origin?

They were generally frames created without anything in it apart from the protocol, so they would have had a same-origin about:blank page loaded in them if you tried to actually access the contents of the frame.

2. How can the frame's contents not have a global associated with it? That should only be possible if it's not in the document tree.

Right, it either wasn't in the document tree or was hidden, IIRC, see https://bugzilla.mozilla.org/show_bug.cgi?id=1650162#c32 . Opening the devtools inspector forced us to create the about:blank window + document which created the window global. I think otherwise the global might only be created once it's needed?

I see, as an optimization that makes sense. (It would have to be in the tree for something to be created though, lazily or otherwise.) Thanks!

This has gotten a bit more visibility and scrutiny via https://schemeflood.com/ , articles/posts linking to it and bug 1711084