Closed Bug 138759 Opened 22 years ago Closed 19 years ago

Deeply nested IMAP folders aren't seen by Mozilla until parent gets folded and unfolded


(MailNews Core :: Networking: IMAP, defect)

Not set


(Not tracked)



(Reporter: aleksander.adamowski, Assigned: mscott)


(Blocks 1 open bug)



(4 files)

Reproducible on: Linux trunk build 2002041921. Not reproducible on same win32
trunk build.

After an upgrade of our IMAP server from Netscape Messaging Server {some older
version} to Netscape Messaging Server 4.15 Patch 7 (built Sep 12 2001) some
metadata on the IMAP server was lost (e.g. e-mail marked as read were all marked
as new again).

I happen to have a structure of deeply nested folders (4 levels) on that server.
Level 4 subfolders on an IMAP server aren't seen by MailNews immediately after
startup and only their parents are visible.
Level 0 being the root account folder, level 1 - Inbox, Sent etc...
See attached screenshot of my folder structure.

I've tried removing localstore.rdf, XUL.mfasl, also tried removing the IMAP
account, involved entries in prefs.js (the ones starting with
"mail.server.serverX") and then re-adding the IMAP account, but the same
subfolders still aren't seen by Mozilla after MailNews startup.

Starting with a new profile, adding the IMAP account, everything works fine.

I suspect that there's some file in the profile directory that caches IMAP
folder structure and it isn't properly refreshed, I'd appreciate hints about
which file would that be. If I find that file, I'll attach it to this bug.

I'm attaching a screenshot showing my full folder structure in IMAP and an image
illustrating the whole process.
This file is 160 KB big!
Comment on attachment 80176 [details]
My folder structure on IMAP server

Green arrows show the folders whose subfolders aren't initially visible
Confirm for mozilla 0.9.9-4 on Debian woody/i386, and also's rc1 on same.
Same as original description _except_ problem still ocurrs with a clean new
account. IMAP server is MDaemon 3 for Windows NT.
Confirm for Mozilla 1.0R1, 1.0R2, 1.0R3, and 1.1alpha on Windows 2000. IMAP
server is Cyrus. Also confirm that problem still ocurrs with a clean new account.
Confirmed for Moz 1.1 on Win2k, using UW-IMAP server on Linux with host folder
set to ~/mail. The mbox file ~/mail/Lists/RPM is visible (as Lists/RPM in the
Moz tree view), and the gray directory ~/mail/Lists/Mail is visible, but the
mbox files within the latter directory are not, and no "+" is visible next to
the Mail subdirectory to expand it.
Just build Moz from CVS on Red Hat 7.3, and found that I could enter a mailbox
as a URL:


Entering this URL, I get a popup asking me if I want to subscribe to
~ken/UW-IMAP. So it looks like maybe the folders are getting collapsed to a
single level somewhere.
QA Contact: huang → gchan
Also happens with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.2.1) Gecko/20021130

One consequence is that mail filters attempting to move messages to a deep
folder fail on startup. Workaround is to switch off "Check for new mail at
startup", then collapse and reopen the folder hierarchy involved before clicking
Get Msgs.
I think bug #167107, bug #144103, bug #131938 and bug #121104 are all duplicates
of this bug.
*** Bug 167107 has been marked as a duplicate of this bug. ***
*** Bug 144103 has been marked as a duplicate of this bug. ***
*** Bug 121104 has been marked as a duplicate of this bug. ***
*** Bug 131938 has been marked as a duplicate of this bug. ***
My comments on bug 121104 still apply.
It seems unrelated to a particular server - UW-IMAP, Cyrus-IMAP and Courier-IMAP
sightings were reported in the dupes.
Flags: blocking1.4a?
Aleksander, I propose marking this as Major severity because of two reasons:

1. the loss of functionality in the Message Filters. If I reconnect to the IMAP
server then message filters that send messages to folders 3 or more levels deep
get (very helpfully) turned off. Then I have to go through the whole Message
Filter dialog to re-enable them (which annoyingly returns me to the top of the
list of the filters every time I re-enable one).

2. saved messages, when downloaded offline, are discarded by the Moz Mail
browser for the folders it's "forgotten about" (again, three or more levels
deep). For archive-style folders with hundreds or thousands of messages, this is
a BIG hassle; after "reminding" Moz Mail about the deep folders, the messages
have to be re-downloaded. And there's no workaround for this.

Please also change Hardware and OS to all, as were the case on the "duplicates"
of this bug. I can certainly confirm this on Windows/PC.
OS: Linux → All
Hardware: PC → All
What is described here (bug 138759) *does* appear to be same as bug 167107.  

In bug 167107 I reported that the problem was happening against two IMAP systems
and running on i686-based servers ... the Mozilla is also on a i686-based server.

   a) Red Hat 6.0 with kernel 2.2.5-15 and considerable updates (notably glibc
1.2.3-1). UW IMAP ver 4.5 release 3 from Red Hat supplied RPM imap-4.5-3

   b) Red Hat 8.0 with kernel 2.4.18-18.8.0 and all but the latest updates via
RH up2date. UW IMAP vers 2001a release 15 from Red Hat supplied RPMs (from RH
install CD). 

   Mozilla 1.2.1 (Xft build) from Mozilla RPMs
   Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202

Only the RH8 machine is still in service now.  We continue to have the problem
and it continues to cause serious extra work for us.

Also, when we manually resubscribe (to pick up the mailboxes that coworkers
created) it is a tremendously tedious process to make all those mailboxes
visible in the subscribe dialog (over 1000 mailboxes nested to 8 levels) -- and
takes over an HOUR PER USER to do this. 

Furthermore after doing that subscribing, it seems that *all* the
mailboxes/messages are set to unread.

I sure hope that this will be taken care of soon -- it is a huge pain and a
tremendous productivity killer.

Ok, I support this.

BTW, for me the bug is only exhibited if I have "Show only subscribed folders"
in account's advanced options disabled.

When I turn "Show only subscribed folders" on and subscribe to all those
subfolders (lots of work, that's a fact) I'm running fine from now on (until I
turn "Show only subscribed folders" off again).
Raising severity to Major.
Severity: normal → major
Hi Alexsander,

You are correct that the "can't see deep levels" bug seems to only occur when
"show only subscribed folders" is DISABLED. 

However, as you point out, the [thus required to workaround the bug] subscribing
process is a huge pain. This pain could be solved by a "easy" step -- which I
think is in other numbered bug report: Add a "open all" button to the subscribe
dialog.  This feature was present in NS 4.76 but was not included in Mozilla; I
believe somebody said that it was left out to simplify the interface --
apparently that person does not a lot of mailboxes.

Additionally, I suggest that you try to change your subscriptions (i.e.
unsubscribe to a couple mailboxes).  Let it take effect and then restart
Mozilla.  Take a look at the read/unread status of all your folders -- on mine
all the "read" status is lost and all are unread.  Since I have several
individual mailboxes with as many as 20,000 messages (archived listserve
postings) in each of them, this is a big deal for Mozilla to rebuild its message
count, etc. when I go into one of these mailboxes.

Flags: blocking1.4a? → blocking1.4a-
I can't confirm that using "Show only subscribed folders" is a workaround. I
have enabled it, and subscribed to all my folders, and I still see the problem.

And I guess this is Asa's way of saying "good luck, this is NEVER going to get
fixed", since she also shot this down as blocking 1.3.


Asa Dotzler <> has denied's request
for blocking1.4a:

Bug 138759: Deeply nested IMAP folders aren't seen by Mozilla until parent gets
folded and unfolded


I am willing to bet that while you *think* you have subscribed to all your
folders you probably have not because of a bug in the subscription
dialog/visibility process.  When in the subscription dialog, you have to close
level 1 and reopen level 1 in order to see level 3.  Then close level 2 and
reopen level 2 in order to see level 4.  And so forth.  In the subscription
dialog, drill down through your subscribed folders and check to see if the
deepest ones are really subscribed.  I am willing to be that they are not.  Once
subscribed, I think you will see them visible in the main mail window.

Question: Excuse my "rudeness", but does anybody know if Asa uses IMAP and deep
folder levels in her work?  I can't imagine that anybody who has to use this on
a daily basis -- whose employment productivity depends upon it -- would think
that this is not important.

Flags: blocking1.4a- → blocking1.4a+
I recommended Mozilla/Netscape7 to a couple of friends. This bug hurts the
credibility of my recommendations. ;)
wenzhou, please don't set flags if you don't know how.
Flags: blocking1.4a+ → blocking1.4a?
I intended to vote. I apologize for the mistake and for the 3 unnecessary
messages you've received.
My Additional Comment #16 on bug 121104 still apply.

This bug is making Mozilla Mail a seriously restrained/hampered IMAP-client. 
Most people have moved or seem to be moving from POP to IMAP. With this in mind, 
I can not understand why this bug are not resolved.

Is there a time table for the solution of this bug? This one is nearly a year 
old. Duplicate bug 121104 is more than a year old. Instead of resolving it, 
somebody tried to bury it twice!
Flags: blocking1.4a? → blocking1.4a-
Get any other mail app but mailnews, ie. evolution, you can see *all* the
folders, subscribe to the folders that are not showing in mailnews. Get back to
mozilla and you will see the folders that were hidden.

BTW: bug 131938 is older than this, why the hell must I change my vote?
This is mainly to add /me to the Cc: List for 138759.

138759 needs to be resolved urgently, since it is a real showstopper when
migrating from NS 4.X to Mozilla as a whole, including mail&news.

I was assinged internal to take care of this problem when our PC-Support decided
it must be a server (courier-imap) problem, which it is definitly _not_.

Is there any way to prioritize the bug, besides voting? It is unresolved for at
least one year.

Lars doubt if this bug is similar to 200989.

For those who wants to reproduce this bug, please:
1. unix/linux
export NSPR_LOG_FILE=<a file that you want to log>
2. win
set NSPR_LOG_FILE=<a file that you want to log>
Then run mozilla mail.

Please attach the log file to this bug.

Please refer to bug 200989. I gave a patch there.

> Lars doubt if this bug is similar to 200989.

Actually, I have no doubt the two bugs are similar.
A misunderstanding? Anyway, Debug output will follow.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Thanks for the log.
I guess they are duplicated. Then could you try the patch of 200989?

The logs are from two versions, 1.2.1 and 1.4a.

I assume trying the patch means to build Mozilla from CVS. I personally have
currently no ressources to do this. But I asked a colleage inside our software
development team to set up the necessary infrastructure. This may take time,
though. Are there binaries I could test?

Calvin's patch, in comment #1 of bug #200989, certainly fixes the problem for
me, which suggests that these should have a dependency, if not a duplication.
Adding bug 200989 to deps.
Depends on: 200989
Blocks: 201332
I'm also hit by this bug. Server is MS Exchange.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030808
Still present on 1.5 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031018
built from source on Gentoo linux.
fixed in 1.7a
Closed: 21 years ago
Resolution: --- → WORKSFORME
*** Bug 146804 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
I still see this bug on mozilla suite 1.7.8 and on Thunderbird 1.0.2 
Resolution: WORKSFORME → ---
unless you can recreate this with a trunk build, please don't re-open it.
Closed: 21 years ago19 years ago
Resolution: --- → FIXED
The problem with this bug is that it seems that nobody who is in the loop with
the latest versions, etc., uses *deeply* nested Imap folders and thus it doesn't
rise to a level of concern.

In fact it seems that rather few people at all understand the concept or need
for *deeply* nested Imap folders.  I have mail boxes for thousands of clients,
projects, in multiple (but small) companies and divisions.  Keeping all that
sorted out properly is what keeps us sane.

I use Mozilla 1.7.3 on RedHat 8 and still have the problem, but I know that is
an old program at this point.


Editorial: People like myself who have only moderate skills would be a *lot*
better able to contribute to resolving these issues/bugs if we did not need a
"secret decoder ring" to understand how to do things like compile the most
recent version for Red Hat 8, or to compile with "talkbalk" (I know what it is,
but have not been able to figure out how I would get/install/use it).  Yes, yes,
I understand that if I RTFM *after* reading a few books and taking a few
classes, I would be up to speed and could do all this stuff.  As it is, anytime
I want an updated Mozilla to run on my aged Red Hat 8, I have to hire somebody
at $75/hour for at least two or three hours to compile it, etc., etc.  The the
last time I did this (for the 1.7.3 that we currently run on RH8 with KDE and
Xprint), we spent an addition 10 billable hours -- before giving up -- trying to
get things like email printing to work (i.e. get *basic* headers to print; we
never were able to get the From header to print; we never did get the Date to
appear in Forwarded emails).  

Hey, I am not trying to be rude.  I am incredibly pleased with how well the
program works and what I am able to do with it.  I gaze in wonder upon the great
minds that have created it.  I just wish that I too could help to demonstrate
issues such as this bug in the latest version, without going broke trying to do it.

Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.