Open Bug 1986027 Opened 2 months ago Updated 8 days ago

Thunderbird 142 not updating Add-on compatibility on update

Categories

(Thunderbird :: Add-Ons: General, defect)

Product:
Thunderbird
Component:
Add-Ons: General
Version:
Thunderbird 142
Platform:
x86_64
Unspecified
Type:
defect

Tracking

(Not tracked)

People

(Reporter: axel.grude, Unassigned)

Details

Attachments

(2 files, 1 obsolete file)

screenshot from my French user after I told him to the "check for updates" command
45.93 KB, image/png
Details
quickltext-bg-update.png
249.85 KB, image/png
Details

I got a few users of multiple of my Add-ons (quickFilters, QuickFolders, SmartTemplates) wondering when I would update my Add-ons to be compatible with Thunderbird 142. These all have strict_max_version 141.* but where updated on the ATN website as "compatible with 142.*" by me after testing for a week with the beta.

I usually tell users that it is already compatible and to go to Add-ons Manager and do a forced update - which apparently refreshes the info and flags my Add-ons as compatible.

I believe the bug is triggered by Thunderbird updating and then not updating its internally compatibility cache by reading the current entry from ATN, but rather waiting until the next scheduled update ping (worst case, next day if Thunderbird was restarted). I propose that Thunderbird should really update all the compatibility information after installing any update in order avoid this unnecessary question. I believe it does not update the (manually set) changed compatibility number if it's on the previous version (141) and already compatible. To just wait until the next scheduled time point rather than actively checking on it's own update doesn't make much sense to me.

I raised the bug after getting yet another question on QuickFolders compatibility. Then I also saw this bug (same problem, Thunderbird reporting SmartTemplates as incompatible on v142 - which it shouldn't)

https://github.com/RealRaven2000/SmartTemplates/issues/392

Severity: -- → S3
Priority: -- → P2
Hardware: Unspecified → x86_64

what a mess this was - I was waiting for nearly a month and finally, with help from Axel, the problem has been solved - it keeps saying that it is incompatible with TB 142

Priority: P2 → --

Hi Axel,

do you still get similar reports from users? Or how did you (permanently) resolve the issue?

Pretty much since the beginning of the monthly releases of Thunderbird, I got about one report per release from a user stating that Thunderbird considers my add-on Mail Merge as incompatible - both when trying to install my add-on or after Thunderbird has been updated. (So far this has only been affecting the monthly release versions!)

(Now for Thunderbird 144 I got already three such reports - but I assume this is more related to the growing number of users on the monthly release channel.)

At the moment the current version 11.2.0 of my add-on has the following compatibility information in the manifest.json - reflecting the latest beta version 143 of Thunderbird back at the time (2025-08-22):

"strict_min_version": "128.0a1"
"strict_max_version": "143.*"

Via the add-on developer hub I had updated the compatibility information as follows:

"strict_min_version": "128.0a1"
"strict_max_version": "*"

And on Monday I tried whether updating the compatibility information another time has any effect for the users reporting the problem:

"strict_min_version": "128.0a1"
"strict_max_version": "146.*"

But unfortunately it didn't solve the issue...

After reading your initial post, I asked the users to manually check for updates - both for Thunderbird via "Help -> About Thunderbird" and for Add-ons via "Add-ons Manager". Unfortunately this didn't solve the issue either...

Then I asked the users to send me the extensions.json. So far one user replied and sent me the file, which still has the (outdated) compatibility information as in the manifest.json, i.e.:

"targetApplications": [{
    "id":"toolkit@mozilla.org",
    "minVersion":"128.0a1",
    "maxVersion":"143.*"
}]

In the profile of one of my own computers the first update to "*" has been correctly applied, but the recent update on Monday is also still not being reflected, i.e.:

"targetApplications": [{
    "id":"toolkit@mozilla.org",
    "minVersion":"128.0a1",
    "maxVersion":"*"
}]

Just out of curiosity I tried to delete the extensions.json and after the next start of Thunderbird and manually checking for add-on updates, the compatibility information was as expected, i.e.:

"targetApplications": [{
    "id":"toolkit@mozilla.org",
    "minVersion":"128.0a1",
    "maxVersion":"146.*"
}]

This makes me believe that Thunderbird can indeed still fetch the updated compatibility information from the add-on developer hub, but it apparently doesn't do this regularly and especially when necessary, i.e. for Thunderbird updates, add-on updates and add-on installations. (At least for some users...)

I don't know what else I could try - other than releasing a new version with updated compatibility information in the manifest.json. Maybe you - or any other reading this - have any idea?

Inspired by Alexander's post, I stepped through the code when manually checking for updates. My test profile is on 144, with my own add-on incompatible and disabled. I then updated ATN to mark it compatible with 144.* and checked for updates. Nothing.

The url which was queried was

https://versioncheck.addons.thunderbird.net/update/VersionCheck.php?reqVersion=2&id={8845E3B3-E8FB-40E2-95E9-EC40294818C4}&version=6.4&maxAppVersion=143.*&status=userEnabled,incompatible&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}&appVersion=144.0.1&appOS=Linux&appABI=x86_64-gcc3&locale=de&currentAppVersion=144.0.1&updateType=97&compatMode=strict

Removing the compatMode does return something:

https://versioncheck.addons.thunderbird.net/update/VersionCheck.php?reqVersion=2&id={8845E3B3-E8FB-40E2-95E9-EC40294818C4}&version=6.4&maxAppVersion=143.*&status=userEnabled,incompatible&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}&appVersion=144.0.1&appOS=Linux&appABI=x86_64-gcc3&locale=de&currentAppVersion=144.0.1&updateType=97

And indeed, toggling extensions.strictCompatibility off, updated the compat data and re-enabled my add-on. Can you or your users reproduce this?

Edit: A couple of minutes later, the url with compatMode=strict also returned something, so this seems to be a caching issue? I will retry.

Switching extensions.strictCompatibility simply caused Thunderbird to use a different URL, which had a different cache state. I repeated the test:

  • switched the upper limit of Quicktext on ATN back to 143.*
  • waited until both check URLs mentioned in Comment 5 returned no compatible versions
  • created a new ESR profile and installed Quicktext ( extensions.strictCompatibility was not changed from the default, which is true)
  • upgraded the ESR profile to Release 144
  • observed Quicktext being disabled
  • switched the upper limit of Quicktext on ATN back to 144.*
  • used the "Check for updates" function of the add-on manager until Quicktext was re-enabled again (took a couple of hours)

I will now repeat the test, but wait for the background update, which uses https://versioncheck**-bg**.addons.thunderbird.net and might have a different cache state/behavior.

The background check also successfully re-enabled my add-on:

  • Thunderbird was kept open the entire time
  • Add-on manager showed the disabled add-on
  • Background update fetched the new upper limit set in ATN and re-enabled it
  • extensions.json was updated

I will now try to identify a code path, where this could go wrong. The place where the extensions.json file is saved is here:

https://searchfox.org/firefox-main/rev/0b21972a78f8915f73ce5579eeee2aa8c9c7d67e/toolkit/mozapps/extensions/internal/XPIDatabase.sys.mjs#1812-1842

Asking affected users to look for warning messages regarding Failed to save XPI database could give a hint.

The trigger for the save is here:

https://searchfox.org/firefox-main/rev/0b21972a78f8915f73ce5579eeee2aa8c9c7d67e/toolkit/mozapps/extensions/internal/XPIDatabase.sys.mjs#721-749

I do not see how that can fail. Any ideas? As it stands now, these are the error cases I could imagine:

  • Caching issues in our CDN: Request to ATN continue to get the old data, but that should resolve over time and eventually return the updated data. In my tests, it took about 2h to get the updated data.

  • File system access error, when trying to save the updated database: Do affected users share a common environment? Maybe sandbox issues due to flatpack or snap installs?

  • Background updates disabled? Manual updates should work however...

  • Firewall issue? The requests to the update server are blocked. Monitoring the requests issued by Thunderbird using the developer tools (as shown in my screenshot), could also give hints.

Attachment #9523692 - Attachment is obsolete: true

Hi John,

thank you for taking the time to look into this! :-)

My first observation is that apparently the updated information via the backend at ATN is only applied, when the current maxVersion in the local database is smaller than the updated maxVersion via the backend at ATN. This means, it is only possible to raise the maxVersion via the backend at ATN but not to lower it afterwards, correct?

The variable aSyncCompatibility seems to be true only when the add-on is installed - see XPIInstall.sys.mjs#3059-3060:

this.syncCompatibility = aReason == AddonManager.UPDATE_WHEN_NEW_APP_INSTALLED;

Maybe the check in XPIDatabase.sys.mjs#726-738 should be at least targetApp.maxVersion != updateTarget.maxVersion:

if (
  targetApp.id == updateTarget.id
  &&
  (aSyncCompatibility || Services.vc.compare(targetApp.maxVersion, updateTarget.maxVersion) != 0)
) {
  ...
}

Changing only the minVersion via the backend at ATN doesn't seem to have any effect, correct?

As both minVersion and maxVersion can be configured via the backend at ATN, I propose to simplify the check as follows... so the updated information via the backend at ATN gets always applied:

if (
  targetApp.id == updateTarget.id
) {
  ...
}

In the past I have set maxVersion = * for the latest version of my add-on - assuming I could lower it at any time, if I discover a compatibility problem with Daily or Beta. Looking at the code this seems to be a wrong assumption.

However, this seems to be in line with the observation in my comment #4 that lowering the maxVersion from * to 146.* via the backend at ATN did not have any effect on my own computers.

(Of course this is not related to the problem some of my users have observed, because then the installed version of my add-on would be still considered compatible with * and therefore NOT be considered incompatible!)

Best regards,
Alexander

Changing that code will probably not be possible, it is toolkit code (Mozilla).

if (
  targetApp.id == updateTarget.id
  &&
  (aSyncCompatibility || Services.vc.compare(targetApp.maxVersion, updateTarget.maxVersion) != 0)
) {
  ...
}

This means that a check is always done on APP_UPDATE, and here it would be allowed to downgrade the compat data. Say your last released version is marked to be compatible with 145, but while 145 is being shipped you realize it's not. If you switch the ATN setting back to 144.* it will not affect users who are already on 145, but everybody who is still upgrading from 144 to 145 will get the add-on disabled, despite the local cache saying it was compatible with 145.

You are right in your observations that normal updates to the local cache are only done when the max supported version has been increased on ATN.

However, this seems to be in line with the observation in my comment #4 that lowering the maxVersion from * to 146.* via the backend at ATN did not have any effect on my own computers.

That is indeed helpful information, which I would not have known without investigating this bug.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: