Closed Bug 1970126 Opened 11 months ago Closed 10 months ago

32-bit Thunderbird does not remember passwords when using MAPI

Categories

(MailNews Core :: Simple MAPI, defect)

Product:
MailNews Core
Component:
Simple MAPI
Version:
Thunderbird 139
Platform:
x86
Windows
Type:
defect

Tracking

(thunderbird_esr140 fixed, thunderbird139+ affected, thunderbird141 unaffected, thunderbird142 unaffected)

Status:
RESOLVED FIXED
Milestone:
142 Branch
Tracking Flags:
Tracking Status
thunderbird_esr140 --- fixed
thunderbird139 + affected
thunderbird141 --- unaffected
thunderbird142 --- unaffected

People

(Reporter: austen, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [fixed by bug 1967485])

User Story

SUMMARY

**What we know**

* likely not specific to imap or pop
* likely only happens when compose window is suppressed

works 138.0.2
works 2025-04-03 139.0a1  (note, the first 139.0a1 is dated 2025-04-01)
fails 2025-04-04 139.0a1
fails 139.0
fails 140 (presumably also ESR)

fails 2025-06-10 141.0a1
works 2025-06-11 141.0a1

**What we don't know**

* What patch/bug broke 139.0a1
* What patch/bug fixed 141.0a1
* What aspect, if any, of the calling software causes this bug

Potential regressors

c-c: https://hg-edge.mozilla.org/comm-central/pushloghtml?startdate=2025-04-03+08%3A00%3A00&enddate=2025-04-04+10%3A00%3A00
m-c: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?startdate=2025-04-03+08%3A00%3A00&enddate=2025-04-04+10%3A00%3A00


Potential Fixers

c-c: https://hg-edge.mozilla.org/comm-central/pushloghtml?startdate=2025-06-10+08%3A00%3A00&enddate=2025-06-11+11%3A00%3A00
m-c: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?startdate=2025-06-10+08%3A00%3A00&enddate=2025-06-11+10%3A00%3A00

UPDATE: Stack from m-c bug 1967485 seems to fix this issue

Attachments

(4 files, 4 obsolete files)

Screnshot
11.67 KB, image/png
Details
simple_mapi_test.c
1.39 KB, text/plain
Details
Unbenannt.png
19.11 KB, image/png
Details
cancel button in dialog.png
12.02 KB, image/png
Details

Steps to reproduce:

Only testing in x86 version

Sent an email via MAPI

Actual results:

Unable to access saved passwords for email account. When email is sent the password prompt appears. Even after inputting password and choosing to save it, the issue happens again.

The password manager does have the password saved and does not prompt for the password inside the application when sending an email within thunderbird.

Expected results:

When using MAPI the saved passwords should be accessible.

THanks for the info.

This probably existed prior to version 139?

Group: mail-core-security
Flags: needinfo?(austen)

Tested as working in 138.0.2 and has worked for the last couple of years for us with previous builds.

Flags: needinfo?(austen)

Thanks very much for the detail.

Ramona/Vlad does this also fail for 64bit?

status-thunderbird139: --- → affected
tracking-thunderbird139: --- → +
tracking-thunderbird140: --- → ?
Flags: needinfo?(vlucaci)
Flags: needinfo?(ramona)
Keywords: regression, regressionwindow-wanted
Component: Security → Simple MAPI
Product: Thunderbird → MailNews Core

Hello,

I just tried this using an Outlook/Office365 account on x64 machines(Windows 11, Ubuntu 25 and macOS 15) but did not manage to encounter it. I never get the password prompt when attempting to send an email from said account. Builds used were:

  • 141.0a1(20250603095824)
  • 139.0.1(20250531130320)
  • 138.0.2(20250519142253)

Are there any other steps or maybe settings/addons that I could use to maybe try to replicate again on x64?

Flags: needinfo?(vlucaci)
Flags: needinfo?(ramona)

Not tested on x64, but we saw this after updating from 138.0.2 to 139 (so not a clean install, and using existing profiles with saved passwords) on all machines that use the MAPI service. reverting back to 138.0.2 by running with --allow-downgrade fixed the issue. After reverting the first MAPI call requested the password then after that was working again.

It would probably be helpful if you could establish a precise regression range using https://mozilla.github.io/mozregression/

Flags: needinfo?(austen)

Austen, can you try comment 6?

Austen, please report back with the results

The issue is reproducible. It first appeared in version 139. Rolling back to 138 temporarily resolves the problem. The bug is also present in the Beta and Daily builds.

Specifically, it can be reproduced as follows:

  1. Send mail via MAPI as usual (if you display Thunderbird’s compose window, everything works as expected).

  2. In my case, the error ALWAYS occurs when you send mail via MAPI WITHOUT showing the compose window (if you do that the first time in Thunderbird you have to confirm the following dialog (https://www.workshop-software.de/cms/images/offers/gvmail/thunderbird/tb-versand-bestaetigen001.PNG).
    → you then experience exactly the behavior described above: you’re repeatedly prompted for the SMTP password…

so to be clear: no bug if you choose to display Thunderbird's compose window

reproduceable bug: if you choose NOT TO DISPLAY Thunderbird's compose window (Bug appears in Windows 10, Windows 11 etc..)

in general this is a very important critical feature cause i know a lot of people/companies who send mail from their ERP software etc. via MAPI through Thunderbird WITHOUT showing the compose window (because if you do that 100x day its a bit nervy)

Flags: needinfo?(lilale2363)

32bit version(s) or 64bit version? At least in the past there were MAPI issues if you moved between those...

The bug is definitely present in the 32-bit build. I can’t judge the 64-bit build at the moment—since I don’t have one installed—but I suspect it’s affected as well.

What I can add is that it’s been completely reproducible on at least ten machines. Some of those have been running Thunderbird for years, and after every minor or major update they never experienced this issue. Additionally, on three other machines I only installed Thunderbird four months ago—so they only ever had the previous 138 build—and as soon as it was updated to 139 the bug appeared immediately. In other words, the error occurs whether Thunderbird has been installed for years or was freshly installed with version 138.

I also firmly believe that a brand-new installation of Thunderbird 139 would exhibit the same bug right away.

Can you not reproduce the issue on your end?

Flags: needinfo?(lilale2363)

Furthermore: there has been no switching back and forth between 32- and 64-bit versions. These are definitely 32-bit builds that updated via auto-update. On some machines still running the 128 ESR version, I used the 32-bit installer as usual and installed over it—and the bug still occurs.

In summary:

The bug appears after an auto-update

The bug appears when updating via the EXE/installer

There was no switching between 32- and 64-bit versions

JohnyBoy: can you get a regression range using https://mozilla.github.io/mozregression/ ?

i do it - give me some hours ;-) - never done it before

so i tried to test it but its not working. my software uses the MAPI and then always the old standard Thunderbird is used. means 138.0.2.

so if i want to recreate a new thunderbird is downloaded an startet. but then when i use the mapi to recreate it the Thunderbird 138.0.2 is startet and not the downloaded daily from that regression tool

ok i tried to use thunderbird dailys (that version which was downloaded from that regression tool) preferences section to tell windows to use thunderbird daily as standard email software. now the mapi interface is destroyed and my software cant find any email software when trying so send email via mapi

so that also no way to test it.

dont u have a test case which recreates the problem`?

-> a third party software which wants to send email via MAPI without showing the compose window of thunderbird. as mentioned above the problem ALWAYS is there. easy to recreate

======================

so i tried a different approach -> just download a few dailys and install them an try to find out from which day / which version it does not work any longer -> would that help`?

so therefore i downloaded a daily from here:
https://archive.mozilla.org/pub/thunderbird/nightly/2025/04/2025-04-24-10-05-16-comm-central/
installed it... -> File thunderbird-139.0a1.en-US.win32.installer.exe 71M 24-Apr-2025 12:24
-> bug is in this version from 24.04.205

so i could try older version....but then this happend: unfortunately the software autoupdates really fast but the good is: in daily 141.0a1 22.06.2025 it is working....so did you already change something`?

so i did not look more into older versions but i can to help

greets

: in daily 141.0a1 22.06.2025 it is working....so did you already change something`?

Good that it's working for you now. I don't think anything changed intentionally.

How is v140?

Austen, can you test as well if it's working for you?

working:
Beta 141.0b1 (32-Bit) Update from today

also working:
Daily 142.0a1 (2025-06-29) (32-Bit)

can you give me URL of v140 which i should test`?

It will be released soon (likely later today).

but hopefully not as ESR? because if the bug is in there and all customers of me update from 128 i have a big problem....

luckily, right now all these machine still working with 128.02

Yes 140esr (as well) though it won't roll out automatically to 128esr users just yet

okay i check it out later, update several installations and give feedback if 140 works fine.

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

Yes 140esr (as well) though it won't roll out automatically to 128esr users just yet

Actually, it is expected that esr140 will be offered to esr128 users today.

thats no good. because than the regression bug will reach everybody ?!?

please give me a link where i can check the 140 version if the bug is still in it or not

ok i need 10 min max

please dont roll this out. the bug is definitiv in this version and will reach everbody who uses MAPI without showing the compose window of thunderbird

Attached image Screnshot —
Blocks: tb140found

so what now`?

i dont care if 140 has the bug in it as long the ESR version from 128 will not be updated....that version is still working.
the workaround is right now for everybody who has newer versions than 138 to roll back to 138.0.2 an then not to allow updating.

if the 128 ESR version will get updated than this rollback has to be done at least for my for over 500 installations

i think this is a major blocker

status-thunderbird141: --- → unaffected
status-thunderbird142: --- → unaffected
OS: Unspecified → Windows
Hardware: Unspecified → x86
Summary: Thunderbird does not remember passwords when using MAPI → 32-bit Thunderbird does not remember passwords when using MAPI

these are customers machines...i dont have access to them

(In reply to JohnyBoy from comment #30)

Bug is in it!!!

-> in this version: https://ftp.mozilla.org/pub/thunderbird/candidates/140.0esr-candidates/build5/win32/de/

Thanks for testing. Is this reproducible on 64bit?

i dont understand. bug was reported 27 days

8 days ago i wrote again a precise description

and its reproduceable

and now this major bug gets published ?! how many companies will be affected by this decision . private persons dont care. but in a professionell environment where MAPI is used you send emails without showing the compose window and EVERY SINGLE MACHINE will be affected from this bug

Nothing is yet published.

JohnyBoy: could you try to figure out which Daily fixed it?

i cross checked with another machine. regarding 32 Bit my results are correct.

now testing 64 bit (i think theres also the bug)

Jeremy, can you test 32bit version of https://ftp.mozilla.org/pub/thunderbird/candidates/140.0esr-candidates/build5/win32/ to see if also fails for you?

Flags: needinfo?(jerj)

64Bit: i need a clean machine. after mixing 32 and 64 bit my api doesnt work. tomorrow i get access to a clean machine

is that okay for you`?

ok 64 bit seems to work. but not 100% sure. in general i ALWAYS installed the 32 bit version BECAUSE of the MAPI because the last 10 years it was always better in combination with MAPI to use 32 bit.

right now i have again the problem that the DLL isnt found/shown in my software if if use 64 bit version of thunderbird. i'm gonna try to install it tomorrow on a clean machine.

besides: the 32 bit version DEFINITIVLY has this bug, i tried it on a windows server machine (Win Server 2012, 2016, 2022) and there's the same problem. so OS independent regarding windows OS

question from me: cant you recreate the bug? dont u have a software which uses mapi WITHOUT showing the compose windows of thunderbird?

(In reply to Austen Draper from comment #5)

Not tested on x64, but we saw this after updating from 138.0.2 to 139 (so not a clean install, and using existing profiles with saved passwords) on all machines that use the MAPI service. reverting back to 138.0.2 by running with --allow-downgrade fixed the issue. After reverting the first MAPI call requested the password then after that was working again.

139.0's comm-release patches.

Magnus do you see anything in there?

Flags: needinfo?(mkmelin+mozilla)

(In reply to JohnyBoy from comment #51)

ok 64 bit seems to work. but not 100% sure. in general i ALWAYS installed the 32 bit version BECAUSE of the MAPI because the last 10 years it was always better in combination with MAPI to use 32 bit.

Indeed, there have been 64bit mapi issues in the past. And maybe the vast majority of mapi users have stayed with 32bit for this reason.

question from me: cant you recreate the bug? dont u have a software which uses mapi WITHOUT showing the compose windows of thunderbird?

I haven't been home to test a windows machine, most of our devs are non-windows, and our QA who weighed in with comment 4 for 64bit is offline for 9-10 more hours.

Ramona/Vlad can you reproduce with 32bit only? And find when it started working again in dailies? Note comment 17, "141.0a1 22.06.2025" daily works.

Flags: needinfo?(vlucaci)
Flags: needinfo?(ramona)

(In reply to Wayne Mery (:wsmwk) from comment #52)
Unfortunately I don't see anything there.

Flags: needinfo?(mkmelin+mozilla)

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

Nothing is yet published.

JohnyBoy: could you try to figure out which Daily fixed it?

i'm gonna find out which version fixed it. beginning in 2 hours

i'm gonna find out which version fixed it. beginning in 2 hours

That will be extremely helpful.

Also, what software and version of software are you using to trigger emails through Thunderbird?

Flags: needinfo?(lilale2363)

okay here my results from a total different machine:

as mentioned above: Beta 141.0b1 (32-Bit) Update is working (that was the version which was installed already on that machine)

ok now older versions:

  1. -> bug is in this version from 24.04.2025
    as mentioned above: https://archive.mozilla.org/pub/thunderbird/nightly/2025/04/2025-04-24-10-05-16-comm-central/
    installed it... -> File thunderbird-139.0a1.en-US.win32.installer.exe 71M 24-Apr-2025 12:24

  2. -> bug is in this version from 30.04.2025
    https://archive.mozilla.org/pub/thunderbird/nightly/2025/04/2025-04-30-10-01-35-comm-central-l10n/thunderbird-140.0a1.de.win32.installer.exe

  3. -> bug is in this version from 15.05.2025
    https://archive.mozilla.org/pub/thunderbird/nightly/2025/05/2025-05-15-09-34-36-comm-central-l10n/thunderbird-140.0a1.de.win32.installer.exe

this for the first update. i keep on testing

Flags: needinfo?(lilale2363)

  1. -> last version of 140 from 26.05.25 -> bug is in this version
    https://archive.mozilla.org/pub/thunderbird/nightly/2025/05/2025-05-26-10-55-35-comm-central-l10n/thunderbird-140.0a1.de.win32.installer.exe

  2. -> first version of 141 from 27.05.2025 (141.0a1 (2025-05-27) (32-Bit) -> bug is in this version
    https://archive.mozilla.org/pub/thunderbird/nightly/2025/05/2025-05-27-05-28-40-comm-central-l10n/thunderbird-141.0a1.de.win32.installer.exe

i keep on testing

You likely want to be looking at 141.0a1 between 2025-05-26 and 2025-06-23

ok i can confirm after cross checking: the last version which HAS THE BUG is this one from 10.06.2025: https://archive.mozilla.org/pub/thunderbird/nightly/2025/06/2025-06-10-09-40-17-comm-central-l10n/thunderbird-141.0a1.de.win32.installer.exe

The version from 11.06. doenst have the bug anymore.

so does that help`?

Attached file simple_mapi_test.c —
Hi, I've written a test script which I have run successfully on 139.0.2 (32-bit) and 64 bit - it does not bring up the compose window and sends successfully from my thunderbird.net account to my personal Gmail. Could you perhaps provide some more details about how I might reproduce the problem that you are running up against?

Hi Tobiy
I have an ERP software that allows me to access Thunderbird via a MAPI interface. This has worked excellently for over 20 years. It works with version 138 and also with the mentioned versions—just not with the ones I attached here. And I really don’t have to do much. In my software, I simply specify the MAPI DLL. I can select it, and then it works automatically.

In the software, I can also specify whether the Thunderbird compose window should be displayed or not. Most users, of course, prefer not to see it and just send the email directly. And then it gets sent without showing the compose window. But that no longer works. That’s basically the issue.

What happens now is that Thunderbird either opens or comes to the foreground. Normally, the email would just be sent and appear in Thunderbird’s Sent folder. But this time, a flashing Thunderbird window appears in the Windows taskbar. And when you click on it, there’s a dialog saying you need to enter your password (see attachments screenshot). You try again, but the same thing keeps happening. Eventually, after 10 or 20 seconds, it says something is wrong with the SMTP settings. But the settings are correct.

Austin Draper seems to have the exact same issue.

how did i find the issue? a customer called me an said: emailing does not work any longer....and then the journey began...

Some mapi commentary in Bug 1964616 - Thunderbird content process on Windows is not sufficiently sandboxed

From bug 1964616 comment 37

(In reply to Kai Engert [:KaiE:] from comment #36)

Could this have caused bug 1970126 ?

I guess it could in theory, but I would have thought that would mean that it would have to be using a content process for updating this, which would be strange. The linux bit did add a setting for the socket process as well, but I don't think you're using that.
Does comment 29 have anything to do with this?

From bug 1964616 comment 29 and 31

Unfortunately the MAPI code doesn't like level 8. Our Windows debug mochitests are blowing up with assertions. Looks like we need to be at 7 after all. (Unless somebody wants to dig in and figure out why. I can't even build with MAPI enabled, so not me.)

All I know is we're getting an assertion failure from the MAPI code at shutdown. MAPI itself may or may not work, I don't know, and we have no automated tests of it. I suspect it doesn't work.

This is from bug 1966153 landing today, so the current nightly is unaffected but the next one won't be. We could mitigate this by setting security.sandbox.content.level to 7.

User Story: (updated)

Based on: Bad 2025-06-10 141.0a1, Good 2025-06-11 141.0a1:
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?startdate=2025-06-10+8%3A00%3A00&enddate=2025-06-11+10%3A00%3A00
with sandboxing changes in bug 1967046 and bug 1967485.

We did end up setting the sandbox level to 7 instead of 8. Does this bug go away if security.sandbox.content.level is lowered further?

(In reply to Geoff Lankow (:darktrojan) from comment #68)

We did end up setting the sandbox level to 7 instead of 8. Does this bug go away if security.sandbox.content.level is lowered further?

JohnyBoy, you might start in the range 0-3 and work your way up.

Hi Wayne, i dont know that preference. how can i assist you in testing`?
thx for short instruction

  1. open the config editor https://support.mozilla.org/en-US/kb/config-editor
  2. paste in security.sandbox.content.level
  3. click the pencil icon to edit
  4. change the value and hit the checkbox
  5. restart thunderbird and test

thx
any version which did not work or should i test a specific one`?

You can try setting security.sandbox.content.level to 0 for any affected version and see if it makes a difference.
IF that makes it work, increase the number to up to 7 (which is the default) to see which level is ok. I think a restart of Thunderbird is required for it to come into effect.

sorry for late feedback.

didnt help. i used this version:
https://archive.mozilla.org/pub/thunderbird/nightly/2025/06/2025-06-13-10-24-17-comm-central-l10n/thunderbird-141.0a1.de.win32.installer.exe

  1. recreated bug to be sure this version has the bug
  2. edited security.sandbox.content.level: from 7 (that's what was used) to 0
  3. restartet thunderbird -> same bug behaviour
  4. even restartet machine -> same bug behaviour
Attached image Unbenannt.png —

send another screenshot which shows what i tried to describe here:
What happens now is that Thunderbird either opens or comes to the foreground. Normally, the email would just be sent and appear in Thunderbird’s Sent folder. But this time, a flashing Thunderbird window appears in the Windows taskbar.

  1. TB starts as always (wasnt startet before) - so the mapi call startet TB (as always the last 20 years)
  2. another "window"/programm is in the windows task bar, which is blinking...-> see screenshot
  3. if you click an that -> the first screenshot is shown (means this one: https://bug1970126.bmoattachments.org/attachment.cgi?id=9497641)

((

tried: 1, 2, 3, 7, 8, 9

nothing helped

JohnyBoy, Thanks for that info. Are you using software developed in-house or off the shelf (and can you share the name)?

Austen reports - "In-house software that we develop. It was developed with OpenText Team Developer and I believe just uses the Microsoft MAPI subsystem."

Flags: needinfo?(lilale2363)

In case it wasn't noticed, User Story section at the top of the bug report has a summary which can be edited.

User Story: (updated)

wayne: in-house using this component https://wiki.delphi-jedi.org/wiki/JCL_Help:InternetandE-mail.MAPI

Flags: needinfo?(lilale2363)
Flags: needinfo?(vlucaci)

is it solved? can i help testing?

We will try to narrow down the list of potentially problematic patches and create some builds for you to test with.

Do you have an installer for your software that we can try to use ourselves to reproduce this?

See comment 67. If it's fixed in TB 141, why not try porting those patches I pointed out back to 140?

Perhaps but seems tenuous given that testing the preference down to zero did not help

Magnus,
Could the problem have been introduced by bug 1846550 landing and then fixed when your patch in bug 1970828 landed? They touch similar files and the dates seem to line up with what landed on c-c during the periods of interest.

Flags: needinfo?(mkmelin+mozilla)
User Story: (updated)

JohnyBoy, Could you please test using the installer from this try build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=1efa0a0641c217c33fc123ae314f74061505181d&selectedTaskRun=cq2yOczFR_W6JcwVY1NtcA.0

This build uses m-c and c-c revisions from 2025-05-15 but with a patch applied that is a possible contender for what might have fixed the problem on 2025-06-11.

Flags: needinfo?(lilale2363)

@Toby. Sure i test! Where can i find the installer/exe`?

Flags: needinfo?(lilale2363)

Installer for the try run is here: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/cq2yOczFR_W6JcwVY1NtcA/runs/0/artifacts/public/build/install/sea/target.installer.exe

It would be surprising if those patches have effect, but since this issue is weird (maybe timing of something) to begin with, who knows. If that's the issue, bug 1970828 with follow-ups can be uplifted.

Flags: needinfo?(mkmelin+mozilla)

bug still there...

even started the pc new...

first try: the dialoag appears

if i click retry in the dialog shows again, if i click cancel the screenshot appears. that behaviour was the same in the past, i just wanted to say what happens if i click cancel in the dialog

as soon as you have a new version, i can test very fast, no problem.

To make it absolutely clear—so there’s no misunderstanding (and apologies, I’m not a native speaker)—the error unfolds exactly the same way it always has. The dialog appears immediately, giving you the options/buttons "Retry", "New Password", or "Cancel". If you click Retry, the dialog pops up again instantaneously. Click Retry a second time, and after a slightly longer pause the dialog reappears yet again. If you click Cancel, you see the screenshot I provided (cancel button in dialog.png). As a brief aside, the SMTP settings are correct. And last but not least, if you press the Enter New Password button you can type in a new password, but it doesn’t change anything. I just wanted to clarify that so there’s no confusion caused by my awkward phrasing.

Not awkward at all, and thank you so much for this information and for all your help!

This next install was built from the c-c and m-c code that produced the Daily on 2025-06-10 with the Firefox patch from m-c for bug 1966185 included (this was one of the many items that were included in the build on 2025-06-11 which could possibly have fixed the problem for us in that version)

Could you please try this build:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/KBvl8gjRSBeA1vjNVrF0dQ/runs/0/artifacts/public/build/target.installer.exe

Unfortunately, we've taken a look at the patches which landed in c-c between the 2025-06-10 and 2025-06-11 builds and there aren't any which could explain the fix. So we're now trying to pick out potential fixes from the list of m-c patches. Hopefully this isn't too painful for you to test.

Flags: needinfo?(lilale2363)

Hi again,
Here's another which caught my attention that I would like to test if you don't mind:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JjbiotxDS_mnBjbWbCGjdg/runs/0/artifacts/public/build/target.installer.exe

This one was built from the c-c and m-c code that produced the Daily on 2025-06-10 with the Firefox patch from m-c for Bug 1821878 included.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Hi Toby,
unfortunately bug is also in this one: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JjbiotxDS_mnBjbWbCGjdg/runs/0/artifacts/public/build/target.installer.exe

i've taken 2 different machines cause this version didnt want to use the existing profile. it asked for a new profile.
also on those 2 other machines. after creating a new profile i could test.

result as mentioned before: bug still there. (

Ok thanks for trying. I'll take another pass.

@Toby: Please try the two from comment 67.

Thanks @Francesco. I've actually noticed something else that I'm going to try first. There was a push that I missed in the initial timeframe with some potential fixes - it came in just before the build on 2025-06-11 so wasn't included. Will update the user story and run a build with m-c from 2025-06-10 and that stack to see if it works.

User Story: (updated)

Hi @JohnyBoy,
Here's another build for you to try. This is the fully intact m-c code from 2025-06-10 with the c-c code from 2025-06-10 plus one stack from 2025-06-11.

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/A7yBRppDTFaIWAFyGmBjsg/runs/0/artifacts/public/build/target.installer.exe

Could you please try this and let us know if it works?

I have been in discussion with our senior security engineer and he's interested to better understand a couple of things:

  • are you using oauth or basic authentication for the account that sends the mail?
  • is the mail server a major provider like Google/Microsoft or privately-hosted?

Thanks very much
toby

Flags: needinfo?(lilale2363)

Hi Toby,
unfortunately, this build also contains the bug.

To answer your questions:

The setup is very simple. Basic Authentication is used, and popular web-based email servers in Germany are contacted directly via IMAP and SMTP.
And most importantly, different providers are used.
So I can say that this is not a custom email server or an exotic setup, but a standard configuration using regular SMTP and IMAP ports.

dont hesitate to give me another EXE - no problem trying other builds ;-)

greetings

Flags: needinfo?(lilale2363)

Hi again,
Here's Francesco's suggested build:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JrmooAa4SOKTxCl1amyeew/runs/0/artifacts/public/build/target.installer.exe

This is c-c from 2025-06-10 built on top of m-c from 2025-06-10 plus the stack for patch D252470

Could you please test this?

Thanks for the information and help testing. If this still doesn't work.... ifthere's any way that we could get an installer of your software so we can test the way you do, it might be quicker.

bug is away ;-) congratulations!!

Well, that's mostly thanks to @Francesco and is only half the battle! Now we have to ask that the m-c bug be uplifted so our monthly and ESR versions can also get the fix.

Bob, could you please help us? Might it be possible to uplift bug 1967485 to release and ESR?

(Short history is that on 2025-04-04, this bug was introduced but we don't know what regressed us. It is fixed with your stack for bug 1967485)

Flags: needinfo?(bobowencode)
See Also: → 1967485
User Story: (updated)

thx to @Francesco and all others. hope didnt nerve you to much ;-)

i can test all builds you need to be testet to win the other half

Flags: needinfo?(ramona)
Flags: needinfo?(jerj)
Flags: needinfo?(austen)

It's great that we have identified the potential fix.

In the test build Toby had applied 5 patches, but patch #5 was later backed out from mozilla-central, so at this time we couldn't ask for it to be uplifted.

We must test whether the 4 other patches are sufficient to fix it.

And the test build was based on TB 142. We must very that the patches work on the 140 branch, too. (In theory, those patches could require other patches that have landed in 141 or later.)

Let's create a test build based on the TB 140 esr release branch, with those 4 patches applied. I'll work on that.

(In reply to Toby Pilling [:tobyp] from comment #105)

Bob, could you please help us? Might it be possible to uplift bug 1967485 to release and ESR?

Toby, the test build also included bug 1967046. We need to check whether that bug would need to get uplifted, too.

(In reply to Kai Engert [:KaiE:] from comment #108)

Let's create a test build based on the TB 140 esr release branch, with those 4 patches applied.

Could you please test this one and report if it works? Thanks in advance!
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/O4PHda47RmeImTyA15h4VQ/runs/1/artifacts/public/build/install/sea/target.installer.exe

(taken from https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=d7083cd2ba2ab8007f102d4e6033903c6f69cdcd )

Flags: needinfo?(lilale2363)

(In reply to Toby Pilling [:tobyp] from comment #105)

Well, that's mostly thanks to @Francesco and is only half the battle! Now we have to ask that the m-c bug be uplifted so our monthly and ESR versions can also get the fix.

Bob, could you please help us? Might it be possible to uplift bug 1967485 to release and ESR?

(Short history is that on 2025-04-04, this bug was introduced but we don't know what regressed us. It is fixed with your stack for bug 1967485)

Seems slightly odd that it would affect that, but sure.
Do you mean uplift to Thunderbird release and ESR?
I found this, is it still the process? (Some of the links 404.)

Flags: needinfo?(bobowencode) → needinfo?(toby)

Hi,
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/O4PHda47RmeImTyA15h4VQ/runs/1/artifacts/public/build/install/sea/target.installer.exe

that version is working - no bug!

next 10 hours im here in case you need me for fast testing!

Flags: needinfo?(lilale2363)

(In reply to JohnyBoy from comment #112)

that version is working - no bug!

Great, thanks a lot for confirming.

I will attach revisions that demonstrate what I have applied.
They are exactly the patches that landed into mozilla-central earlier, just applied to mozilla-esr140.

(In reply to Bob Owen (:bobowen) from comment #111)

Seems slightly odd that it would affect that, but sure.
Do you mean uplift to Thunderbird release and ESR?

Yes, and also to beta.

I found this, is it still the process? (Some of the links 404.)

I think you intended to include a link, but I don't see one.

(In reply to Toby Pilling [:tobyp] from comment #105)

Well, that's mostly thanks to @Francesco and is only half the battle! Now we have to ask that the m-c bug be uplifted so our monthly and ESR versions can also get the fix.

Bob, could you please help us? Might it be possible to uplift bug 1967485 to release and ESR?

(Short history is that on 2025-04-04, this bug was introduced but we don't know what regressed us. It is fixed with your stack for bug 1967485)

Seems slightly odd that it would affect that, but sure.
Do you mean uplift to Thunderbird release and ESR?
I found this, is it still the process? (Some of the links 404.)(In reply to Kai Engert [:KaiE:] from comment #114)

(In reply to Bob Owen (:bobowen) from comment #111)

Seems slightly odd that it would affect that, but sure.
Do you mean uplift to Thunderbird release and ESR?

Yes, and also to beta.

These changes are already in mozilla-beta, would that not automatically put them in comm-beta?

I found this, is it still the process? (Some of the links 404.)

I think you intended to include a link, but I don't see one.

I did indeed: https://developer.thunderbird.net/releases/uplifting-fixes

Flags: needinfo?(kaie)

Including patch from bug 1967046, would make the patches apply cleanly, by the way (I've tested release and esr140).

Hi Bob,
In order for Thunderbird ESR and Monthly releases to have those patches, they will need to be uplifted to mozilla-esr140 and mozilla-release, because that's what our build system pins to for our releases - we don't maintain a separate copy of the FF code within our repo.

And yes, if these changes are already in mozilla-beta, that would automatically put them in our beta.

Thanks for your help with this - if you need any support with the process, just let us know.

Flags: needinfo?(toby)
Flags: needinfo?(kaie)
See Also: → 1967046

(In reply to Toby Pilling [:tobyp] from comment #117)

Hi Bob,
In order for Thunderbird ESR and Monthly releases to have those patches, they will need to be uplifted to mozilla-esr140 and mozilla-release, because that's what our build system pins to for our releases - we don't maintain a separate copy of the FF code within our repo.

And yes, if these changes are already in mozilla-beta, that would automatically put them in our beta.

Thanks for your help with this - if you need any support with the process, just let us know.

I believe that this change will be merged into mozilla-release anyway on Monday (14/07/2025) as part of the Fx141 release candidate build.
It seems unlikely that they'll want to take a change that isn't driven by a Firefox dot release before that, but I can ask if that's not early enough?

esr140 should be a more straightforward request I think.

Flags: needinfo?(toby)
Assignee: nobody → kaie
Status: NEW → ASSIGNED
Attachment #9499443 - Flags: approval-mozilla-esr140?

This uses RunOnShutdown instead of ClearOnShutdown to clear statics, so we can
move future caching off main thread. This also means we can move the creation of
sLaunchErrors to be off main thread and lazy.

Attachment #9499444 - Flags: approval-mozilla-esr140?

We don't want to add these to the gecko directory service, because we don't want
them to be exposed generally.

Attachment #9499445 - Flags: approval-mozilla-esr140?
Attachment #9499446 - Flags: approval-mozilla-esr140?

Not sure if it's necessary or helpful, but as part of trying to applying those patches to mozilla-esr140 locally, and migrating myself to GIT for that work, I've submitted phabricator patches for mozilla-esr140.

(In reply to Bob Owen (:bobowen) from comment #116)

Including patch from bug 1967046, would make the patches apply cleanly, by the way (I've tested release and esr140).

Yes we included both bug 1967046 and bug 1967485 in our test, agree that we should uplift both.

(In reply to Kai Engert [:KaiE:] from comment #123)

Not sure if it's necessary or helpful, but as part of trying to applying those patches to mozilla-esr140 locally, and migrating myself to GIT for that work, I've submitted phabricator patches for mozilla-esr140.

I think it's normally done from the original landing unless rebased patches are needed, even then normally in the same bug.
I was just waiting to see if we needed to ask about release uplifts as well.

(In reply to Bob Owen (:bobowen) from comment #125)

I think it's normally done from the original landing unless rebased patches are needed, even then normally in the same bug.
I was just waiting to see if we needed to ask about release uplifts as well.

Thanks. I will mark those as abandoned. If helpful for rel-eng, they can still be found.

(In reply to Bob Owen (:bobowen) from comment #115)

I found this, is it still the process? (Some of the links 404.)

I think you intended to include a link, but I don't see one.

I did indeed: https://developer.thunderbird.net/releases/uplifting-fixes

Thanks, I see two 404, I will make our team aware.
I believe the only 404 are for the uplift criteria.

In our case here, there is no separate process necessary for Thunderbird, because the necessary fix is limited to changes in the Mozilla/Firefox repository. No code change to Thunderbird is necessary. That means we can automatically inherit the fix for TB 140.x ESR once the fix is committed to mozilla-esr140.

All that will be necessary on the Thunderbird side is to reference the more recent Firefox changeset that is used for building Thunderbird, but no action is necessary here, the TB release engineers will handle that when rebuilding.

Attachment #9499446 - Attachment is obsolete: true
Attachment #9499446 - Flags: approval-mozilla-esr140?
Attachment #9499445 - Attachment is obsolete: true
Attachment #9499445 - Flags: approval-mozilla-esr140?
Attachment #9499444 - Attachment is obsolete: true
Attachment #9499444 - Flags: approval-mozilla-esr140?
Attachment #9499443 - Attachment is obsolete: true
Attachment #9499443 - Flags: approval-mozilla-esr140?

(In reply to Bob Owen (:bobowen) from comment #118)

I believe that this change will be merged into mozilla-release anyway on Monday (14/07/2025) as part of the Fx141 release candidate build.
It seems unlikely that they'll want to take a change that isn't driven by a Firefox dot release before that, but I can ask if that's not early enough?

As I understand it, this will fix the future Thunderbird 141 monthly release.

Thunderbird publishes separate releases for version 140, the monthly 140 release and the ESR 140 release.

If the uplift were excluded from Firefox 140, then Thunderbird 140 monthly would remain unfixed, and users would be required to either skip the 140 monthly release and wait for 141, or decide to switch to the ESR update channel.

I think that might be acceptable.

For this issue, we're largely concerned about ESR and if we have to live with this broken on monthly 140 for another 2 weeks until 141 is available, it won't impact too many users.

Flags: needinfo?(toby)

(In reply to Toby Pilling [:tobyp] from comment #129)

I think that might be acceptable.

For this issue, we're largely concerned about ESR and if we have to live with this broken on monthly 140 for another 2 weeks until 141 is available, it won't impact too many users.

OK, I've done the esr140 request.
I've also asked in release-coordination, if it is at all possible to uplift to m-r140.

Release managers confirmed that uplifts to release would only be driven by an incident at this stage.
Uplift to esr140 is underway.

Fixed by uplifts to mozilla-esr140.(In reply to Kai Engert [:KaiE:] from comment #124)

(In reply to Bob Owen (:bobowen) from comment #116)

Including patch from bug 1967046, would make the patches apply cleanly, by the way (I've tested release and esr140).

Yes we included both bug 1967046 and bug 1967485 in our test, agree that we should uplift both.

Fixed in 140 by uplifts to mozilla-esr140.

Status: ASSIGNED → RESOLVED
Closed: 10 months ago
status-thunderbird_esr140: --- → fixed
Resolution: --- → FIXED

This should be fixed in: https://ftp.mozilla.org/pub/thunderbird/candidates/140.1.0esr-candidates/build1/

JohnyBoy, would you be able to give this candidate release a test by any chance?

Flags: needinfo?(lilale2363)

Hi Corey,
build is working - tested on 2 machines!

Flags: needinfo?(lilale2363)

(In reply to JohnyBoy from comment #134)

Hi Corey,
build is working - tested on 2 machines!

Excellent! Thank you again for all your help testing.

See Also: → 1977609
See Also: 1977609 →
tracking-thunderbird140: ? → ---
Whiteboard: [fixed by bug 1967485]
Target Milestone: --- → 142 Branch
See Also: → 1981185
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: