All Products Community Forum

While attempting to upgrade my Ubuntu Thunderbird client, I saw the attached screen. I'm concerned because of the unsophisticated style of the page, and the fact that it asks for my password, which makes me think "phishing". Can some trustworthy person confirm that this is a legitimate screen?

Lightning Strikes again.

As soon as TB upgraded to 143 I had the following problems:

1. Half my folders disappeared. In this day and age, where emails are "official documents" to prove communications.... 2. I could not delete any email, folder. 3. I could not create a folder.

So, I deleted that installation and reinstalled TB.

Same issues. NO CHANGE with a clean install.

Thunderbird just updated itself to a state where I need to do the setup process manually, which always takes a few hours (with networksolutions as the host). How can I continue to work with the previous version until the bug is fixed or I have time to go through the entire complicated process? Thanks in advance, Knut

I've been struggling for months to standardize a deployment of Firefox ESR across various client environments that reliably auto-updates and doesn't cause UAC prompts and XULRunner profile error pop-ups(I work in IT).

We deploy Firefox ESR in bulk on machines via a batch script which runs as SYSTEM, with msiexec /i and /qn flags.

Firefox installs fine, but then users are typically met with a UAC prompt when they first try to run Firefox. If they decline, then the UAC prompt comes back again next time and often fails to update at all, so the machine is left on an older, vulnerable version.

Regarding the environment: we have deployed the Firefox ESR admx templates and enabled the relevant auto update settings in Group Policy. But only some machines seem to stay up to date, and it seems like this only happens if a user with local administrative privileges has run the program at least once.

What I find unusual is that Firefox seems to attempt to make a "Background Updater" scheduled task for every user that runs the software on each PC, but these users do not have administrative privileges, and the scheduled task is set to only run when that user is logged in. Obviously a scheduled task running as a user with limited privileges isn't going to be able to update files in the Mozilla/Firefox subdirectory in "Program Files" as by default that's read-only access for non-admin users. And, obviously, if a user with local admin privileges DOES log into the machine, then it can update once, but then the scheduled task that it creates for that user (now with admin privileges) will only run when that user logs in - and we don't login as "admin"-privileged users day-to-day.

So, various machines are out of date, running vulnerable Firefox 128 instead of 140 or 142 even though they're all deployed from the same image and have the same policies and restrictions, and ran the same installer for Firefox.

Is there some reason why the auto update scheduled task isn't created at installation time, when administrative privileges have been granted? It's very odd that it doesn't, because then every time a user logs into a machine it seems like Firefox ESR creates the background upgrade task under a non-admin user which simply won't work. I see machines having 4 or 5 background upgrade scheduled tasks, all created by Firefox ESR, and yet the software still won't update - there's a UAC prompt every time the program launches, and going to Help -> About shows "Restart Firefox to update..." but then when clicking the button to restart Firefox, we get the UAC prompt, user doesn't have privileges, so this goes around and around in circles.

Is there a reliable way to keep Firefox up to date without manually logging into each machine and going through the UAC prompts? Can we manually create a scheduled task with the correct user account that has privileges to actually upgrade Firefox?

The background auto update mechanism simply doesn't make sense to our team on a machine-wide install.