2065428 - Thunderbird 154 x64 Gmail IMAP sync/download failures; same release works with x86 on identical Windows system

Status: UNCONFIRMED

(MailNews Core :: Networking: IMAP, defect)

Description

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36

Steps to reproduce:
(from comment 1)

1. Platform. Win11, Thunderbird 154.0 x64
2. Gmail IMAP account
3. When clicking on a folder or message, long delays, then: "Authentication failure while connecting to server"

Investigation of a recurring Gmail IMAP connection/synchronization failure in Thunderbird on Windows 11.

Observed with Thunderbird 154.0 x64 using a Gmail account over IMAP (imap.gmail.com:993) with OAuth2/XOAUTH2 authentication causing failure to sync folders and download messages. Troubleshooting to determine whether the problem was related to Thunderbird configuration, the Gmail account, authentication, Windows, or the network.

Tests included:

• Thunderbird 151/154.0 x64.
• Thunderbird 151/154.0 32-bit (x86).
• Fresh Thunderbird profile
• Thunderbird Troubleshoot Mode (no effect)
• Verification that Thunderbird was not in Work Offline mode.
• Verification that Services.io.offline was false.
• Wi-Fi and a mobile-phone hotspot.
• Windows DNS resolution: Resolve-DnsName imap.gmail.com
• Windows TCP connectivity: Test-NetConnection imap.gmail.com -Port 993
• Direct IMAPS testing with curl.
• Manual IMAP testing using OpenSSL. Manual IMAP CAPABILITY testing.
• Verification that Gmail advertises AUTH=XOAUTH2.
• Investigation of Gmail IMAP folder/subscription settings.
• Firewall/antivirus and Windows network configuration checks.
• Thunderbird Necko/socket logging with:
  MOZ_LOG=timestamp,nsSocketTransport:5,nsHostResolver:5,necko:5
  The basic network connection to Gmail was verified independently of Thunderbird. For example, Test-NetConnection successfully established TCP connectivity to imap.gmail.com:993.
  curl successfully established an IMAPS connection and received:

• OK Gimap ready for requests ...
  An interactive IMAP session also successfully received Gmail's CAPABILITY response, including:
  AUTH=XOAUTH2

The most important test was ultimately an architecture comparison on the same Windows installation and physical machine. I installed Thunderbird 151.0 32-bit and subsequently allowed it to reach 154.0 32-bit before I had completely disabled automatic updating. Thunderbird 154.0 x86 is now working normally on this system.

The same Thunderbird release in x64 previously exhibited the problem.

Both were tested against the same Gmail account on the same Windows installation and machine.

Actual results:

With Thunderbird 154.0 x64, Gmail IMAP connections repeatedly failed during ordinary mail operations.

The failures were not limited to initial account authentication. Thunderbird could establish an IMAP connection and communicate with Gmail, but subsequently connections would disappear during normal operations.

Examples included:

Folder message listings failing to load.
Switching between folders causing connection/authentication errors.
Clicking an indexed message and having the message download fail.
Synchronization of folder indexes failing.
Thunderbird repeatedly displaying:

"Authentication failure while connecting to server"

The problem persisted with a fresh profile and in Troubleshoot Mode.

It also occurred over both Wi-Fi and a mobile-phone hotspot.

This made a simple local Wi-Fi problem unlikely.

The independent Windows and IMAP tests showed that the machine could successfully reach Gmail on TCP port 993 and establish an IMAPS connection. Manual IMAP interaction also worked.

The Thunderbird network log from the failing x64 build showed socket activity including:

nsSocketTransport::SendStatus ... status=4b0005

followed shortly afterward by:

nsSocketTransport::Close ... reason=80004004

and then during socket detachment:

nsSocketInputStream::OnSocketReady ... cond=804b0010

The relevant sequence was approximately:

PR_Write returned [n=17]
nsSocketTransport::SendStatus ... status=4b0005
...
nsSocketTransport::Close ... reason=80004004
...
nsSocketInputStream::CloseWithStatus ... reason=80004004
...
nsSocketTransport::OnMsgInputClosed ... reason=80004004
...
nsSocketTransportService::DetachSocket
...
nsSocketTransport::OnSocketDetached ... cond=0
nsSocketInputStream::OnSocketReady ... cond=804b0010

My understanding of these values is:

0x4B0005 = STATUS_SENDING_TO
0x80004004 = NS_ERROR_ABORT
0x804B0010 = NS_ERROR_OFFLINE

The 0x4B0005 event appears to be normal socket status reporting rather than the actual failure.

The more interesting event is that the socket is explicitly closed with 0x80004004 (NS_ERROR_ABORT). The subsequent 0x804B0010 (NS_ERROR_OFFLINE) appears during socket detachment.

The IMAP log then showed the authentication operation failing because the underlying socket had disappeared. For example:

IMAP auth: server caps ...
Trying auth method 0x800000000
XOAUTH2 auth
SendData ...
ReadNextLine [rv=0x804b000e ...]
clearing IMAP_CONNECTION_IS_OPEN
TellThreadToDie: close socket connection
SetConnectionStatus(0x804b000e)
authlogin failed
Marking auth method ... failed

This suggests that Thunderbird's UI message saying "Authentication failure" may be a secondary symptom of the underlying socket failure rather than an actual Gmail authentication rejection.

I also verified that the account could successfully communicate with Gmail's IMAP server outside Thunderbird, and the same account subsequently worked normally with Thunderbird 154 x86.

The decisive observation is therefore that Thunderbird 154 x86 works on the same system where Thunderbird 154 x64 fails.

The x86 version provides normal behavior:

Folder synchronization is responsive.
Folder message listings load.
Messages download successfully.
Normal IMAP operations work.
No corresponding recurring authentication/socket failures have been observed.

I have therefore stopped trying to debug the underlying Windows/Necko cause myself. I am reporting the architecture-dependent behavior because it may indicate a Thunderbird/Necko/NSS/Windows x64 issue.

Expected results:

Thunderbird 154.0 x64 should behave like Thunderbird 154.0 x86 on the same Windows installation and hardware, and Gmail IMAP account.

After successfully connecting to Gmail's IMAP server and authenticating using OAuth2/XOAUTH2, Thunderbird should maintain the IMAP connection and successfully perform normal operations such as:

• Synchronizing folder indexes.
• Loading folder message listings.
• Selecting folders
• Downloading message bodies.
• Synchronizing messages.
• Maintaining/re-establishing IMAP connections when necessary.
  In particular, an underlying socket termination should not result in Thunderbird misleadingly reporting an authentication failure if Gmail has not actually rejected the authentication.

The expected behavior is demonstrated by Thunderbird 154.0 x86 on the same machine, where the Gmail account operates normally.

I am reporting this primarily because the x86/x64 difference is reproducible and potentially significant, even though I have not determined the underlying cause of the socket termination.

I can provide sanitized Thunderbird Necko/network logs and additional environment information if useful.

Comment 1

[Rama Hoetzlein]

(In reply to Rama Hoetzlein from comment #0)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36

Steps to reproduce:

1. Platform. Win11, Thunderbird 154.0 x64
2. Gmail IMAP account
3. When clicking on a folder or message, long delays, then: "Authentication failure while connecting to server"

Investigation of a recurring Gmail IMAP connection/synchronization failure in Thunderbird on Windows 11. Observed with Thunderbird 154.0 x64 using a Gmail account over IMAP (imap.gmail.com:993) with OAuth2/XOAUTH2 authentication causing failure to sync folders and download messages. Troubleshooting to determine whether the problem was related to Thunderbird configuration, the Gmail account, authentication, Windows, or the network.

Tests included:

• Thunderbird 151/154.0 x64.
• Thunderbird 151/154.0 32-bit (x86).
• Fresh Thunderbird profiles
• Thunderbird Troubleshoot Mode (no effect)
• Verification that Thunderbird was not in Work Offline mode.
• Verification that Services.io.offline was false.
• Wi-Fi and a mobile-phone hotspot.
• Windows DNS resolution OK: Resolve-DnsName imap.gmail.com
• Windows TCP connectivity OK: Test-NetConnection imap.gmail.com -Port 993
• Direct IMAPS testing with curl OK.
• Manual IMAP testing using OpenSSL. Manual IMAP CAPABILITY testing. OK.
• Verification that Gmail advertises AUTH=XOAUTH2. OK
• Investigation of Gmail IMAP folder/subscription settings.
• Firewall/antivirus and Windows network configuration checks. OK
• Thunderbird Necko/socket logging with:
  MOZ_LOG=timestamp,nsSocketTransport:5,nsHostResolver:5,necko:5
  The basic network connection to Gmail was verified independently of Thunderbird. For example, Test-NetConnection successfully established TCP connectivity to imap.gmail.com:993.
  curl successfully established an IMAPS connection and received:

• OK Gimap ready for requests ...
  An interactive IMAP session also successfully received Gmail's CAPABILITY response, including:
  AUTH=XOAUTH2

The most important test was ultimately an architecture comparison on the same Windows installation and physical machine. I installed Thunderbird 151.0 32-bit and subsequently allowed it to reach 154.0 32-bit before I had completely disabled automatic updating. Thunderbird 154.0 x86 is now working normally on this system.

The same Thunderbird release 154.0 in x64 previously exhibited the problem.

Both were tested against the same Gmail account on the same Windows installation and machine.

Actual Results:

With Thunderbird 154.0 x64, Gmail IMAP connections repeatedly failed during ordinary mail operations.
The failures were not limited to initial account authentication. Does not appear to be caused by PKCE (introduced in Thunderbird 152) as the issue was also found/tested in Thunderbird 151.0 x64. I could establish an IMAP connection and communicate with Gmail, but subsequently connections would disappear during normal operations.

Examples included:

• Folder message listings failing to load.
• Switching between folders causing connection/authentication errors.
• Clicking an indexed message and having the message download fail.
• Synchronization of folder indexes failing.
• Thunderbird repeatedly displaying: "Authentication failure while connecting to server"

The problem persisted with a fresh profile and in Troubleshoot Mode.
It also occurred over both Wi-Fi and a mobile-phone hotspot.
This made a simple local Wi-Fi problem unlikely. The independent Windows and IMAP tests showed that the machine could successfully reach Gmail on TCP port 993 and establish an IMAPS connection. Manual IMAP interaction also worked.

The Thunderbird network log from the failing x64 build showed socket activity including:
nsSocketTransport::SendStatus ... status=4b0005
followed shortly afterward by:
nsSocketTransport::Close ... reason=80004004
and then during socket detachment:
nsSocketInputStream::OnSocketReady ... cond=804b0010

The relevant sequence was approximately:
PR_Write returned [n=17]
nsSocketTransport::SendStatus ... status=4b0005
...
nsSocketTransport::Close ... reason=80004004
...
nsSocketInputStream::CloseWithStatus ... reason=80004004
...
nsSocketTransport::OnMsgInputClosed ... reason=80004004
...
nsSocketTransportService::DetachSocket
...
nsSocketTransport::OnSocketDetached ... cond=0
nsSocketInputStream::OnSocketReady ... cond=804b0010

My understanding of these values is:
0x4B0005 = STATUS_SENDING_TO
0x80004004 = NS_ERROR_ABORT
0x804B0010 = NS_ERROR_OFFLINE

The 0x4B0005 event appears to be normal socket status reporting rather than the actual failure.

The more interesting event is that the socket is explicitly closed with 0x80004004 (NS_ERROR_ABORT). The subsequent 0x804B0010 (NS_ERROR_OFFLINE) appears during socket detachment.

The IMAP log then showed the authentication operation failing because the underlying socket had disappeared. For example:

IMAP auth: server caps ...
Trying auth method 0x800000000
XOAUTH2 auth
SendData ...
ReadNextLine [rv=0x804b000e ...]
clearing IMAP_CONNECTION_IS_OPEN
TellThreadToDie: close socket connection
SetConnectionStatus(0x804b000e)
authlogin failed
Marking auth method ... failed

This suggests that Thunderbird's UI message saying "Authentication failure" may be a secondary symptom of the underlying socket failure rather than an actual Gmail authentication rejection.

I also verified that the account could successfully communicate with Gmail's IMAP server outside Thunderbird, and the same account subsequently worked normally with Thunderbird 154 x86.

The decisive observation is therefore that Thunderbird 154 x86 works on the same system where Thunderbird 154 x64 fails.

The x86 version provides normal behavior:

Folder synchronization is responsive.
Folder message listings load.
Messages download successfully.
Normal IMAP operations work.
No corresponding recurring authentication/socket failures have been observed.

I have therefore stopped trying to debug the underlying Windows/Necko cause myself. I am reporting the architecture-dependent behavior because it may indicate a Thunderbird/Necko/NSS/Windows x64 issue.

Expected results:

Thunderbird 154.0 x64 should behave like Thunderbird 154.0 x86 on the same Windows installation and hardware, and Gmail IMAP account.

After successfully connecting to Gmail's IMAP server and authenticating using OAuth2/XOAUTH2, Thunderbird should maintain the IMAP connection and successfully perform normal operations such as:

• Synchronizing folder indexes.
• Loading folder message listings.
• Selecting folders
• Downloading message bodies.
• Synchronizing messages.
• Maintaining/re-establishing IMAP connections when necessary.
  In particular, an underlying socket termination should not result in Thunderbird misleadingly reporting an authentication failure if Gmail has not actually rejected the authentication.

The expected behavior is demonstrated by Thunderbird 154.0 x86 on the same machine, where the Gmail account operates normally.

I am reporting this primarily because the x86/x64 difference is reproducible and potentially significant, even though I have not determined the underlying cause of the socket termination.

I can provide sanitized Thunderbird Necko/network logs and additional environment information if useful.

Comment 2

[Wayne Mery (:wsmwk)]

This may be the same as Bug 2063816 which is filed against version 153 - Gmail IMAP unusable with Thunderbird 153 ESR: intermittently but very frequently gives authentication errors and messages not loading. “Authentication failure while connecting to server imap.gmail.com.”

Rama, does it look to be the same to you?

Comment 3

[Rama Hoetzlein]

@Wayne Mery
Yes, it looks like the same as Bug 2063816. The symptoms are identical. Including that message downloads willl sometimes but rarely succeed. Most often, a long delay, then message "Authentication failure..". Other aspects, such as reinstalling, rebooting and Troubleshooting mode all not helping are consistent with that bug.

Comment 4

[Rama Hoetzlein]

Attachment: thunderbird-net-trace.log

I have attached a net/core trace to this bug.

This trace was created on Win11 64-bit Thunderbird using:

set MOZ_LOG=timestamp,nsSocketTransport:5,nsHostResolver:5,necko:5,nspr:5
set MOZ_LOG_FILE=%USERPROFILE%\Desktop\thunderbird-net-fresh.log
del %USERPROFILE%\Desktop\thunderbird-net-fresh.log
"C:\Program Files\Mozilla Thunderbird\thunderbird.exe"

Someone with deeper knowledge of net/core can search this log for the error code 80004004 (NS_ERROR_ABORT) and the cause should be prior to that. The socket is dropped at some point, which causes errors up the stack resulting in "Authentication failure" UI message (OAuth is not necessarily the reason).

Comment 5

[Rama Hoetzlein]

It is also useful to trace the IMAP layer, using the following:

set NSPR_LOG_MODULES=timestamp,IMAP:5
set NSPR_LOG_FILE=%USERPROFILE%\Desktop\thunderbird-imap-fresh.log
"C:\Program Files\Mozilla Thunderbird\thunderbird.exe"

Although I don't have a saved log for that.

Comment 6

[Max Emig [:maxe]]

I do not believe x86 vs AMD64 makes any difference here, must have been some kind of coincidence.