164550 - Collapsed folders at startup disable filters

Status: RESOLVED EXPIRED

(MailNews Core :: Filters, defect)

Description

[Thomas Pollinger]

I have an IMAP mail account with a depth of at most 4 - 5 subfolders.
Once filters are installed and working, quitting Mozilla and restarting the mail
agent collapses some of the folders (sometimes at depth 1, sometimes at depth
2). This makes the filter think that the subfolders are not available anymore
and thus get disabled. As a related bug (however less severe) is certainly the
fact that the tree state is not conserved accross sessions.

Manually reopen the closed folder on the treeview and activating the filter
again is a somewhat crude workaround as this can only be done once one fetch
finishes.

I have looked at a similar bug 115228 but this seems to be specifically
targetted for POP mail accounts.

I am not sure whether the IMAP server behaves somewhat incorrectly - however
manually expanding/collapsing the tree view seems to be working ok.

I am using Cyrus IMAP version: Cyrus IMAP4 v 2.0.16
The server is Debian Linux, Kernel 2.4.17
The client is on Windows XP, Mozilla nightly build ID: 2002082404

It is possible that the bug has been longer around as I have used server side
filtering so far and switched to client side to see which folders have new mail.

Comment 1

[laurel]

Worksforme with 08-23 commercial branch Win98, using Netscape server, IMAP
account filtering to a 5th level subfolder on that same account when I've exited
and restarted and folders are collapsed at first level.  Will try again with
trunk...

Comment 2

[Thomas Pollinger]

I have downloaded and use now the release build 1.1 for win32 and see the same
behaviour.
Don't know whether this makes any difference, however I have enabled checking
for mail at startup.

Comment 3

[Olav Seyfarth]

Attachment: close+open account doesn't restore folder state

In step 1, click on account to close it: OK.
In step 2, click on account to reopen it: shortly displayed correctly, the
subfolders close (as soon as server reply is complete).
In step 3, click on incorrectly as "open" displayed level2-handle: not-open
subfolders are "closing".
In step 4, click on same handle to "reopen" subfolder list: again, levels 3 to
5 are displayed correctly and then disappear - leaving a "complete" subfolder
list terminated at level 4.
In step 5, click on "last" level 3 handle: subfolder list closes.
In step 6, click on same handle to reopen list: revealing the whole folder list
as shown in step 1.
If the list was deeper, one would have to continue closing and reopening all
subfolders on all levels >2, I tested this also.

Comment 4

[Olav Seyfarth]

further details on comment #3:
- loosing the filters seems to be a consequence of an underlying IMAP problem:
not recursively loading the whole folder subtree.
- might be server /server configuration dependent.
- restarting mozilla results in exactly the same as close+open account.
- we verified this with windows 95, NT, 2000 and XPpro
- tested with at least Mozilla 1.0.1 and 1.1 in depth
- with and without german language pack
- never seen under linux

Comment 5

[Olav Seyfarth]

Tested again with mozilla 1.3a: MY problem is SOLVED, folder state is restored
correctly - thank you all.

Comment 6

[Olav Seyfarth]

Comment #5 isn't exactly true: the default IMAP setting is "subscribed folders
only: YES" - once changing that to "NO" (in order to notice new folders on
shared accounts) we get back the behaviour described in comment #3. Sorry for
the confusion :-(

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 9

[Olav Seyfarth]

I cannot reproduce the bug using TB 1.0.7 so I leave it resolved.