1953616 - Find out why newtab needs to register the chrome://newtab URI for accessing activity-stream.css with contentaccessible=yes

Status: NEW

(Firefox :: New Tab Page, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

We seem to need the contentaccessible=yes directive when registering chrome://newtab for the activity-stream.css file. I believe it's been that way for a while (we originally accessed activity-stream.css via resource://activity-stream, and that was also contentaccessible=yes).

robwu asked me to file this bug in order to figure out if we really actually need this in order for the newtab page to access activity-stream.css.

See https://phabricator.services.mozilla.com/D240941#8331270 for context.

Comment 1

[Rob Wu [:robwu]]

Bug 1534581 is an existing bug (without activity for years) about contentaccessible=yes on chrome:-URLs:.

In this specific case, chrome://newtab/content/ is an alias for moz-extension://<random>/data/ (and resource://builtin-addons/newtab/ is also aliases to that moz-extension:-URL).
Both are currently declared content accessible (at browser/extensions/newtab/webext-glue/resource-mapping.js).

The activity-stream.css file is currently available from:

• chrome://newtab/content/css/activity-stream.css
• resource://newtab/data/css/activity-stream.css
• resource://builtin-addons/newtab/data/css/activity-stream.css
• moz-extension://<random>/data/css/activity-stream.css

The first three are all globally accessible to content, but the moz-extension: is not by default.
The availability of the moz-extension:-URL can be controlled through web_accessible_resources, and as of Manifest Version 3, per origin.
The extension is currently declared as a manifest version 2 extension, and it looks like it can transition to a MV3 problem without any issues.

For web_accessible_resources to support about:-URLs, the implementation needs one tweak, to allow any scheme when the extension is privileged:

• pass mIsPrivileged flag at https://searchfox.org/mozilla-central/rev/8f31613f0a0ad276146f8acced7e2eec4fa3605f/toolkit/components/extensions/WebExtensionPolicy.cpp#223
• set mRestrictSchemes to false if not privileged, at https://searchfox.org/mozilla-central/rev/8f31613f0a0ad276146f8acced7e2eec4fa3605f/toolkit/components/extensions/WebExtensionPolicy.cpp#153

... alternatively we could consider allowing any about:newtab, about:home, etc. to load moz-extension:-resources by default.

With either of these, it becomes possible to expose the internal moz-extension:-URL to about:newtab, about:home, etc., without also exposing it to the web.
I see one potential hurdle: the URL to the resource is currently hard-coded (at https://searchfox.org/mozilla-central/rev/8f31613f0a0ad276146f8acced7e2eec4fa3605f/browser/extensions/newtab/data/content/abouthomecache/page.html.template#36 ). The moz-extension:-URL has a random UUID that makes the URL unpredictable. If you can feed the URL externally, you can obtain the correct URL with WebExtensionPolicy.getByID("[e-mail]").getURL("data/css/activity-stream.css")

If that stylesheet cannot be added dynamically for some reason (I don't see why not), then a way to get a predictable moz-extension:-URL is by modifying the UUID generation logic to provide deterministic host names for this built-in, at https://searchfox.org/mozilla-central/rev/8f31613f0a0ad276146f8acced7e2eec4fa3605f/toolkit/components/extensions/Extension.sys.mjs#413-415,434