User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 I have an IMAP account which is heavily folder structured. By this I mean that it contains lots of sub folders under lots of levels. Normally, when the mail client starts up it shows a collapsed view the main folder. What I normally have to do to view the subfolders I want to see is to expand, collapse, expand the parent folder (or the parent of the parent folder). Apparently, this triggers some sort of look for folders event. Basically tweaking around with expand and collapse icons here and there seem to get what i need. When it works, I can see the folders being populated on the screen. The bug is when it stops when i know there are alot moreHowever, it seems to show a certain number of folders and then stops. In one case(repeatable), it populates a subfolder with 5 mailfolders(folders containing mail) when there are actually 30+ mailfolders. But the case seems to be more related to the amount of folders instead of the actual level. Initially, I had 300+ folders with 4 levels and things seemed to be fine (although it was really tiresome having to collapse, and re-expand the folders everytime i restarted the mail client) but now that i have atleast 1000+ subfolders with 4 levels. I've created a small java mail client and I can see them, but not in the mozilla mail client. Also, all these folders exist on the server. The problem doesn't seem to exist on local folders. On the IMAP advanced settings, i have the 'Show only subscribed folders' setting *unchecked*. and the 'Server supports folders that contain sub-folders and messages' unchecked. Reproducible: Always Steps to Reproduce: 1. Create the folder structure with large amounts of entries. NB: You'll need to create this under a IMAP server somewhere else and NOT in mozilla. The following linux command line can be used to to create mailfolders (not subfolders). For sub folders, just use mkdir i=0; while [ $i -lt 800 ]; do touch "file$i"; let i=$i+1; done The folder structure should look a little like this: -INBOX |- subfolder01 |- subfolder02 |- subfolder01.01 |- mailFolder001 |- mailFolder002 . . . |- mailFolder800 2. Change the IMAP settings Make sure the following is set in the Advanced IMAP Server settings 'Show only subscribed folders' = unchecked 'Server supports folders that contain subfolders and messages' = checked IMAP server directory = INBOX (this is what's setup on mine, but will obviously depend on the where you create your folders in step 1) Make sure you reset mozilla for the changes to take effect. 3. start the mozilla mail client 4. If the the subfolders haven't appeared, collapse the inbox folder and then expand it. 5. try to expand all the folders. Actual Results: it stopped expanding after it reached mailFolder350. Expected Results: Should have shown all 800 mail folders
I can confirm this problem on Mozilla clients up to v1.4a running on both Linux and Windows. While this bug may not seem severe by itself it does become VERY important when you have filters for subfolders that do not expand. - Inbox |-People |- Bob |- Andy |- George For example, if you have filters to put emails from Bob and Andy into the Bob and Andy folders, those filters will fail and be disabled because only People has expanded. This is especially true when loading mail for the first time. Only the People folder exists (like below) - Inbox |-People while the subfolders within People are not shown so the filters will fail. You must then manually re-enable filters and then re-run the filters on the inbox. This can be very time consuming if you have a lot of filters and a lot of email from various people sitting in your inbox. I have found that by opening and closing the Inbox sometimes will open sub folders it doesn't always seem to be the case. In a directory structure like - Inbox |- Work |- People |- Bob |- Andy closing the Work folder and re-opening it will ALWAYS display the subfolders within People.
It *appears* that this bug is the result of when Mozilla expands the folder treef or the first time. The BEST way to reproduce this over and over is to simply collapse the root tree and expand it again. Mozilla will say at the bottom "Looking for folders" and only second level folders will expand. This is especially true if you already have all the folders expanded and you collapse and expand the tree again. Only folders up to the second level will be displayed. In fact I have noticed that when starting up Mozilla that it will correctly have the folders expanded from when I last shut it down. Then it must do an init of some sort and you see the message "Looking for folders" presumably to make sure that no folders were added or deleted since last time and then it incorrectly collapes the expaned folders.
I have the same problem: Mozilla 1.4/WinXP never seems to find 3rd level folders* at startup, so the message filters pointing to those directories are a) not run and b) deactivated, which is VERY ANNOYING. Filters to 1st and 2nd level work fine. Maybe connected to bug 111256 et al.? *folder structure - Inbox |-Work (1st level) |-project 1 (2nd level) |-admin (3rd level - filters don't see this)
Product: Core → MailNews Core
Confirm this bug with Seamonkey 2.17 on Linux Ubuntu 12.04.2 LTS with kernel 3.2.0-39 At the startup all the subfolders are show correctly. After a while some of them disappear. Opening a closing two level up parent folder many times I always got some subfolders disappear. See attachment with down arrow but without subfolders.
Created attachment 734859 [details] opening & closing parent folder, always made disappear some subfolders
two other hints: - only opened subfolders disappear - folding and defolding the subfolder, doesn't resolve the problem. The arrow change orientation, but no subfolder appear
> only opened subfolders disappear are always the same subfolder in different sessions. Some opened subfolder are not affected, I do not understand the criteria.
You need to log in before you can comment on or make changes to this bug.