1984724 - Addons cannot be updated using about:addons

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect, P1)

Description

[zhawk83]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:142.0) Gecko/20100101 Firefox/142.0

Steps to reproduce:

Since Firefox 142 addons cannot be updated via about:addons.

Using https://addons.mozilla.org and searching for the addon and installing (actually updating) it manually, works.

Actual results:

1. I click on check for updates
2. addons are listed
3. I click update
4. Addon is gone from list (but did not update)

Now I can repeat those steps infinitely.

As a test I reverted to Firefox 141 and the addons could be updated just normally without any issue.

Expected results:

Addons are updated.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Searinox Navras]

Same issue after updating to 142. Here's some additional info if it helps:

Windows 10 x64 22H2, firefox profile folder encrypted with Windows EFS. All addons set to manually update.

How it goes:

1. Go to Addons -> Extensions
2. Check for updates
3. Observe Available Updates list get a badge counter(in my case 6 extensions to be updated)
4. Go to "Available Updates", view the list of extensions with updates, and pick one of them.
5. From the "..." menu select "Update".

Within a second or less the badge count goes down by one. Extensions that require being restarted like "uBlock Origin" normally show a prompt to either restart Firefox or the addon itself by clicking a button. This does not happen.

We can go into the extension Details and check "Version" and "Last Updated" and note that the updated addons have not changed version at all.

Finally we can click "Check for updates" and observe that the same list of updatable addons from a moment ago is shown. None of the "updated" addons are omitted. No matter how many times this is repeated, the extensions never update. Console(ctrl+shift+K) shows no errors. The process console(ctrl+shift+J) does not populate any errors during these steps either.

Comment 3

[Alex Cornestean]

Hello,

I could not reproduce the issue on the latest Release (142.0/20250811145442) or Nightly (144.0a1/20250824214058) under Windows 11 x64.

With add-ons set to update manually, I performed the steps from Comment 2 with 3 add-ons (FoxClocks, Return YouTube Dislike and uBlock Origin) and the add-ons updated without issues. Note that I installed the add-ons before updating to the latest version of the browser and I performed the manual add-on updates after the browser was updated to the latest version (Release from 141 to 142 and Nightly from 143 to 144).

I’ve also tried the same steps with the Firefox profile folder encrypted with Windows EFS and even so, the add-on update was successful.

Comment 4

[Searinox Navras]

Hello, would a paste of prefs.js help?

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

In addition to the prefs.js, would you mind to report back the details got from about:support and to look into BrowserConsole (see https://firefox-source-docs.mozilla.org/devtools-user/browser_console/index.html) for errors hit while reproducing the issue (either the STR described in comment 0 or the one from comment 2).

It may also be useful if you could record a screencast while reproducing the issue in case we may spot some other details that could help the investigation through that.

Comment 6

[Searinox Navras]

I have managed to resolve the issue. By going to prefs.json and deleting the line:

user_pref("extensions.databaseSchema", 37);

I was able to then start the browser and successfully complete all the add-on updates. The line has returned in the file immediately so I have to assume this triggered some manner of addon database re-update/refresh/re-generation. This was tested because I have 4 similarly-configured Firefox profiles and this issue occurred on all of them, and was likewise fixed everywhere in the same fashion.

Comment 7

[zhawk83]

I can confirm that the deletion of the row:
user_pref("extensions.databaseSchema", 37);
did resolve the issue. Nevertheless this is just a dirty workaround and not a solution in my opinion.

Comment 8

[fluks]

I encountered exactly the same bug. I updated from 141 (don't know the exact version) to 142 and I tried to update my own add-on that I updated at AMO to new version and about:add-ons shows it has a new version, but when I press update, it does nothing.

Removing the add-on and installing it again results to the version that is in AMO.

Firefox from snap
Kubuntu 25.04
Build ID 20250821175018
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:142.0) Gecko/20100101 Firefox/142.0

Comment 9

[Rob Wu [:robwu]]

I encountered this issue today (on Nightly 144.0a1 from yesterday), and could reproduce it again with a profile restored from backup immediately after. However, after repeated attempts I cannot reproduce it again.

There have been other reports (e.g. #Add-ons on Matrix) of the inability to update.

Given that this is critical functionality and reportedly a recent regression, I'll take this bug for further investigation.

Comment 10

[Rob Wu [:robwu]]

If someone has reliable reproduction steps, please visit about:config and set extensions.logging.enabled to true, reproduce the issue and share the output of the Browser Console.

--

Additional information from recollection when the bug was reproduced, in case it is relevant:

• Add-on auto-updates were disabled globally.
• The list of available updates was visible because of a background update check (happens ~30 seconds after startup if starting from an old profile)
• I clicked on the triple-dot menu and chose "Update".
• Upon clicking "Update", the "Check for updates" button in the "Allow automatic updates" row became immediately visible.
• Clicking on "Check for updates" immediately hid that row, without actually updating the extension, and a blue dot appeared on the extension's triple-dot button (signaling that an update is available).
• When I tried to update, the locations of the remote data are:
  • Update manifest: https://ftp.mozilla.org/pub/labs/devtools/adb-extension/mac64/update.json
  • Add-on package: https://ftp.mozilla.org/pub/labs/devtools/adb-extension/mac64/adb-extension-0.0.8.2-mac64.xpi
• The failure to update continued consistently, until I tried to step through with a debugger, which caused the update to install successfully.

Because the update manifest and xpi file are hosted at the same server, and the "Check for updates" option immediately added the "Update" button, I am inclined to rule out network connectivity issues.

I also looked at the changelog ( git log -p toolkit/mozapps/extensions/ ) of changes after Firefox 141, and did not see anything that would meaningfully change the update behavior.

Comment 11

[Rob Wu [:robwu]]

I found a bit of suspicious code here: https://searchfox.org/firefox-main/rev/995b0c65366602cbb70a65131f9a848c82a8d19d/toolkit/mozapps/extensions/content/aboutaddons.js#2635,2638,2644,2652

It attaches a prompt handler to this.updateInstall and intends to clear that upon completion. But this.updateInstall is immediately nulled before that code runs, so it is never cleared. I don't expect this to change the behavior for this bug, because other interested callers override the prompt handler before getting there.

Comment 13

[Ed]

Same problem, but only with Stylus, Copy Link Text, Word Counter, and Textarea Cache.

Plus one other I forgot to record when it happend.

To reproduce the problem, I installed Textarea Cache v5.04, proceeded to try to update it, and when it didn't updated I found this in the console:

Event received:
Object { type: "onInstalling", id: "[e-mail]", needsRestart: undefined }
amo-590a3d83341a81855452.js:2:601859

And indeed, it updated t v5.06 with the restart.

Comment 14

[Chris [:cmd]]

I'm a user having this issue, v142.0.1 on Windows 10 22H2 19045.6216

The issue seems to affect updating all of my extensions. For simplicity and brevity of console logs, I've reproduced it with just a single one: "Firefox Multi-Account Containers". I currently have v8.2.0 installed, and v8.3.0 is available.

I have automatic updates disabled. This is from the individual extension page.

Clicking "Check for Updates" produces the following output, puts the small badge on the triple dot menu, and enables the "Update" menu item in the menu produced there.

1756992916089	addons.update-checker	DEBUG	Requesting https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=@testpilot-containers&version=8.2.0&maxAppVersion=*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=142.0.1&appOS=WINNT&appABI=x86_64-msvc&locale=en-US&currentAppVersion=142.0.1&updateType=97&compatMode=normal
1756992916128	addons.update-checker	DEBUG	Found an update entry for @testpilot-containers version 8.3.0

Clicking the "Update" button in that menu produces the following output:

1756992985504	addons.xpi	DEBUG	Download started for https://addons.mozilla.org/firefox/downloads/file/4494279/multi_account_containers-8.3.0.xpi to file C:\Users\cmd\AppData\Local\Temp\tmp-9cf.xpi
1756992985518	addons.xpi	DEBUG	Download of https://addons.mozilla.org/firefox/downloads/file/4494279/multi_account_containers-8.3.0.xpi completed.
1756992985611	addons.xpi	INFO	Install of @testpilot-containers cancelled by user
1756992985611	addons.xpi	DEBUG	removeTemporaryFile: https://addons.mozilla.org/firefox/downloads/file/4494279/multi_account_containers-8.3.0.xpi removing temp file C:\Users\cmd\AppData\Local\Temp\tmp-9cf.xpi

I most certainly did not cancel the install, as the message implies :)

The response headers, which seem fine, for multi_account_containers-830.xpi are as follows:

HTTP/2 200 
referrer-policy: same-origin
last-modified: Mon, 19 May 2025 12:24:17 GMT
x-content-type-options: nosniff
access-control-allow-origin: *
x-frame-options: DENY
strict-transport-security: max-age=31536000
cache-control: max-age=86400
content-security-policy: connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com https://*.googletagmanager.com; form-action 'self'; default-src 'none'; font-src 'self' https://addons.mozilla.org/static-server/; child-src https://www.recaptcha.net/recaptcha/; frame-src https://www.recaptcha.net/recaptcha/; style-src 'unsafe-inline' https://addons.mozilla.org/static-server/; script-src https://*.google-analytics.com https://*.googletagmanager.com https://www.recaptcha.net/recaptcha/ https://www.gstatic.com/recaptcha/ https://www.gstatic.cn/recaptcha/ https://addons.mozilla.org/static-server/; object-src 'none'; img-src 'self' blob: data: https://addons.mozilla.org/static-server/ https://addons.mozilla.org/user-media/ https://*.google-analytics.com https://*.googletagmanager.com; media-src https://videos.cdn.mozilla.net; report-uri /__cspreport__
server: openresty
content-type: application/x-xpinstall
via: 1.1 google, 1.1 varnish, 1.1 varnish, 1.1 varnish
accept-ranges: bytes
age: 75347
date: Wed, 03 Sep 2025 17:35:03 GMT
x-served-by: cache-bfi-kbfi7400073-BFI, cache-bfi-kbfi7400073-BFI, cache-mia-kmia1760068-MIA
x-cache: MISS, HIT, HIT
x-cache-hits: 0, 2, 0
x-timer: S1756920903.257603,VS0,VE1
vary: X-Country-Code
content-length: 923029

I can provide the response body as well if needed, but it does appear to be the correct file.

Other Notes

I have tried updating while launching in safe mode, and the behavior is the same, so it doesn't appear to be a conflict with any of my other extensions.

As well: manually removing and re-installing an extension does circumvent this issue, so the install failure seems to only occur when following the "Update" flow.

Comment 15

[Rob Wu [:robwu]]

Attachment: Bug 1984724 - Add extra logging of unexpected add-on install cancellation

Comment 16

[Rob Wu [:robwu]]

Thanks for the log Chris. The interesting part of the log is that it goes through https://searchfox.org/firefox-main/rev/c0a89603e6e572b20e66350d69cb0addb6c08389/toolkit/mozapps/extensions/internal/XPIInstall.sys.mjs#1808 , which suggests that there may be an unexpected error in the promptHandler.

I've attached a patch to actually log that error, but it will take a while before that reaches release. In the meantime:

If you are able to consistently reproduce the issue, could you follow the following steps:

1. Open the Browser Toolbox.
2. In the Debugger, press Ctrl+P (Cmd+P on macOS) and search for XPIInstall.sys.mjs (search for the line I highlighted above, cancelled by user).
3. Right-click on the line number, choose "Add log" and use "promptHandler failed:", err?.message, err?.stack, err
4. Follow your own steps to reproduce the issue.
5. Go to the Console tab of the Browser Toolbox, and copy the output, share it here in this bug.

Comment 17

[Rob Wu [:robwu]]

Comment on attachment 9511716 [details]
Bug 1984724 - Add extra logging of unexpected add-on install cancellation

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Log unexpected error to help with debugging this bug in critical functionality (add-on updating not working).
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Merely adds logging using established methods when an unexpected error is encountered. This does not change behavior.
• String changes made/needed: None
• Is Android affected?: Unknown

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/aea7a1fc1db4
https://hg.mozilla.org/integration/autoland/rev/002a6450f140
Add extra logging of unexpected add-on install cancellation r=zombie

Comment 19

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/002a6450f140

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9511716 [details]
Bug 1984724 - Add extra logging of unexpected add-on install cancellation

Approved for 143.0rc1. I'm clearing the flag, however, so this doesn't show up on the needs-uplift radar while we continue to the investigation.

Comment 21

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/32ee13061328
https://hg.mozilla.org/releases/mozilla-beta/rev/d464d243570a

Comment 22

[Chris [:cmd]]

Hey Rob, here's some fresh logs for you!

1757342504428	addons.update-checker	DEBUG	Requesting https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=@testpilot-containers&version=8.2.0&maxAppVersion=*&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=142.0.1&appOS=WINNT&appABI=x86_64-msvc&locale=en-US&currentAppVersion=142.0.1&updateType=97&compatMode=normal
1757342504470	addons.update-checker	DEBUG	Found an update entry for @testpilot-containers version 8.3.0
1757342506964	addons.xpi	DEBUG	Download started for https://addons.mozilla.org/firefox/downloads/file/4494279/multi_account_containers-8.3.0.xpi to file C:\Users\cmd\AppData\Local\Temp\tmp-fm5.xpi
1757342506975	addons.xpi	DEBUG	Download of https://addons.mozilla.org/firefox/downloads/file/4494279/multi_account_containers-8.3.0.xpi completed.
promptHandler failed: can't access property "concat", required.data_collection is undefined get installPermissions@resource://gre/modules/addons/XPIDatabase.sys.mjs:1421:7
get hasDataCollectionPermissions@resource://gre/modules/addons/XPIDatabase.sys.mjs:1453:1
installPromptHandler@chrome://mozapps/content/extensions/aboutaddonsCommon.js:97:5
checkPrompt/<@resource://gre/modules/addons/XPIInstall.sys.mjs:1797:22
checkPrompt@resource://gre/modules/addons/XPIInstall.sys.mjs:1822:7
install@resource://gre/modules/addons/XPIInstall.sys.mjs:1396:14
install@resource://gre/modules/addons/XPIInstall.sys.mjs:2403:22
downloadCompleted@resource://gre/modules/addons/XPIInstall.sys.mjs:2801:12
async*onStopRequest/<@resource://gre/modules/addons/XPIInstall.sys.mjs:2684:20
promise callback*onStopRequest@resource://gre/modules/addons/XPIInstall.sys.mjs:2681:38
 TypeError: can't access property "concat", required.data_collection is undefined
    get installPermissions resource://gre/modules/addons/XPIDatabase.sys.mjs:1421
    get hasDataCollectionPermissions resource://gre/modules/addons/XPIDatabase.sys.mjs:1453
    installPromptHandler chrome://mozapps/content/extensions/aboutaddonsCommon.js:97
    checkPrompt resource://gre/modules/addons/XPIInstall.sys.mjs:1797
    checkPrompt resource://gre/modules/addons/XPIInstall.sys.mjs:1822
    install resource://gre/modules/addons/XPIInstall.sys.mjs:1396
    install resource://gre/modules/addons/XPIInstall.sys.mjs:2403
    downloadCompleted resource://gre/modules/addons/XPIInstall.sys.mjs:2801
    onStopRequest resource://gre/modules/addons/XPIInstall.sys.mjs:2684
    promise callback*onStopRequest resource://gre/modules/addons/XPIInstall.sys.mjs:2681
XPIInstall.sys.mjs:1808:13
    checkPrompt resource://gre/modules/addons/XPIInstall.sys.mjs:1786
    checkPrompt resource://gre/modules/addons/XPIInstall.sys.mjs:1785
    install resource://gre/modules/addons/XPIInstall.sys.mjs:1393
    install resource://gre/modules/addons/XPIInstall.sys.mjs:2385
    downloadCompleted resource://gre/modules/addons/XPIInstall.sys.mjs:2750
    anonymous unknown:0
1757342507070	addons.xpi	INFO	Install of @testpilot-containers cancelled by user
1757342507070	addons.xpi	DEBUG	removeTemporaryFile: https://addons.mozilla.org/firefox/downloads/file/4494279/multi_account_containers-8.3.0.xpi removing temp file C:\Users\cmd\AppData\Local\Temp\tmp-fm5.xpi 

Seeing that it was complaining about required.data_collection being undefined, I added a log on XPIDatabase.sys.mjs:1418 to output required declared on line 1411. It's output:

{
  "permissions": [
    "activeTab",
    "contextMenus",
    "contextualIdentities",
    "cookies",
    "history",
    "idle",
    "management",
    "storage",
    "tabs",
    "unlimitedStorage",
    "webRequest",
    "webRequestBlocking"
  ],
  "origins": [
    "<all_urls>"
  ]
}

Sure enough, no data_collection property, so it makes sense the .concat call on line 1421 blows up.

The extension I'm using to test/repro this doesn't seem to include any "data_collection_permissions" key that seems to be supported in the manifest. Nor does it indicate "none" as required to explicitly say it doesn't, either.

I'm not familiar enough with the inner workings there, but it would seem reasonable that an extension not setting those keys would be a potential cause for that data_collection property to not get assigned anywhere, but it seems XPIDatabase.sys.mjs likely expects it to be at the very least an empty array like the other properties, rather than undefined.

Let me know what I should try next!

Comment 23

[Rob Wu [:robwu]]

Thanks for the logs. I identified multiple potential culprits before, and your logs helps with narrowing it down to this change:

• introduction of info.existingAddon.hasDataCollectionPermissions at https://searchfox.org/firefox-main/diff/c5df4ab813207e3326cf423c3462334b8cd8b02c/toolkit/mozapps/extensions/content/aboutaddonsCommon.js#97 in bug 1978614.
• error thrown from https://searchfox.org/firefox-main/rev/1f462a0092bc995d91d3f5f790c197b1bf739954/toolkit/mozapps/extensions/internal/XPIDatabase.sys.mjs#1421

The last line was added in bug 1955942, which added logic for install prompts. There the addon is freshly parsed. In this bug, the add-on metadata is not re-parsed, but apparently read directly from the data on disk (extensions.json file) without migration. The next step here is to figure out how we got into this state, and how we should fix this.

Note: the fact that access to hasDataCollectionPermissions throws due to (effectively) info.existingAddon.userPermissions.data_collection being undefined also implies that this kind of issue also happened before the regression of bug 1955942:
Two lines after the new code, the implementation calls Extension.comparePermissions(oldPerms, newPerms); (with oldPerms = info.existingAddon.userPermissions). The comparePermissions function has the following logic (permalink to source code):

      data_collection: newPermissions.data_collection.filter(
        perm =>
          !oldPermissions.data_collection.includes(perm) && perm !== "none"

This means that if an extension adds a non-empty data_collection field, that it would also trigger this bug and prevent add-on updates from propagating. That logic was added in bug 1971414, landed in Firefox 141.

We should fix this regression and also audit the rest of the codebase to verify that there are no other similar issues here.

Comment 24

[Rob Wu [:robwu]]

I can reproduce locally with my own profile directory from backup. I had to use cp -a instead of cp -r to make sure that all file attributes (timestamps in particular) were correctly restored.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1978614

Comment 26

[Rob Wu [:robwu]]

Attachment: Bug 1984724 - Account for missing data_collection field

extensions.json can miss the data_collection field when it was generated
by a Firefox version that did not support it. The implementation did not
account for this, and prevented extensions from updating due to a
runtime error.

This patch fixes the issue by adding a null check, and unit tests for
background updates. The unit test does not exercise the code path of the
"manual update" scenario from the bug, because of complexity and the
fact that its implementation is going to be replaced with the same logic
of the background update check (bug 1974732)..

Comment 27

[Chris [:cmd]]

I'd like to confirm that your patch does alleviate the issue for me; as long as I define data_collection to be [] in the debugger, I'm able to update each extension that faced this problem!

I really appreciate your help and effort in fixing this issue, Rob!

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/45385c4f9706
https://hg.mozilla.org/integration/autoland/rev/12d0bf6a782e
Account for missing data_collection field r=willdurand

Comment 29

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Extensions cannot be updated if they were installed a few releases ago.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: STR to test, use the same profile directory across the test.

1. Install an old version of Firefox that does not support data_collection_permissions, e.g. version 135.
2. Visit about:addons, in the gear icon, uncheck "Update add-ons automatically".
3. Install an older version of an add-on, e.g. by clicking on "Download file" at version 4.27 of https://addons.mozilla.org/en-US/firefox/addon/dont-track-me-google1/versions/
4. Install the Firefox version of interest (with or without this patch/fix).
5. In about:addons, in the Gear icon, click on "Check for Updates"
6. A blue dot should appear on the triple-dot menu. Click on it and choose "Update"
7. Without patch: nothing happens; with patch: the extension updates to the latest version.

• Risk associated with taking this patch: low
• Explanation of risk level: The issue is well understood. The patch adds missing null checks, and the faulty logic is covered by automated unit tests.
• String changes made/needed: None
• Is Android affected?: yes

Comment 30

[Rob Wu [:robwu]]

Attachment: Bug 1984724 - Account for missing data_collection field

extensions.json can miss the data_collection field when it was generated
by a Firefox version that did not support it. The implementation did not
account for this, and prevented extensions from updating due to a
runtime error.

This patch fixes the issue by adding a null check, and unit tests for
background updates. The unit test does not exercise the code path of the
"manual update" scenario from the bug, because of complexity and the
fact that its implementation is going to be replaced with the same logic
of the background update check (bug 1974732)..

Original Revision: https://phabricator.services.mozilla.com/D264155

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9512299 [details]
Bug 1984724 - Account for missing data_collection field

143 is in RC now. Moving the request over.

Comment 32

[Rob Wu [:robwu]]

Setting severity to S2 because this bug prevented Firefox users from updating their add-ons, whether automatically or manually. Consequently, users may miss out on critical add-on updates.

A work-around is to visit about:config and clearing extensions.databaseSchema then restarting the browser. This works because it forces a rebuild of the database stored in extensions.json. This work-around is not a satisfactory general solution, because it requires the user to be aware of the inability to update. The preferred fix is the above patch.

Comment 33

[amarc]

https://hg.mozilla.org/mozilla-central/rev/12d0bf6a782e

Comment 34

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (144.0a1/20250909205747) under Windows 11 and Ubuntu 24.04 LTS.

Following the STR from Comment 29, on the Firefox version without the patch/fix, after clicking “Update”, nothing happens i.e. the add-on is not updated. On the other hand, on the Firefox version with the patch/fix, clicking “Update” will properly update the add-on to the latest available version.

Comment 35

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:robwu, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval. Also, don't forget to request an uplift for the patches in the regression caused by this fix.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox143 to wontfix.

For more information, please visit BugBot documentation.

Comment 36

[Rob Wu [:robwu]]

Although ESR140 is not affected by the originally reported issue here (regressed by bug 1978614), it is affected by a similar bug in a more limited scope (regressed by bug 1971414). Specifically, if an extension developer publishes an update with the data_collection_permissions field set, ESR140 users who installed the extension in ESR128 or earlier (before bug 1954524) will be unable to update to it due to a missing data_collection field in the database. I described this in more detail at the second half of https://bugzilla.mozilla.org/show_bug.cgi?id=1984724#c23.

Although not as bad as the inability to update all add-ons, it is still impeding the ability to update some add-ons.
Therefore I will request an uplift to ESR140 of the two patches that landed in this bug, plus the test fixup for Thunderbird that landed in bug 1987828. The combined patch has not changed in other ways.

Comment 37

[Rob Wu [:robwu]]

Attachment: Bug 1984724 - Account for missing data_collection field (ESR140 port)

extensions.json can miss the data_collection field when it was generated
by a Firefox version that did not support it. The implementation did not
account for this, and prevented extensions from updating due to a
runtime error.

This patch fixes the issue by adding a null check, and unit tests for
background updates. The unit test does not exercise the code path of the
"manual update" scenario from the bug, because of complexity and the
fact that its implementation is going to be replaced with the same logic
of the background update check (bug 1974732).

This patch also includes smaller fixups related to this bug and patch:

• https://phabricator.services.mozilla.com/D263925
• https://phabricator.services.mozilla.com/D264372

Original Revision: https://phabricator.services.mozilla.com/D264155

Comment 38

[Rob Wu [:robwu]]

On a second thought, ESR140 is NOT affected for ESR128 -> ESR140 update scenarios, because the ESR128 had schema version 36 (source),
and ESR140 has bumped the version to 37 (source, done by bug 1917848). This was an effective work-around to the problem.

If someone were to reuse a profile (or at least the extension database) that installed an extension from version 134 through 138 (between landing of bug 1917848, before landing of bug 1954524), then they are still affected though. This scenario is expected to be relatively rare, especially in comparison to the originally reported issue that was more widespread

Comment 39

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Cannot update some add-ons in some rare cases. For details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1984724#c36 and https://bugzilla.mozilla.org/show_bug.cgi?id=1984724#c38
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: Not needed; covered by unit tests. If desired, use the STR from https://bugzilla.mozilla.org/show_bug.cgi?id=1984724#c29, except with Firefox ESR140 instead of Nightly/release. The profile directory still needs to be created with version 135 (a lucky coincidence hid the bug from ESR128->ESR140 upgrade paths, see https://bugzilla.mozilla.org/show_bug.cgi?id=1984724#c38 )
• Risk associated with taking this patch: low
• Explanation of risk level: The issue is well understood. The patch adds missing null checks, and the faulty logic is covered by automated unit tests.
• String changes made/needed: None; "Is Android affected?" is "No" because we do not publish ESR versions of Firefox for Android.
• Is Android affected?: no

Comment 40

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/56c490bcad50

Comment 41

[Alex Cornestean]

Verified as Fixed. Tested on the latest ESR (140.4.0esr/20250919170250 from https://treeherder.mozilla.org/jobs?repo=mozilla-esr140&revision=56c490bcad501e85ef080897eec11d9d246d228e) under Windows 11 and Ubuntu 24.04 LTS.

Following the STR from Comment 29, clicking “Update” will properly update the add-on to the latest available version.

Comment 42

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/184cba7bcc46
https://hg.mozilla.org/releases/mozilla-release/rev/8f2bafc999cd

Comment 43

[Rob Wu [:robwu]]

For clarity, here is a summary of impacted Firefox versions. The patch landed in Firefox 144 and got backported to earlier releases where possible.

Regression from bug 1978614 (introduced in Firefox 142) - most extensions cannot update (see comment 23 for technical details).

• Firefox 141 unaffected
• Firefox 142 wontfix
• Firefox 143 until 143.0.2 - affected (wontfix)
• Firefox 143.0.3 fixed

Regression from bug 1971414 (introduced in Firefox 140) - extensions specifying data_collection in their update are unable to update.

• Firefox 140 wontfix
• Firefox 141 wontfix
• Firefox 142 wontfix
• Firefox 143 until 143.0.2 - affected (wontfix)
• Firefox 143.0.3 fixed
• Firefox ESR 140 up until 140.3.0 - affected (wontfix)
• Firefox ESR 140.3.1 fixed

(QA tested the fix in ESR 140.4.0 in comment 41, but an unplanned ESR dot release happened that includes the fix)

Comment 45

[Alex Cornestean]

Verified as Fixed. Tested on the latest Release (143.0.3/20250925195835 from https://treeherder.mozilla.org/jobs?repo=mozilla-release&revision=532de6796f942901e3943d4d241b84bcaf670ae7 as the builds there contain the fixes for this bug as well, as per the pushlog accessed via about:buildconfig) under Windows 11 and Ubuntu 24.04 LTS.

Following the STR from Comment 29, clicking “Update” will properly update the add-on to the latest available version.

Comment 46

[Ryan VanderMeulen [:RyanVM]]

Added to the 143.0.3 relnotes.