Allow ExtensionSettings update_url to be used as an install source
Categories
(Firefox :: Enterprise Policies, enhancement)
Tracking
()
| 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.
| Assignee | ||
Comment 1•2 months ago
|
||
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.
Updated•2 months ago
|
Updated•1 month ago
|
Description
•