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

Steps to reproduce:

Launching the app

Actual results:

Takes more than 30s to display the main window

Expected results:

This version has many issues
Too long when starting
When I send a message, this open outlook. Why TB cannot send alone a message anymore ?
Many useful addon do not work anymore...

Launching takes more than 60s

Please Start Windows' safe mode with networking enabled

• win10 https://support.microsoft.com/en-us/help/12376/windows-10-start-your-pc-in-safe-mode

Still In Windows safe mode, start thunderbird in troubleshoot mode

• https://support.mozilla.org/en-US/kb/troubleshoot-mode-thunderbird

Does problem substantially improve?
If you have calendars, you issue might be calendar related

With windows in safe mode, TB crashes even in troubleshoot mode

I do have calendars, but these were present in the previous version (78) of TB and TB started in less than 30s.

TB V91 is rather a bad surprise since it is not possible to reinstall a previous version.

During startup, how much memory and CPU is Thunderbird using?

One of 4 TB tasks takes between 10 and 12% and between 160 and 165Mb. When the TB window is displayed, this task takes 329Mb.

What shows in tools > activity manager, and tools > developer > error console ?

Unexpected event profile-after-change URLQueryStrippingListService.jsm:224
Unknown Collection "thunderbird/query-stripping" RemoteSettingsClient.jsm:160
TypeError: win.gFolderTreeView._tree is null
FeedUtils.jsm:941:9
Successfully loaded OpenPGP library rnp.dll version 0.15.2+git20210806.dd923a4e.MZLA from C:\Program Files\Mozilla Thunderbird\rnp.dll RNPLib.jsm:92:15
getOrCreateFolderForURL: factory not registered for exquilla://bruno@192.168.0.1/Archives 2 FolderLookupService.jsm:76
Found 37 public keys and 6 secret keys (6 protected, 0 unprotected) RNPLib.jsm:288:15
[l10nregistry] Attempting to synchronously load file
resource:///chrome/en-US/locale/en-US/calendar/messenger/otr/otrUI.ftl while it's being loaded asynchronously. L10nRegistry.jsm:597:19
[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 692" data: no] L10nRegistry.jsm:692:19
Trying to load C:\Program Files\Mozilla Thunderbird\libotr.dll OTRLib.jsm:64:11
Successfully loaded OTR library C:\Program Files\Mozilla Thunderbird\libotr.dll OTRLib.jsm:72:13
tb.account.size_on_disk - Truncating float/double number. 10
La mise en page a été forcée avant le chargement complet de la page. Si les feuilles de style ne sont pas encore chargées, cela peut provoquer un flash de contenu non stylisé. aboutconfig.js:466:9
1630650142839 addons.webextension.<unknown> WARN Loading extension 'null': Reading manifest: Warning processing legacy: An unexpected property was found in the WebExtension manifest.
1630650142846 addons.webextension.<unknown> WARN Loading extension 'null': Reading manifest: Warning processing version_name: An unexpected property was found in the WebExtension manifest.
1630650142874 addons.webextension.<unknown> WARN Loading extension 'null': Reading manifest: Warning processing legacy: An unexpected property was found in the WebExtension manifest.
Attempt to override an existing message: "sidebar-preferences-button-title". 2
1630650143191 addons.webextension.<unknown> WARN Loading extension 'null': Reading manifest: Warning processing legacy: An unexpected property was found in the WebExtension manifest.
1630650143196 addons.webextension.<unknown> WARN Loading extension 'null': Reading manifest: Warning processing version_name: An unexpected property was found in the WebExtension manifest.
1630650143230 addons.webextension.<unknown> WARN Loading extension 'null': Reading manifest: Warning processing legacy: An unexpected property was found in the WebExtension manifest.
getOrCreateFolderForURL: factory not registered for exquilla://bruno@192.168.0.1/Archives 2 FolderLookupService.jsm:76
Attempt to override an existing message: "font-size-label".
Attempt to override an existing message: "window-close-key".
Attempt to override an existing message: "startup-label".
Attempt to override an existing message: "focus-search-shortcut".
Attempt to override an existing message: "close-button".
Le positionnement relatif des lignes de tableau et des groupes de lignes est désormais pris en charge. Ce site peut avoir besoin d’être mis à jour s’il repose sur le fait que cette fonctionnalité n’a aucun effet. preferences.js:261:2
[l10nregistry] Attempting to synchronously load file
resource:///chrome/en-US/locale/en-US/calendar/toolkit/intl/languageNames.ftl while it's being loaded asynchronously. L10nRegistry.jsm:597:19
[l10nregistry] Attempting to synchronously load file
resource:///chrome/en-US/locale/en-US/calendar/toolkit/intl/regionNames.ftl while it's being loaded asynchronously. L10nRegistry.jsm:597:19
[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 692" data: no] L10nRegistry.jsm:692:19
[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 692" data: no] L10nRegistry.jsm:692:19
Attempt to override an existing message: "font-size-label".
Attempt to override an existing message: "window-close-key".
Attempt to override an existing message: "startup-label".
Attempt to override an existing message: "focus-search-shortcut".
Attempt to override an existing message: "close-button".

80s before the TB window is displayed

The new version 91.1.0 (64bits) takes 2 minutes to start

(In reply to roquemaurel from comment #9)

The new version 91.1.0 (64bits) takes 2 minutes to start

All measurements with Windows and Thunderbird in safe mode?
Do you have a language pack installed?

These measurements are not made with windows and thunderbird in sagfe mode and the FR language pack is installed.
Please note that all other programs such as word, Corel draw, Firefox start in less than 10s.

(In reply to roquemaurel from comment #11)

These measurements are not made with windows and thunderbird in sagfe mode and the FR language pack is installed.

Thanks for that info. In that case, this is an issue related to language packs, which is still being investigated and worked on. I should have noticed it earlier with your comment 7.

Are you sure that's a dupe of bug 1642415? That can only be confirmed by looking at about:support data, and normally only happens when opening Preferences, not in common use (at least in Firefox).

Hmm, isn't bug 1642415 more general than just the Preferences, though that's the most common are people have encountered it?

I do not meet memory leak and high CPU when opening prefs/options/settings.
This issue, bug 1728744, should not be closed as duplicate now

I should test TB with a validated language pack before deciding the bug come from a language pack

(In reply to Magnus Melin [:mkmelin] from comment #15)

Hmm, isn't bug 1642415 more general than just the Preferences, though that's the most common are people have encountered it?

No. It's about incomplete fall-back (which happens only with same language pack on top of same locale build), and a window with a very high number of files loaded.

Things are getting worse with the version 91.2.0 (64bits) :
10 minutes between launching the app and display of the main window ....

What's next? And why is the performance getting worse? First 30 seconds, then two minutes, now 10 minutes which is quite extraordinary.

(In reply to Francesco Lodolo [:flod] from comment #18)

(In reply to Magnus Melin [:mkmelin] from comment #15)

Hmm, isn't bug 1642415 more general than just the Preferences, though that's the most common are people have encountered it?

No. It's about incomplete fall-back (which happens only with same language pack on top of same locale build),

Just curious, is it unusual for someone to install the same language pack, and is there a reason someone would intentionally do so?

and a window with a very high number of files loaded.

The 3-pane is such a window?

(In reply to Wayne Mery (:wsmwk) from comment #20)

What's next? And why is the performance getting worse? First 30 seconds, then two minutes, now 10 minutes which is quite extraordinary.

(In reply to Francesco Lodolo [:flod] from comment #18)

(In reply to Magnus Melin [:mkmelin] from comment #15)

Hmm, isn't bug 1642415 more general than just the Preferences, though that's the most common are people have encountered it?

No. It's about incomplete fall-back (which happens only with same language pack on top of same locale build),

Just curious, is it unusual for someone to install the same language pack, and is there a reason someone would intentionally do so?

No, absolutely unusual. It typically happens because people get confused between language packs and dictionaries, assuming the former includes the latter.

and a window with a very high number of files loaded.

The 3-pane is such a window?

The code would tell you. Preferences in Firefox has more than 20.

The 3pane has 13 .ftl includes: https://searchfox.org/comm-central/rev/5e94c611d13ff79f35b34f91c13af7064a927d58/mail/base/content/messenger.xhtml#72-84.
I don't really know where to debug this unfortunately.

Finally, Tbd did not start anymore. I reinstalled my profile with email accounts, calendars, address books ... and now Tbd works normally.

Given that it has been decided not to fix bug 1642415, what is our next step, and who gets the assignment of this bug?

Let's use this as the blocker for bug 1674132, and bug 1737922

Hi all,
Can I help somehow debugging this issue? Thunderbird continues to use CPU - currently sitting at 175% of a core - and it seems that in the wake of COP 26 no one is very bothered. Wayne suggested I disable language packs. I am no expert at langpacks, but I removed the RPM for en_GB. [Though that is my language] Can I proceed to remove all langpack rpms?
Thanks
Bill

If someone could provide steps to reproduce, with builds from thunderbird.net, that would be very useful! I spent some time trying earlier today, but did not manage to reproduce (though we do use more CPU than we'd like, in general).

Took some digging, but this looks very suspicious:
https://searchfox.org/comm-esr91/search?q=L10nRegistry.jsm&path=&case=false&regexp=false

Especially this call: https://searchfox.org/comm-esr91/rev/a76d36d427f3d0e255cd6bfb03d68efdc10bc6fe/mail/components/preferences/general.js#1025 which was later removed by https://hg.mozilla.org/comm-central/rev/9da37c24de095f8cd8b6177c666a6fe29f3d34cf#l9.12

Ah, maybe not. Firefox had something very similar.

Whatever the issue is, bug 1660392 changed so much that it's unlikely bugs would be the same outside of 91 (vs. trunk).

I'm able to reproduce it now on 91: Installed French language pack and set Thunderbird to use that. No problem with the en-US build, but starting with the fr build it uses insane amounts of cpu and memory (6.1G of mem after half a min).

Very peculiar bug.
It doesn't seem to be any particular ftl file that causes it. I can take out random ones and it's still a problem if the total number of files is large enough.

Since taking bug 1660392 and dependencies would be hard and risky, I think we should just take out this section
https://searchfox.org/comm-esr91/rev/a76d36d427f3d0e255cd6bfb03d68efdc10bc6fe/mail/components/preferences/preferences.xhtml#48-66
The downside is that then it's not possbile to search-find subdialog strings. But this bug disappears.

Try: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=013111b0c7a6b39f92d6701c4234d34fecaa2bd5

I left the about config in there. It didn't cause problems and seems like a common search.

This fixes it for the preferences window. It's unclear to me if any other places are affected. We could probably not work around those as easily if there are.

(In reply to Magnus Melin [:mkmelin] from comment #32)

Whatever the issue is, bug 1660392 changed so much that it's unlikely bugs would be the same outside of 91 (vs. trunk).

I'm able to reproduce it now on 91: Installed French language pack and set Thunderbird to use that. No problem with the en-US build, but starting with the fr build it uses insane amounts of cpu and memory (6.1G of mem after half a min).

Are there any errors in the browser console about missing ftl strings, either when using it in English or in French, for local builds?

When I run the French build + French lang-pack and it opens showing the preferences (from session restore) it directly goes into the spin so can't do anything except kill the program. I used --jsconsole and that doesn't show anything, but it's so locked up I can't even scroll down...

In --safe-mode everything works as it should. I see a couple of warnings then, but I'm not sure they matter
[l10nregistry] Attempting to synchronously load file
resource:///chrome/en-US/locale/en-US/calendar/toolkit/intl/languageNames.ftl while it's being loaded asynchronously.
[l10nregistry] Attempting to synchronously load file
resource:///chrome/en-US/locale/en-US/calendar/messenger/otr/otrUI.ftl while it's being loaded asynchronously.
[l10nregistry] Attempting to synchronously load file
resource:///chrome/en-US/locale/en-US/calendar/toolkit/intl/regionNames.ftl while it's being loaded asynchronously.

Mine doesn't freeze but it's slow to lunch and sluggish in general.

These are the error messages I see in the console:

This is repeated 6 times
[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: L10nRegistry.loadSync :: line 692" data: no]

These are repeated 4 times
downloadable font: kern: Too large subtable (font-family: "Open Sans" style:normal weight:700 stretch:100 src index:2) source: https://addons.thunderbird.net/static/css/impala/fonts/OpenSans-Bold.ttf?5014568
downloadable font: Table discarded (font-family: "Open Sans" style:normal weight:700 stretch:100 src index:2) source: https://addons.thunderbird.net/static/css/impala/fonts/OpenSans-Bold.ttf?5014568
downloadable font: kern: Too large subtable (font-family: "Open Sans" style:normal weight:400 stretch:100 src index:2) source: https://addons.thunderbird.net/static/css/impala/fonts/OpenSans-Regular.ttf?629a55a
downloadable font: Table discarded (font-family: "Open Sans" style:normal weight:400 stretch:100 src index:2) source: https://addons.thunderbird.net/static/css/impala/fonts/OpenSans-Regular.ttf?629a55a

I should specify.
The errors I listed happen only WITHOUT your patch, but on regular 91 with the IT language pack.

WITH your patch I don't see those errors.

If I'm not mistaken this should happen only when you have a packaged locale and langpack with the same locale.

Would it be possible to write code that disables locale that matches packaged locale?

Probably somehow, but I don't know where. I had the thought that maybe on load in the preferences I could remove the Fluent <link>s but it's already in a spin so doesn't get far enough to execute such code...

The problem is that you're solving a single subset of a single UI screen, while the problem can and will happen in many different UIs. The source of the problem is a single scenario where the user has a repackaged Thunderbird and then somehow ends up with a langpack for the same locale. This setup is pointless and should never happen, but it seems that it happens often for some reason.
(the reason it was not a very high priority in Firefox is that in Firefox it does happen very rarely)

My suggestion is to disable those langpacks.

Yes I'm fully aware it's not an ideal solution, and maybe not complete. I'm just whacking a mole.
Do you have suggestions of how to disable these langpacks?

Especially since this is 91-only...

blocklist?

nevermind, we don't want it disabled for every user

Yes, and even if we would manage to add code to - in time - disable the langpack, then the user might enable it again. Uninstall langpack would not always work like for distro-installed global ones.

Hi guys,
Just wanted to say - I reported 100-200% CPU burn with Fedora's tb 91.2. But thanks to Magnus' request from a couple of days ago I am now running tb 91.3 from www.thunderbird.net and it has dropped to O(5%) Of course I don't know the reason, but this is great for my battery!

Re disabling: I didn't realize lang-packs are not enabled/disabled the same way extensions are. Changing language requires restart. So perhaps even less feasible to go that route.

Comment on attachment 9251162 [details] [diff] [review]
Bug_1728744____ESR91__avoid_Fluent_bug_eating_insane_amounts_of_memory_until_OOM_when_opening_preferences__r_aleca.diff

[Approval Request Comment]
Regression caused by (bug #): Unknown.
User impact if declined: Localized build + lang pack will eat all your memory within minutes until OOM. Apparently also cases of high CPU and such.
Testing completed (on c-c, etc.): 91 only
Risk to taking this patch (and alternatives if risky): The actual change is not risky but searching in preferences won't find matches in subdialogs anymore. It's possibly we could find a better fix, but not sure how likely we're to find one.

Especially since this is 91-only...

I'm not very familiar with the Addons management, but my naive idea would be to look at code around https://searchfox.org/mozilla-central/source/toolkit/components/extensions/Extension.jsm#2994

and write something like (scaffolding):

let packaged = Services.locale.packagedLocales;
for (let locale of this.startupData.languages) {
  if (packaged.contains(locale)) {
    return; // bail early
  }
}
// otherwise add file source and register it

Re disabling: I didn't realize lang-packs are not enabled/disabled the same way extensions are.

I don't believe that sentence is correct. Langpacks are extensions and are enabled/disabled the same way (without requirement of restarts).

In the add-ons manager you can only trash them, not disable.

I should be able to try you suggestion tomorrow, thx!

(In reply to Bill Murray from comment #49)

Hi guys,
Just wanted to say - I reported 100-200% CPU burn with Fedora's tb 91.2. But thanks to Magnus' request from a couple of days ago I am now running tb 91.3 from www.thunderbird.net and it has dropped to O(5%) Of course I don't know the reason, but this is great for my battery!

Bother...leave it another hour and its climbed to 150% CPU again.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #52)

Seems to work! Should be in theory applicable for trunk as well, even if it doesn't cause huge problems there.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ac6cc12abfd8ac05a2482a00187e923de60f2eab

This looks to me like the best band aid. I'd prefer not to lock that patch in m-c because we don't have a technical reason to keep that limitation anymore, but it should address Tb 91 issue at lowest cost.

A little report update on a new issue that came up since yesterday.

Since the latest flatpak update to 91.3.2, the app tries to install language packs out of the box as soon as it's launched.
This resulted in the installation of 3 English language packs (EN, US, CA), causing the app to freeze and crash when accessing the prefs.

After manually deleting those lang packs, I now see 65 console errors on startup:

1637604867778	addons.xpi	ERROR	Failed to install distribution add-on
/app/lib/thunderbird/distribution/extensions/langpack-da@thunderbird.mozilla.org.xpi:
Error: File /app/lib/thunderbird/distribution/extensions/langpack-da@thunderbird.mozilla.org.xpi
does not contain a valid manifest(resource://gre/modules/addons/XPIInstall.jsm:669:11)
JS Stack trace: loadManifest@XPIInstall.jsm:669:11
awaitPromise@XPIProvider.jsm:215:15
installDistributionAddons@XPIProvider.jsm:2876:33
checkForChanges@XPIProvider.jsm:2983:22
startup@XPIProvider.jsm:2471:12
callProvider@AddonManager.jsm:230:31
_startProvider@AddonManager.jsm:590:17
startup@AddonManager.jsm:814:14
startup@AddonManager.jsm:3511:26
observe@addonManager.js:81:29

(In reply to Alessandro Castellani [:aleca] from comment #61)

Since the latest flatpak update to 91.3.2, the app tries to install language packs out of the box as soon as it's launched.
This resulted in the installation of 3 English language packs (EN, US, CA), causing the app to freeze and crash when accessing the prefs.

What a fault feast! Not only does it happen in the wild as seen on this bug and duplicates, but also from an UX POV, there's probably nothing inherently wrong with having multiple language pack flavors of the same base language, like British English, American English, Canadian English, etc. I don't fully understand the Firefox status or approach wrt this. Maybe someone can add a comment with an executive summary.

there's probably nothing inherently wrong with having multiple language pack flavors of the same base language, like British English, American English, Canadian English, etc.

There's no impact of multiple variants of English on this problem. The bug is only when the particular locale is present both as packaged and langpack and a missing l10n id is encountered.

This means that assuming your packaged version is en-CA, it doesn't matter if you install 1, 5, 10 or 20 langpacks, but if one of them is en-CA as well, then the risk increases.

Then, if all strings used in UI are present in the language resources, the bug will not surface either. Only if the above is true and a missing string is present, the L10nRegistry will try to find a combination of resources that has a given string, and since there are many of them (16?) and multiple potential sources, the number of permutations it'll try is exploding.

I don't fully understand the Firefox status or approach wrt this.

This is a particular scenario that should be rare, and in Firefox was very rare. Unfortunately it seems that in Thunderbird 91 it is not and it was discovered late.

The Firefox status is that this bug was fixed in 94 branch (see bug 1642415) by rearchitecting l10nregistry-rs logic to limit the number of potential permutations.

This means that the problem in Thunderbird can be solved in one of three ways:

1. Do not distribute l10n resources with missing strings.
2. Do not register langpacks of the same locale as packaged locales <-- chosen approach
3. Uplift changes from Gecko 94

The (3) is very challenging since between 91 and 94 a number of l10n system refactors happened that enabled the fix, and all of them would have to be backported to 91.

This problem will also disappear when Tb updates to 94.

Comment on attachment 9251440 [details]
Bug 1728744 - prevent langpack vs packagedLocale overlap to avoid severe memory usage issues. r=zbraniecki

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined:
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky):

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #64)

This is a particular scenario that should be rare, and in Firefox was very rare. Unfortunately it seems that in Thunderbird 91 it is not and it was discovered late.

Probably the main reason is that Thunderbird 91 shipped with zero locales complete, because of the way content was exposed (lot of strings, and too late for locales to catch up), and other issues (changes to existing strings, causing strings with errors to be stripped).

Comment on attachment 9251440 [details]
Bug 1728744 - prevent langpack vs packagedLocale overlap to avoid severe memory usage issues. r=zbraniecki

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Causes severe memory issues.
• User impact if declined: When running with packaged locale colliding with an incomplete langpack (e.g. fr packaged locale + fr langpack), some situations - notably opening the Thunderbird preferences - will cause severe memory issues, eating RAM until OOM.
• Fix Landed on Version: N/A
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It a well confined fix that that could only impact langpacks.
• String or UUID changes made by this patch: none

Comment on attachment 9251440 [details]
Bug 1728744 - prevent langpack vs packagedLocale overlap to avoid severe memory usage issues. r=zbraniecki

I am taking this one on ESR given the number of dupes for 91 showing the high impact for these users and the fact that this should not have a negative impact on Firefox ESR users.

https://hg.mozilla.org/releases/mozilla-esr91/rev/b7e0d3f07d61

Fix should be in Thunderbird 91.4.0, scheduled for Dec 7.

Thank you all!! Today I posted a duplicate of this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1743109) and after removing the Italian Language Pack the problem (obviously) is solved. Can't wait for 91.4.0 (c'mon guys!!! It's November 26!!! ;) )

(In reply to Magnus Melin [:mkmelin] from comment #77)

Fix should be in Thunderbird 91.4.0, scheduled for Nov 7.

December 7.

(In reply to Wayne Mery (:wsmwk) from comment #79)

(In reply to Magnus Melin [:mkmelin] from comment #77)

Fix should be in Thunderbird 91.4.0, scheduled for Nov 7.

December 7.

I was about to ask for that time machine which brings bug fixes back in time so that they won't even occur in the present... :-))

(In reply to Wayne Mery (:wsmwk) from comment #79)

(In reply to Magnus Melin [:mkmelin] from comment #77)

Fix should be in Thunderbird 91.4.0, scheduled for Nov 7.

December 7.

AHHHHHHECCO!!!!😉😎

Comment on attachment 9251440 [details]
Bug 1728744 - prevent langpack vs packagedLocale overlap to avoid severe memory usage issues. r=zbraniecki

This was successfully uplifted to ESR91 for the TB 91.4.0 release. Removing the approval to get this off the needs-uplift radar since this component doesn't have the appropriate status flags for us to set.