Closed Bug 1468191 Opened 6 years ago Closed 6 years ago

Opening "about:home" is now forbidden

Categories

(WebExtensions :: Frontend, defect)

61 Branch
defect
Not set
normal

Tracking

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox60 unaffected, firefox61 wontfix, firefox62 wontfix, firefox63 wontfix)

RESOLVED WONTFIX
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix

People

(Reporter: juraj.masiar, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180607135512

Steps to reproduce:

Using Firefox 61:
1) open any add-on page with "tabs" permission
2) execute: `browser.tabs.create({url: 'about:home'})`


Actual results:

Error: Illegal URL: about:home


Expected results:

New tab with about:home page should be displayed.

NOTE:
Navigation to about:home was working in Firefox 60, now it's blocked.
Navigation to about:blank is still working.
Update also fails: `browser.tabs.update({url: 'about:home'})`

Is there a reason to block about:home? 
My add-on is overriding new tab page but not everybody want it like that so I added an option to redirect to about:home that doens't work now.
Product: Toolkit → WebExtensions
This worked in 60 and does not work as of 61.
can we get a regression range for this issue? thanks!
Flags: needinfo?(cosmin.badescu)
Attached image Bug1468191.gif
I can reproduce this issue on Firefox 61.0rc-build3 (20180621125625) and Firefox 62.01 (20180621220127) under Win 7 64-bit and Mac OS X 10.13.3

Please see the attached video.

I did a regression window and observed that Bug 1438367 is the one that caused this regression.

Last good revision: abdaa1f91c4c9ec56f77af5c9310eb20e84b6b8d
First bad revision: 2a5a941c2db9c64d18a7b56cb7112ae7ac14fc52
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=abdaa1f91c4c9ec56f77af5c9310eb20e84b6b8d&tochange=2a5a941c2db9c64d18a7b56cb7112ae7ac14fc52
Flags: needinfo?(cosmin.badescu)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Unspecified → All
Hardware: Unspecified → All
Blocks: 1438367
Flags: needinfo?(gijskruitbosch+bugs)
I think any kind of plan here is up to the webextensions team. Perhaps they want to fix bug 1368700 instead or provide some other runtime way to load this page. In any case, about:newtab and about:home having different permissions was a bug, and I don't think we're going to "unfix" it - if anything, I'd expect us to get rid of about:home as a separate URL eventually.
Flags: needinfo?(gijskruitbosch+bugs)
As Gijs suggested, the different permission for about:home/newtab was not intended, so reverting bug 1438367 allowing any page to load about:home again is not desired.

If existing extensions are indeed doing `browser.tabs.create({url: 'about:home'})`, perhaps a narrow backwards-compatible fix is to detect the specific about:home url and open it? Not sure if this would be marked deprecated somehow and provide a different API to "open default home page in a tab"?

mixedpuppy, not sure who should make the call on fixing the regression to uplift for 62 vs a new api, etc?
Flags: needinfo?(mixedpuppy)
ISTM that we should be able to allow extensions to load uris marked with URI_SAFE_FOR_UNTRUSTED_CONTENT.  This of course would allow more about: uris to be opened than before, but if they are "safe" why not?  Kris should chime in.

Maybe by doing

if (isSamePage && (otherAboutModuleFlags & nsIAboutModule::MAKE_LINKABLE || BasePrincipal::Cast(aPrincipal)->AddonPolicy()))

See:

https://searchfox.org/mozilla-central/rev/14cb8f1c238735ba1abe18ad44e39808983c2572/caps/nsScriptSecurityManager.cpp#770

https://searchfox.org/mozilla-central/rev/14cb8f1c238735ba1abe18ad44e39808983c2572/caps/nsScriptSecurityManager.cpp#828
Flags: needinfo?(mixedpuppy) → needinfo?(kmaglione+bmo)
In general, I'd like to avoid allowing extensions to open those URLs because they're generally implementation details that are likely to change. We've finally gotten most developers to stop passing "about:newtab" as a URL to tabs.create rather than omitting the URL. I don't want to lose the progress we've made there.
Flags: needinfo?(kmaglione+bmo)
Well, since this is broken in release...and the intention is to remove about:home anyway per comment #4, we should probably just leave it as-is.  I'd prefer to avoid a new api for something with limited lifetime.  Punting to Mike.
Flags: needinfo?(mconca)
Agree we should leave as-is. MDN clearly states that tabs.create() doesn't work with privileged pages, so about:home should never have worked in the first place. Providing a different, less implementation-dependent way for extensions to open the home page would be better.
Flags: needinfo?(mconca)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
See Also: → 1269456
Since this solution was only a workaround for another bug, can we now put higher priority on one of these:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420944
https://bugzilla.mozilla.org/show_bug.cgi?id=1368700

Also you may want to disable "about:blank" as well to be consistent and to prevent future developers from starting using it.
(In reply to juraj.masiar from comment #10)
> Since this solution was only a workaround for another bug, can we now put
> higher priority on one of these:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1420944
> https://bugzilla.mozilla.org/show_bug.cgi?id=1368700
> 
> Also you may want to disable "about:blank" as well to be consistent and to
> prevent future developers from starting using it.

about:blank is a web standard, not an implementation detail, at this point. Extensions are expected to be able to load it.
(In reply to Kris Maglione [:kmag] from comment #11) 
> about:blank is a web standard, not an implementation detail, at this point.
> Extensions are expected to be able to load it.

You say extensions are expected do be able to load about:blank, but the following code is broken since Firefox 60:

browser.tabs.getCurrent((tab) => {
  let tabId = tab.id;
  browser.tabs.update(tab.id, { url : 'about:blank'});
});

It results in a new tab with "about:blank" written in the address bar instead of an empty address bar with the following console message:

> Incorrect argument types for tabs.update
(In reply to Sören Hentzschel from comment #12)
> (In reply to Kris Maglione [:kmag] from comment #11) 
> > about:blank is a web standard, not an implementation detail, at this point.
> > Extensions are expected to be able to load it.
> 
> You say extensions are expected do be able to load about:blank, but the
> following code is broken since Firefox 60:
> 
> browser.tabs.getCurrent((tab) => {
>   let tabId = tab.id;
>   browser.tabs.update(tab.id, { url : 'about:blank'});
> });
> 
> It results in a new tab with "about:blank" written in the address bar
> instead of an empty address bar with the following console message:
> 
> > Incorrect argument types for tabs.update

Please file a separate bug if you haven't already. This is clearly unrelated, because the about:home load "broke" in 61, and you're saying you can't load about:blank since Firefox 60.
(In reply to Sören Hentzschel from comment #12)
> You say extensions are expected do be able to load about:blank, but the
> following code is broken since Firefox 60:
> 
> browser.tabs.getCurrent((tab) => {
>   let tabId = tab.id;
>   browser.tabs.update(tab.id, { url : 'about:blank'});
> });
> 
> It results in a new tab with "about:blank" written in the address bar
> instead of an empty address bar with the following console message:
> 
> > Incorrect argument types for tabs.update

This is an unrelated issue. Extensions can, in general, load about:blank. The tabs.update API, however, currently prohibits loading any URL that inherits the principal of the opener, since that used to cause them to inherit the principal of whatever page was currently loaded into the tab they were updating.

At this point, they should actually inherit the principal of the extension instead, so we've been considering lifting that restriction.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: