Thunderbird 140.x | wrong NSS libs?

I think this is an .rpm packaging issue but can’t be sure. At any rate…

1\ have Fedora 42 running well on a Lenovo X1 carbon laptop. Wayland.

2\ had (past tense) Thunderbird 128 working perfectly. Since its relevant, main mail account uses POP3, and points at outlook.office365.com, using OAuth2 authentication. Worked perfectly.

3\ Tbird install had a couple of add-ons, but nothing fancy. Main one is Google provider (for accessing my various Google calendars).

I did an in-place update of TBird from 128 → 140, using dnf. Update went fine, but I noticed that a slew of things about using TBird in its 140 incarnation were ‘broken’. The first thing I noticed was that if I tried to access the preferences option for any of the add-ons, it either (i) spawns a tab, but the tab never shows anything. Its blank; or (ii) it brings up a windows with 3 options: details, preferences, and permissions. Selecting ‘preferences’ shows only a blank box, or (iii) spawns a new tab, which never resolves anything. And, for some addons, the ‘wrench’ icon (to access preferences) was greyed out (whereas using 128, it wasn’t). All of the addons are compatible with TBird 140 (in theory).

4\ I decided to try the Draconian experiment of doing a fresh, clean install of TBird 140 (dnf install thunderbird). First, I dnf removed Thunderbird, and manually nuked every file/cache related to it (e.g., deleted .thunderbird, and anything related to it). I did the fresh clean install of 140 from fc42 repos. Seemed to go fine, until I tied to Oauth2 handshake with outlook.office365.com. The little web popup window where I imagine I’m supposed to enter user and password information remained entirely blank. Eventually, timed out.

5\ In either situation (in-place upgrade from 128 → 140, fresh install of 140.x), if I tried starting TBird from the command line, I think see the problem. Lots and lots of messages about things like the following pointing at an NSS lib incompatibility:

XPCOMGlueLoad error for file /usr/lib64/thunderbird/libxul.so:
/usr/lib64/thunderbird/libnss3.so: version `NSS_3.107' not found (required by /usr/lib64/thunderbird/libxul.so)
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib64/thunderbird/libxul.so:
/usr/lib64/thunderbird/libnss3.so: version `NSS_3.107' not found (required by /usr/lib64/thunderbird/libxul.so)
Couldn't load XPCOM.
<etc, etc>

I found this puzzling to say the least, since machine definitely has nss 3.116 installed:

 nss.x86_64                      3.116.0-1.fc42 updates
 nss-devel.x86_64                3.116.0-1.fc42 updates
 nss-mdns.x86_64                 0.15.1-25.fc42 fedora 
 nss-softokn.x86_64              3.116.0-1.fc42 updates
 nss-softokn-devel.x86_64        3.116.0-1.fc42 updates
 nss-softokn-freebl.x86_64       3.116.0-1.fc42 updates
 nss-softokn-freebl-devel.x86_64 3.116.0-1.fc42 updates
 nss-sysinit.x86_64              3.116.0-1.fc42 updates
 nss-tools.x86_64                3.116.0-1.fc42 updates
 nss-util.x86_64                 3.116.0-1.fc42 updates
 nss-util-devel.x86_64           3.116.0-1.fc42 updates
 nss_wrapper.x86_64              1.1.16-4.fc42  updates
 nss_wrapper-libs.x86_64         1.1.16-4.fc42  updates

But, for some reason, TB 140.x seems to be looking for something (NSS_3.107) it can’t find.

If I run

 sudo find / -name "libnss3.so*" 2>/dev/null

it shows that nss is in fact where TBird seems to be looking for it:

 /opt/google/chrome/libnss3.so.1d
 /usr/lib64/thunderbird/libnss3.so
 /usr/lib64/libnss3.so

But for some reason, TB isn’t seeing it as the ‘right version’.

Of note, maybe, TB 140.3 works fine on my AlmaLinux 9 machines, which have a ‘less recent’ version of the NSS libs. But, oddly (or perhaps part of the issue), only in /usr/lib64. The rpm for TBird on AlmaLinux seems to be looking for nss in a different location than does the rpm for Fedora 42.

In summary, the issue seems to be that TB 140.3, as currently packaged, is either (i) looking for the wrong libs, or (ii) is not correctly parsing where they are in a typical Fedora 42 installation. [I’m assuming nss 3.116 is backwards compatible with the nss 3.107 that TBird seems to be looking for.]

Any suggestions? 128 runs fine, but I have 140.x on all my non-Fedora machines, and don’t like getting systems too out of sync.

I don’t have an answer to the nss problem, but I see that Fedora will apparently switch to the non-ESR release branch of Thunderbird in an upcoming update.

Making sure you're not a bot!

I use the original version released by the Thunderbird team.
This has two major advantages:
It updates itself if enabled, and you can choose which release branch you want to use.

Directory Listing: /pub/thunderbird/releases/140.4.0esr/linux-x86_64/

Thanks. I used to do that on my CentOS boxs, but out of pure laziness, have been using the package manager approach on my Fedora machines.

In the end - solved the problem by (i) completely blowing away 100% of everything I could find (directories, subdirectories, cache…) related to Thunderbird, (ii) upgrade Fedora from 42 → 43 (which went perfectly), (iii) and installing TB 140.3 using dnf. Yes, I had to rebuild my profile, but that wasn’t more than a 10 minute job. More importantly, everything with TB 140.3 seems to work. None of the issues I was having as per OP.

Yet another personal example of: “if its broken, refresh (or upgrade), and start over”.