1800995 - Content scripts not injected into new blank tab page (which is no longer about:blank)

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[shiandow]

Steps to reproduce:

After the changes in https://phabricator.services.mozilla.com/D154319 to fix bug 1676492 changing the new tab page to "Blank Page" no longer allows web extensions to inject content scripts into the new blank tab page.

Actual results:

Web extensions cannot inject content scripts into the new blank tab page chrome://browser/content/blanktab.html, among other things this breaks web extensions like Gesturfy/Foxygestures which rely on content scripts to implement mouse gestures.

Expected results:

Allowing content scripts to function is one of the main advantages of using a blank new tab page. I would expect a new version of the blank new tab page to have the same behaviour.

Comment 1

[shiandow]

See also: https://github.com/marklieberman/foxygestures/issues/375 for a discussion in the Foxy Gestures Web extension github repository.

Comment 2

[Daniel Bodea [:danibodea]]

I can't seem to reproduce your issue as gestures don't work in about:newtab or in about:blank pages neither before the mentioned change, nor after it. Please attempt to answer some questions:

1. Which operating system are you using?
2. How exactly do you open a blank tab page on which the gestures no longer work?
3. Which version of firefox allowed these gestures? Or when did this happen?
4. Which browser are you using (Nightly/Beta/LiveRelease version)?
5. Which exact version are you reproducing the problem on?

Thank you for your contribution!

Comment 3

[shiandow]

Hi Bodea,

Thanks for the response. I'm somewhat confused why you seem to be getting different results, but here are the answers to your questions:

1. Windows (7 and 10)
2. Setting the new tabs setting to "Blank tab" and opening a new tab results in a page where gestures no longer work. Opening a tab by going to about:blank directly results in a blank tab where gestures do work.
3. So far all versions of firefox have allowed content scripts on about:blank. It's only in the last beta (v108) that I noticed an issue, which seems to be because the blank tab used for the new tab has changed to resolve bug 1676495. Opening about:blank directly still allows gestures and other content scripts to function.
4. I've noticed the issue on the last Beta v108
5. 108.0b2 (64-bit)

I hope this helps clarify things, but I'm somewhat confused why you cannot get gestures to work in about:blank, even in the latest Beta they still work if you go to about:blank directly, they just won't work in the new blank tab page (which is something like chrome://browser/content/blanktab.html)

For reference I'm using the Gesturefy web extension to test the gestures, but I'm fairly confident it's a matter of allowing content scripts to be injected at all and not something specific to a single extension. I also notice extensions like uBlock Origin won't load in the blank new tab page, but do load in about:blank. Though obviously an adblocker is not much use on a completely blank page.

Comment 4

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (109.0a1/20221117214129) and Beta (108.0b3/20221117185908) under Windows 10 x64 and Ubuntu 16.04 LTS. Tested Release (107.0/20221110173214) as well, but it’s not affected.

As per the provided STR, using Gesturefy, the gestures dont’t work in a New Tab which has been set to "Blank Tab" in the browser settings, but continue to work on about:blank. For more details, see the attached video.

Ran a mozregression as well to confirm the initial finding in Comment 0:

2022-11-18T09:20:42.349000: DEBUG : Found commit message:
Bug 1676492, when new tab page is configured to show a blank page, it should not be added to session history, r=Mardak

Differential Revision: https://phabricator.services.mozilla.com/D156303

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d6b82b3d655959b256be143218b86ee28d9fe06a&tochange=2e7abedae4a01ba3fefaa93462b5211824e5c947

Comment 5

[Alex Cornestean]

Attachment: 2022-11-18_09h05_03.mp4

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1676492

:enndeakin, since you are the author of the regressor, bug 1676492, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 7

[:Gijs (he/him; back Aug 12)]

I don't really understand why add-ons aren't able to run content scripts here - the page is loaded using about:newtab and that's reflected in location.href and the origin part of the content principal. Can add-ons also not run content scripts on the default new tab page?

Comment 8

[Rob Wu [:robwu]]

Extensions can run in about:blank if it has access to its principal (usually http/https) or when it's the null principal of a top-level document.

Extensions cannot run scripts in about:newtab nor chrome-URLs. The only way to override the homepage is through the chrome_urls_overrides API. But blank pages without content, I would expect extensions to be able to run scripts there.

Comment 9

[:Gijs (he/him; back Aug 12)]

(In reply to Rob Wu [:robwu] from comment #8)

Extensions can run in about:blank if it has access to its principal (usually http/https) or when it's the null principal of a top-level document.

Extensions cannot run scripts in about:newtab nor chrome-URLs.

Given that changing the URL of the blank new tab was the crucial component of fixing bug 1676492 in the first place, we're not going to be able to change it back to about:blank. What can be done to fix this? That is, what is needed to allow webextensions to run against these documents?

Comment 10

[Rob Wu [:robwu]]

Judging by the (existing) code in AboutNewTabChild.sys.mjs and the fact that there is a special check to exclude the "new" use of about:newtab in https://hg.mozilla.org/mozilla-central/rev/0e738eb84828, I would say that the new "about:newtab" page is too privileged to permit content script execution, as that could allow extensions to dispatch custom events to trigger privileged functionality. Specifically, an extension could prepare the page before DOMContentLoaded such that the checks are skipped at https://searchfox.org/mozilla-central/rev/aa329cf7506ddd966542e642ec00223fd7461599/browser/actors/AboutNewTabChild.sys.mjs#27-29.

Upon taking a closer look, I concluded that it's not even necessary to bypass these checks. And this example (run from the console at the "new" "blank" about:newtab) page confirms that there is privileged functionality associated with the about:newtab URL (registered here):

window.addEventListener("ContentSearchService", console.info);
window.dispatchEvent(new CustomEvent('ContentSearchClient', {detail: {type:"GetEngine", data:null}}))
// Result: `console.info` was invoked with the response to the "GetEngine" request.

My recommendation here is: if you want to allow extensions to run scripts there, use something else than about:newtab. Whether it's something completely new such as about:newblanktab or about:blank?newtab, or simply about:blank with a different way to recognize the blank tab, to fix bug 1676492 (I haven't looked at that bug in detail).

Comment 11

[shiandow]

I see the status has changed to 'wontfix'. I presume this means that a deliberate decision has been made to no longer allow content-scripts on blank new tabs?

If so that is unfortunate. I'm rather disappointed that a powerful feature like a new tab page that allows content-scripts is broken in order to allow people to optionally show the bookmark toolbar when they also want their new tab page to be blank.

It is also slightly concerning to me that this functionality seems to have been broken unintentionally (at no point was this tradeoff discussed in the original bugfix), and is now declared broken semi-permanently, without discussion.

Comment 12

[:Gijs (he/him; back Aug 12)]

(In reply to shiandow from comment #11)

I see the status has changed to 'wontfix'. I presume this means that a deliberate decision has been made to no longer allow content-scripts on blank new tabs?

If so I'm not aware of it. Jim, can you help clarify why you set 109 to wontfix as well - maybe it was a misclick and you just meant to set this to wontfix for 108 given that's on beta?

Comment 13

[Jim Mathies [:jimm]]

(In reply to :Gijs (he/him) from comment #12)

(In reply to shiandow from comment #11)

I see the status has changed to 'wontfix'. I presume this means that a deliberate decision has been made to no longer allow content-scripts on blank new tabs?

If so I'm not aware of it. Jim, can you help clarify why you set 109 to wontfix as well - maybe it was a misclick and you just meant to set this to wontfix for 108 given that's on beta?

My interpretation of Rob's comment is that this is wontfix, and I assume the webextensions team get this triaged appropriately eventually.

Comment 14

[Rob Wu [:robwu]]

My interpretation of Rob's comment is that this is wontfix, and I assume the webextensions team get this triaged appropriately eventually.

I didn't wontfix the bug. I stated that the suggested approach from comment 7 ("Can add-ons also not run content scripts on the default new tab page?") requires careful consideration on the implementation to avoid introducing a security issue (elaborated in comment 10). I also suggested a way to fix this regression:

My recommendation here is: if you want to allow extensions to run scripts there, use something else than about:newtab. Whether it's something completely new such as about:newblanktab or about:blank?newtab, or simply about:blank with a different way to recognize the blank tab, to fix bug 1676492 (I haven't looked at that bug in detail).

Comment 15

[Shane Caraveo (:mixedpuppy)]

@enndeakin or @gijs

Is there any reason not to add about:blanktab to handle this situation? We have a behavior regression and we cannot allow extensions to inject into about:newtab.

Comment 16

[:Gijs (he/him; back Aug 12)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #15)

@enndeakin or @gijs

Is there any reason not to add about:blanktab to handle this situation? We have a behavior regression and we cannot allow extensions to inject into about:newtab.

A dedicated about: page was the original suggestion in bug 1676492 ; I don't recall why Neil chose to stick with adding a different mode to about:newtab instead, so I'll leave him to clarify that.

I'll add that if we do use a separate URL it may be wise to avoid a URL like about:blanktab (or, sadly, my preference of about:blanketyblank) because they prefix-match with about:blank. Of course in theory all about: page matching should be on full URLs minus query/ref bits, in practice because about URLs IIRC are not nsStandardURLs and don't QI to nsIURL, query parsing has to be done separately, and sometimes people are lazy (url.startsWith(...)) and so there may be lurking bugs in that area.

Comment 18

[alex]

Using about:blank as a workaround does not work.

• Install https://addons.mozilla.org/de/firefox/addon/new-tab-override/
• Set the custom URL to about:blank

The URL-Bar is empty and shows a badge with the extension name instead of a URL and mouse gestures do not work.

Using New Tab Override with a URL works and extensions work on that URL.

Comment 19

[alex]

Tabs loaded with New Tab Overide and about:blank also neither have a Favicon nor a title in the Tab-Bar. This looks quite weird and makes it harder to use.

Comment 21

[Rob Wu [:robwu]]

Until this bug is resolved, the work-around for users is:

1. Visit about:preferences#home
2. Instead of "Blank Page", choose "Custom URLs" and input "about:blank" .

Comment 22

[shiandow]

(In reply to Rob Wu [:robwu] from comment #21)

Until this bug is resolved, the work-around for users is:

1. Visit about:preferences#home
2. Instead of "Blank Page", choose "Custom URLs" and input "about:blank" .

Does this also mean there are plans to implement a feature allowing Custom URLs for the new tab page? As of firefox 110.0b9 it's not yet possible to pick a custom URL for the new tab page.

Comment 23

[Nick]

(In reply to Rob Wu [:robwu] from comment #21)

Until this bug is resolved, the work-around for users is:

1. Visit about:preferences#home
2. Instead of "Blank Page", choose "Custom URLs" and input "about:blank" .

In Firefox 110.0.1, when you follow the proposed steps above, FF reverts the changes to "Blank page", so this workaround is not possible (not anymore at least).

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 25

[Serge van den Boom]

A data URI can be used as a new work-around, instead of about:blank.
Something like this:

data:text/html,<html><head><title>Blank page</title></head></html>

Or the minimal version:

data:,

Unfortunately, this setting (browser.startup.homepage) only applies to new windows.
For new tabs, there was once browser.newtabpage.url, but that does not seem to exist anymore.