Decision taken: if AMO has not approved 1.10.0 by the time 1.13 ships, we stop releasing to AMO and distribute Firefox builds ourselves.
This issue records the mechanics, because "zip only" as stated does not work and the alternative needs a manifest change.
Where AMO actually stands
Per AMO's public API, the newest public version is 1.8.0, reviewed 2026-08-12. 1.9.1 and 1.10.0 have been in the queue since roughly 2026-08-20 and 2026-08-26 with no reviewer messages, and direct questions have gone unanswered.
The five releases before that cleared in one to three days each:
| Version |
Reviewed |
| 1.5.0 |
2026-07-24 |
| 1.5.1 |
2026-07-25 |
| 1.6.0 |
2026-07-28 |
| 1.7.0 |
2026-07-31 |
| 1.8.0 |
2026-08-12 |
Nothing in the submission explains the change. Permissions are byte-identical to 1.8.0, data_collection_permissions predates it, no new minified or bundled dependency was added (jsqr.js shipped in 1.1.0 and is not minified), and the one long line in pdf-backup.js is SVG path data already documented at REVIEWERS.md:135.
Worth noting separately: release-1.11.0-guide.md says "HOLD until 1.10.0 is approved", reversing the correct reasoning in release-1.10.0-guide.md — that a pending version should be stacked on, not waited for, since AMO serves the highest approved version. That reversal is why 1.11.0 and 1.12.0 were never filed at all.
A zip is not installable on Firefox
Since Firefox 48, release and beta builds refuse unsigned extensions and there is no user-facing override. xpinstall.signatures.required only takes effect on Developer Edition, Nightly and ESR. A plain zip or unsigned .xpi from sidecar.top would be rejected by the browser most users run.
What does work: AMO's unlisted channel
Upload to AMO as unlisted and signing is automated with no human review. You get a signed .xpi back and host it wherever you like. Same account, same add-on ID, no listing and no queue.
Work required
The open question: existing AMO users
They installed from the listed channel and will stay on it. Self-hosted updates will not reach them.
So if we stop releasing to AMO and leave 1.8.0 listed, every current Firefox user is parked permanently on the build with the socket leak, the relay-resolution bugs and the approval-queue deadlock — the release that made the extension feel broken.
Delisting is arguably kinder to them than abandoning them there, but it also removes the discovery path for new users and cannot be undone quickly. This needs deciding before 1.13 ships, not after.
Decision taken: if AMO has not approved 1.10.0 by the time 1.13 ships, we stop releasing to AMO and distribute Firefox builds ourselves.
This issue records the mechanics, because "zip only" as stated does not work and the alternative needs a manifest change.
Where AMO actually stands
Per AMO's public API, the newest public version is 1.8.0, reviewed 2026-08-12. 1.9.1 and 1.10.0 have been in the queue since roughly 2026-08-20 and 2026-08-26 with no reviewer messages, and direct questions have gone unanswered.
The five releases before that cleared in one to three days each:
Nothing in the submission explains the change. Permissions are byte-identical to 1.8.0,
data_collection_permissionspredates it, no new minified or bundled dependency was added (jsqr.jsshipped in 1.1.0 and is not minified), and the one long line inpdf-backup.jsis SVG path data already documented atREVIEWERS.md:135.Worth noting separately:
release-1.11.0-guide.mdsays "HOLD until 1.10.0 is approved", reversing the correct reasoning inrelease-1.10.0-guide.md— that a pending version should be stacked on, not waited for, since AMO serves the highest approved version. That reversal is why 1.11.0 and 1.12.0 were never filed at all.A zip is not installable on Firefox
Since Firefox 48, release and beta builds refuse unsigned extensions and there is no user-facing override.
xpinstall.signatures.requiredonly takes effect on Developer Edition, Nightly and ESR. A plain zip or unsigned.xpifrom sidecar.top would be rejected by the browser most users run.What does work: AMO's unlisted channel
Upload to AMO as unlisted and signing is automated with no human review. You get a signed
.xpiback and host it wherever you like. Same account, same add-on ID, no listing and no queue.Work required
browser_specific_settings.gecko.update_url. It is currently absent. Without it a self-hosted install never updates and users re-download by hand forever. It needs to point at a JSON update manifest on sidecar.top listing versions and.xpiURLs.update_urlas "dev build".FIREFOX_PORT.md:93records that this exact heuristic once gated the debug panel and dev badge, and was changed tomanagement.getSelf().installTypebecause AMO never injects the field. Setting it now inverts that assumption; confirm no other code reads it..xpi, and add install instructions to sidecar.top.The open question: existing AMO users
They installed from the listed channel and will stay on it. Self-hosted updates will not reach them.
So if we stop releasing to AMO and leave 1.8.0 listed, every current Firefox user is parked permanently on the build with the socket leak, the relay-resolution bugs and the approval-queue deadlock — the release that made the extension feel broken.
Delisting is arguably kinder to them than abandoning them there, but it also removes the discovery path for new users and cannot be undone quickly. This needs deciding before 1.13 ships, not after.