STEPS TO REPRODUCE: 1) Install https://addons.mozilla.org/en-US/firefox/addon/new-tab-override/ 2) Go into its settings and set it to use "about:blank" as the new-tab page. 3) Open a tab. EXPECTED RESULTS: URL bar is blank, I can type in it. ACTUAL RESULTS: URL bar has "about:blank" in it text caret is after it, so typing more or less fails until I delete the extra text. ADDITIONAL INFORMATION: * Navigating to about:blank via the URL bar does _not_ have this problem. * Opening a new window does not have this problem. * This is a regression, presumably sometime in the past month (I just updated nightly).

Regression range on nightlies: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b996cabc7ef54bbe050d647494bf00d668ec52e6&tochange=b2a9a4bb5c94de179ae7a3f52fde58c0e2897498

These weird about:blank pages also seem to have a CSP which prevents javascript: URL execution, which normal about:blank pages do not...

Local bisect says this is a regression from bug 1398713. Which makes sense, because about:blank ends up inheriting the triggering principal. That seems ... undesirable in this case.

In particular, perhaps this loadURI call should be passing LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL ?

There are several loadURIWithFlags calls getting the extension principal, will need to evaluate which ones need the flag.

I'm honestly not sure this is the wrong behavior. Or, at least, if it is, it's a case of damned if we do, damned if we don't. You may not wan about:blank to inherit a principal in this case, but there are certainly other cases where the extension will expect it to, the way it does when they create an iframe or use window.open()

We could work around this in the 'blank' determination in the URL bar code by exception web-extension controlled about:blank and allowing that to blank the url bar? Though that won't address (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #2) > These weird about:blank pages also seem to have a CSP which prevents > javascript: URL execution, which normal about:blank pages do not... I'm a little bit confused why this affects the new tab pages but not the new windows (per comment #0) .

I'm happy to do the work here, but it isn't clear to me whether it should be done...

> Or, at least, if it is, it's a case of damned if we do, damned if we don't. Well, can we at least unbreak the new tab override extension? If that means giving them an API that explicitly lets them load the desired URL without weird inheritance bits, great. Right now this is making actually using the browser pretty hellish for me. :( In general, it seems like if we don't know what behavior is right on a case by case basis that means the extension should be able to pick the behavior that makes sense in its context...

> I'm a little bit confused why this affects the new tab pages but not the new windows (per comment #0) . New windows load the homepage by default, which I have set to about:blank in preferences. That case is not going through the extension at all. New tabs try to loadabout:newtab no matter what the homepage is, so I have install an extension that does what I actually want. ;)

> to loadabout:newtab "to load about:newtab". ;)

Ping? I've had to downgrade nightly and disable updates because of this bug...

Kris is thinking about this and I'd like his thoughts before doing anything. If I were to do anything, I'd go with the suggestion from Gijs, but that leaves the CSP issue still.

Yeah, the CSP issue is what largely drove me to revert; it made looking up regression ranges really painful. :(

(In reply to :Gijs from comment #7) > I'm a little bit confused why this affects the new tab pages but not the new > windows (per comment #0) . Also, notably, we don't set a triggering principal when loading URLs using windows.create... :( (In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #9) > > Or, at least, if it is, it's a case of damned if we do, damned if we don't. > > Well, can we at least unbreak the new tab override extension? If that means > giving them an API that explicitly lets them load the desired URL without > weird inheritance bits, great. Right now this is making actually using the > browser pretty hellish for me. :( I guess we could add a flag. I'm not really opposed to it. But this is also a weird corner case. about:blank was previously the only URL that these kinds of extensions could redirect the new tab page to without the URL being visible. And that was basically a fluke. If the CSP issue doesn't matter, we should probably just hide about:blank URLs for extension-created about:blank pages, and just show the extension name in the site identity box. If it does, we should really probably just support using about:blank as the new tab page as a built-in feature.

The CSP issue matters to me, because it breaks bookmarklets implementing multi-argument bookmark keywords... > If it does, we should really probably just support using about:blank > as the new tab page as a built-in feature. I would _love_ that, again personally. I got very sad when we removed support for that as part of our attempts to push the new-tab page on everyone.

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #16) > we should really probably just support using about:blank as the > new tab page as a built-in feature. Isn't that already the case since bug 1417155?

Oh, as of 3 days ago? ;) Yes, it looks like that does what I want, and now I can stop using the new tab override extension!