220375 - IMAP subfolders do not display, but do show up in subscribe list.

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Andrew Brady]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030917
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030917

Ref: http://bugzilla.mozilla.org/show_bug.cgi?id=199155 which was "resolved".

In courier imap when using subfolders the initial view is of just
the inbox. Only when the folder view is collapsed and expanded do
the subfolders appear.

This is back again in 1.5rc1. It was fixed in one of the 1.5b SNAPSHOTS.

courier.00143-mclient.36793: 2 OK LOGIN Ok.
mclient.36793-courier.00143: 3 lsub "" "INBOX./*"
courier.00143-mclient.36793: 3 OK LSUB completed
mclient.36793-courier.00143: 4 list "" "INBOX"
courier.00143-mclient.36793: * LIST (\Marked \HasChildren) "." "INBOX"
4 OK LIST completed

Trace from when mozilla first connects to the IMAP:

courier.00143-mclient.
courier.00143-mclient.36793: 2 OK LOGIN Ok.
mclient.36793-courier.00143: 3 lsub "" "INBOX./*"
courier.00143-mclient.36793: 3 OK LSUB completed
mclient.36793-courier.00143: 4 list "" "INBOX"
courier.00143-mclient.36793: * LIST (\Marked \HasChildren) "." "INBOX"
4 OK LIST completed

Trace from when the folder is collapsed and expanded:

courier.00143-mclient.36794: 1 OK LOGIN Ok.
mclient.36794-courier.00143: 2 lsub "" "INBOX.*"
courier.00143-mclient.36794:* LSUB (\HasNoChildren) "." "INBOX.Trash"
2 OK LSUB completed
mclient.36794-courier.00143: 3 list "" "INBOX"
courier.00143-mclient.36794: * LIST (\Marked \HasChildren) "." "INBOX"
3 OK LIST completed36794: 1 OK LOGIN Ok.
mclient.36794-courier.00143: 2 lsub "" "INBOX.*"
courier.00143-mclient.36794:* LSUB (\HasNoChildren) "." "INBOX.Trash"
2 OK LSUB completed
mclient.36794-courier.00143: 3 list "" "INBOX"
courier.00143-mclient.36794: * LIST (\Marked \HasChildren) "." "INBOX"
3 OK LIST completed

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Larry Fields]

Is this the same as http://bugzilla.mozilla.org/show_bug.cgi?id=219498 ?

Comment 2

[David :Bienvenu]

does this work in 1.6a?

Comment 3

[Andrew Brady]

No. I don't think so. AFAI can tell the problem relates to the difference in the
way that Mozilla lsubs's to the Inbox. In the first case when the connection is
first made Mozilla does (note the fwd slash):

  3 lsub "" "INBOX./*"

and the courier imap (in my case) replies with:

  * LIST (\Marked \HasChildren) "." "INBOX"

When the folders are expanded and collapsed, Mozilla does (note no slash this time):

  2 lsub "" "INBOX.*"

and the imap replies that the folder Inbox has children:

  * LSUB (\HasNoChildren) "." "INBOX.Trash"

Then everything works ok.

Comment 4

[Andrew Brady]

Will test in 1.6a.

Comment 5

[David :Bienvenu]

Andrew, I now doubt it's fixed in 1.6a. Do you still have the online directory
set "INBOX." and are you allowing the server to override the namespaces?

Comment 6

[Andrew Brady]

It works ok in 1.6a.

Yes. I have the online directory set to "INBOX." and the server *can* override
the namespaces.

Strange. It didn't work in 1.4. Was corrected and worked in 1.5a. But did
not work in 1.5 release. Now it works in 1.6a. Will it continue to work in
the 1.6 release?

Andy

Comment 7

[David :Bienvenu]

Andrew, for you, probably. But you can pull a nightly build to make sure. I did
make one change to this code for bug 219645 that is NOT in 1.6a, but is in the
nightly builds.

Comment 8

[Andrew Brady]

Ok in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031110

Comment 9

[David :Bienvenu]

Attachment: proposed fix

this patch makes it so the subscribe UI doesn't remember the expand/collapse
state of the folders since the last time you used it. That fixes this problem.
The subscribe UI wasn't designed to work with the expand/collapsed state
remembered, but it was getting remembered anyway, leading to all sorts of
problems.

Comment 10

[David :Bienvenu]

fix checked in, will be in tomorrow's build (and the first 1.6b candidate build)

Comment 11

[David :Bienvenu]

*** Bug 136749 has been marked as a duplicate of this bug. ***