1779543 - TB 102.0.2 doesn't refresh IMAP inbox - TB tries to create a folder which is already present and has been discovered during folder enumeration

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: IMAP, defect)

Description

[Chris Zim]

Steps to reproduce:

Tried to access an IMAP inbox

Actual results:

TB cannot access a SSL/TLS protected IMAP Inbox (mail server logs only show connect / disconnect attempts).

OS is OSX 12.4 with a universal binary.

Issue cannot be reproduced on SM 2.52.13 (x86_64 binary).

Expected results:

Messages are downloaded from IMAP server

Comment 1

[Chris Zim]

Please let me know if more info is required.

Comment 2

[Chris Zim]

Seems to be an UI issue as I encountered the following behaviour upon further investigation of this issue: Upon start if the Inbox folder is selected TB tries to refresh the inbox w/o showing any messages. If you click on a different folder than the Inbox, the contents of the folder is displayed OK. Going back to the Inbox, all messages based on the actual state of this folder are displayed and any busy indicators such as the spinning disk attached to the cursor (on OSX) or the swinging dot on the folder name are gone.

Comment 3

[Magnus Melin [:mkmelin]]

Please provide an IMAP log - https://wiki.mozilla.org/MailNews:Logging

Comment 4

[Chris Zim]

IMAP log per instructions supplied above can be found at https://gist.github.com/a1c2ebb0d846aec3fb39586384c04785 .

Please note due to security reasons folder names and other sensitvite information have been removed from this log and server names have been changed. The server in question is server2.com.

Please let me know if further information is required.

Comment 5

[Magnus Melin [:mkmelin]]

The relevant part is probably:

27 create "INBOX.Trash"
27 NO Cannot create this folder.
URL failed with code 0x80550021 (imap://[e-mail]:993/discoverallboxes)

Comment 6

[Chris Zim]

The problem is of course that TB tries to create a folder which is already present and has been discovered during folder enumeration (like the other IMAP folders).

(Apparently not all redactions were successful :-)

Where the SM code handles this correctly by not trying to create these folders after the enumeration as the following log snippet shows:

2022-07-15 13:19:41.001950 UTC - [Unnamed thread 0x145b5cc70]: I/IMAP 0x14600a000:server2.com:A:CreateNewLineFromSocket: * LIST (\HasNoChildren) "." "INBOX.Trash"
2022-07-15 13:19:41.062005 UTC - [Unnamed thread 0x145b5cc70]: I/IMAP 0x14600a000:server2.com:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "." "INBOX.Trash"

Comment 7

[Chris Zim]

So far, I've been only able to reproduce this on OSX 12.4 (a Win10 installation with the same version works).

Comment 8

[Wayne Mery (:wsmwk)]

Please update to 102.0.3 and report your results.
Thanks

Comment 9

[Chris Zim]

Issue still persists but the work-around still funcctions.

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to Chris Zim from comment #9)

Issue still persists but the work-around still funcctions.

you mean switching folders?

Comment 11

[Chris Zim]

Cf. comment #2.

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to Chris Zim from comment #11)

Cf. comment #2.

Yes, I had read that. I want to confirm that my interpretation, "switching folders", precisely matches your comment 2.

Comment 13

[Chris Zim]

Issue still present after update to 102.1.2.

Comment 14

[Wayne Mery (:wsmwk)]

Reporter, do you still see this issue when using the latest version?
What information can you add to clarify the steps to reproduce this issue?

Comment 15

[Chris Zim]

Can be closed as this issue is not reproducible with TB 102.9.1.

Comment 16

[Wayne Mery (:wsmwk)]

Thanks for the update