Related Firefox bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1321305
Related Edge bug report: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10022307/

Some notes:

* Opera Presto restricted navigation for HTTPS pages. This is not a good solution for a future where we want all pages to use HTTPS. It probably does not cater to the current OAuth pages either.

* Mobile browsers often re-display the address field if navigation occurs, so the user at least has a chance to see it. Whether or not the user pays attention to it is another matter.

* Any implementation that relies on modal dialogs is undesirable, since it breaks user interaction flow, and trains users to blindly click "OK" on any dialog they see.

Alternative solutions:

* If cross-origin opener navigation is initiated, the new URL could be opened as a new tab instead (this might be abused as a way to open unrequested popups, but perhaps could be limited to just one, or use the popup blocker click detection in some way).

* Highlight the address field when the opener tab is next focused, to draw the user's attention to it. (UI fix rather than engine fix.)

* Rather than just tying it to the cross-origin nature of the .opener and .self, it could also be related to whether the new URL would have a different origin to the original URL in the .opener. Eg. foo.com opens example.com in a popup, example.com tries to say .opener.location='http://foo.com/bar', this could be allowed because it does not change the origin of the opener. This should reduce the number of false positives, and might allow some more of those OAuth pages to work seamlessly.

> Any implementation that relies on modal dialogs is undesirable, since it breaks user interaction flow

I think that this is actually something good, since it stimulates web-developers to use alternative, safer mechanisms. The biggest problem would be the transition period. I think that a decent timeline would be to start out with a not-too-intrusive solution (any of your proposed solution will do), after which WHATWG can work on a proper mechanism to "authorize" safe use of `window.opener`. When this is in place then the not-too-intrusive solution can be replaced with an intrusive solution. By then web developers will have an alternative which they can migrate to. 

Tagging as Feature request.

This seems like festure request and hence marking it as untriaged.

CCing some Enamel folks.

(UI>Browser>Navigation label only sort of makes sense; not sure where else to put this)

I think that some kind of fullscreen-like notification could work, but we'd have to think carefully about what it should say and when it fire so that it would be effective. I like the idea in comment 2 about only firing if the opener is navigated cross-origin. If we show it less often in common harmless scenarios, users will pay more attention when they see it.