(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #10)
Alright, that regression range is definitely wrong. Gijs checked, and the actual behavior change is from bug 1370971. And in fact, flipping that pref ("dom.noopener.newprocess.enabled") back to false changes the behavior back to about:blank.
So I think there's still kinda a bug here, due to the inconsistency between same-process and different process.
In the different-process case, ContentChild::ProvideWindowCommon sends CreateWindowInDifferentProcess, which ends up doing ContentParent::CommonCreateWindow with aLoadURI == true. That then calls nsIBrowserDOMWindow::OpenURIInFrame.
In the same-process case, ContentChild::ProvideWindowCommon sends CreateWindow, which ends up doing ContentParent::CommonCreateWindow with aLoadURI == false. That calls nsIBrowserDOMWindow::CreateContentWindowInFrame.
Now if you compare https://searchfox.org/mozilla-central/source/browser/base/content/browser.js#5721-5725 to https://searchfox.org/mozilla-central/source/browser/base/content/browser.js#5713-5719 (the browser.js implementations of openURIInFrame and createContentWindowInFrame), the latter passes a null URI to getContentWindowOrOpenURIInFrame. So it causes addTab to be called with no URI and the URL bar does not get set to anything interesting. But openURIInFrame passes the URI through, so ends up setting the URL bar to that URI.
It's still not 100% clear to me what behavior we really want here, but we should definitely have it be consistent for the same-process vs different-process cases!
Going to be slightly controversial: I think we want the URL to show up (in the general case), per bug 610357 and the mess of already-fixed bugs in that department. Basically, we want the URL bar to show the user where they're heading especially in an otherwise empty/clean tab, which is what the tabbrowser.js code does.
If/when the load is redirected to the unknownContentType dialog and its friends and/or doing a download, we want it to be cleared. But the URL should show up so the user has feedback about the fact that they opened a URL.
So I think we need to do 2 things:
- fix the non-OOP case to also send the URL (and/or figure out if there was a conscious decision that led to it not doing so)
- fix the case where we don't load a document to force a URL bar update so we show about:blank.
I'm a little bit confused about where to do the latter, because casual source trawling would suggest somewhere around https://searchfox.org/mozilla-central/rev/7abb9117c8500ed20833746c9f8e800fce3a4688/uriloader/exthandler/nsExternalHelperAppService.cpp#1569 ... which is clearly not working atm, viz. bug 1531289.