Closed Bug 2061439 Opened 3 months ago Closed 1 month ago

Allow ExtensionSettings update_url to be used as an install source

Categories

(Firefox :: Enterprise Policies, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
158 Branch
Tracking Status
firefox158 --- fixed

People

(Reporter: mkaply, Assigned: mkaply)

References

(Blocks 2 open bugs)

Details

Attachments

(1 external file)

ExtensionSettings accepts both install_url and update_url, but update_url is only ever read in one place -- UpdateChecker in XPIInstall.sys.mjs -- which overrides the update URL for an add-on that is already installed. It is not an install source.

So for a force_installed or normal_installed entry:

  • with install_url: the XPI is installed from that URL.
  • with no install_url: installAddonFromRepository() looks the add-on up on addons.mozilla.org by ID.
  • with only update_url: the AMO lookup runs anyway and fails for a self-hosted add-on, even though the policy names a manifest that says exactly where to get it.

That last case is the gap. An admin who self-hosts and supplies an update manifest gets "No XPI URL found on AMO", and has to duplicate the XPI location into install_url.

Proposal: when a force_installed/normal_installed entry has no install_url and the add-on is not installed, fetch the manifest from update_url via AddonUpdateChecker, pick the newest compatible version with getNewestCompatibleUpdate(), and install that XPI. Already-installed add-ons are unaffected -- they keep getting update_url through the normal update check, so this adds no startup network traffic.

This also matters for bug 1672923, which adds Chrome's ExtensionInstallForcelist. Chrome's entry format is <id>;<update_url> where the URL is the install source, so parity needs this.

force_installed/normal_installed entries with only update_url fell through to the
AMO lookup, which fails for a self-hosted add-on. Resolve the XPI from the update
manifest instead. AddonRepository isn't usable here: it only resolves add-ons
listed on AMO, and AddonUpdateChecker owns the only parser for the update
manifest format.

update_url hydrates to a URL, but PolicySchemaValidator passes the string through
when new URL() rejects a value the validator accepted as format: uri (e.g.
"http://"), so href is checked before use rather than falling back to AMO for an
add-on that almost certainly isn't there.

The manifest URL is used verbatim: the "%...%" parameters escapeAddonURI expands
for update checks describe an installed add-on, and there isn't one yet.

Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Blocks: 2068266
Blocks: 2072666
See Also: → 2068266
Pushed by mozilla@kaply.com: https://github.com/mozilla-firefox/firefox/commit/278d47d09212 https://hg.mozilla.org/integration/autoland/rev/326845f877fa Install ExtensionSettings add-ons from update_url when install_url is absent r=joporter,extension-reviewers,rpl
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 158 Branch
QA Whiteboard: [qa-triage-done-c159/b158]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: