1976115 - experiment_apis scripts are run from jar:file: URL instead of moz-extension:-URL

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Rob Wu [:robwu]]

When an extension specifies an experiment_apis entry in their manifest.json and canUseAPIExperiment() is true, then parseManifest will resolve the relative URL to a jar:file://-URL within the extension.

• rootURI.resolve called here: https://searchfox.org/mozilla-central/rev/584b344830aa2558985675b99aaadbb915402caa/toolkit/components/extensions/Extension.sys.mjs#2143
• used here (and persisted in startupCache/webext.sc.lz4): https://searchfox.org/mozilla-central/rev/584b344830aa2558985675b99aaadbb915402caa/toolkit/components/extensions/Extension.sys.mjs#2181-2186,2199,2203

For example, webcompat/manifest.json declares aboutConfigPrefs.js in experiment_apis, which resolves to: jar:file:///Applications/Firefox%20Nightly.app/Contents/Resources/browser/omni.ja!/chrome/browser/builtin-addons/webcompat/experiment-apis/aboutConfigPrefs.js . This URL can be seen in several places:

• Attach the Browser Toolbox, and in the Debugger tab, look at the sidebar for the source.
• Any stack trace where the script executes from shows this URL.
• Run the following from the global browser console: ChromeUtils.importESModule('resource://gre/modules/ExtensionParent.sys.mjs').StartupCache._data.get('manifests').get('[e-mail]').values().next().value.get('en-US').modules.parent.deserialize({}, true).modules.get('aboutConfigPrefs').url

This use of the jar:file:-URL is inconsistent with the other logic in the extension framework, which usually uses moz-extension:-URLs. We should use the moz-extension:-URL too. This will have the following impact:

• startupcache more portable: Using moz-extension: (or even just relative URLs) instead of the jar:file:-URL makes the startupcache more portable. The computed URL is stored, and the use of the resolved URL prevents privileged extensions from functioning if the profile directory or application directory is relocated (bug 1975255).
• Consistent validation logic: Any policies related to execution of extension code can be associated with the moz-extension:-URL instead of jar:file:. For example, bug 1959437 has a patch introduces additional validation for moz-extension:-URLs, but these checks are not applied to jar:file:-URLs.
• Devtools: WebExtensions experiment scripts appear as moz-extension:-URLs in the devtools, debugger and stack traces (instead of jar:file:).
• Sanity check: no performance regression: Using moz-extension: instead of jar:file delays file content resolution in ExtensionProtocolHandler until readyPromise is resolved. In practice, this is not expected to cause regressions in load time, since the earliest point of execution of experiment_apis is at the onStartup method of the ExtensionAPI subclass, which is called only after readyPromise is resolved.

Comment 1

[Rob Wu [:robwu]]

When a patch is created for this, make sure to involve me and rpl in review or patch creation.

rpl wants to double-check that the changes don't cause regressions in the newtab-as-builtin extension component.

Comment 2

[Rob Wu [:robwu]]

Another consequence of this bug is that experiment_apis with scope addon_child and content_child cannot execute when loaded temporarily from disk, when the process sandbox blocks file access. When loaded temporarily from disk (unpacked), rootURI is file:, not jar:file:.

A colleague reported that they'd encounter the following error:

Uncaught Error opening input stream (invalid filename?): file:///Users/username/extension-dir/api.js

... and the issue is fixed when this.rootURI.resolve( is replaced with this.getURL( at https://searchfox.org/mozilla-central/rev/584b344830aa2558985675b99aaadbb915402caa/toolkit/components/extensions/Extension.sys.mjs#2143
(this is not a full fix - it only works when an extension has an ID in the manifest file)