174670 - Sent folder in Local Folders does not show recipients

Status: RESOLVED INVALID

(MailNews Core :: Networking, defect)

Description

[John Malmberg]

The sent folder in local folders shows the sender by default, and there is no
option to show the recipiant.

Mozilla 1.1

Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.1)
Gecko/20020828

Comment 1

[Colin Blake]

In the folder pane (left pane in 3-pane view), is the "sent" folder you are
referring to showing up as "sent" or "Sent"?

This is the "Sent" in the "Local Folders", right (that's what you said, I'm just
confirming).

Comment 2

[Colin Blake]

I see the same problem. With Mozilla 1.1 I can rename "sent" to "sentt" and then
"Sent" and then "recipient" appears instead of sender as the column heading. But
after restarting Mozilla the folder is back to "sent" again!

I think this is related to bug 155226 which is detailed in bug 153101. The
mailbox name comparison is meant to be made case-blind for non-IMAP mailboxes,
but that doesn't seem to be happening, hence the problem (for any non-VMS people
reading this, file names are not case sensitive on VMS, and readdir() returns
everything in lowercase).

Comment 3

[Colin Blake]

I've been playing around with this and here's what I see on a newly created mail
account:

colin@whatever
  Inbox
  Trash
  drafts
  sent
  templates

LocalFolders
  Trash
  drafts
  sent
  templates
  unsent_messages

I think there's two problems here.

Problem 1. Some folder names appear in lowercase, while other are capitalized.
All special folder names are meant to be case-insensitive, and there's code in
Mozilla that's meant to handle this. But I think this code is broken and no one
else has noticed this because no other platforms have case-blind file systems.
See the code in
http://lxr.mozilla.org/seamonkey/source/mailnews/local/src/nsLocalMailFolder.cpp#299
which takes care of case-ignoring "Inbox", "Trash", and "Unsent Messages". Now
look at the code at
http://lxr.mozilla.org/seamonkey/source/mailnews/local/src/nsLocalMailFolder.cpp#314
which is meant to take car of "drafts", "sent", and "templates", and notice that
its been ifdef'd out. There's a comment which says these three special folders
are now handled elsewhere but I don't believe it!!

Problem 2. unsent_messages (with an underscore). This is caused by the fact that
OpenVMS doesn't allow a space in filenames (lets ignore ODS5 volumes for now).
To get around this our "UNIX layer" translates the space to an underscore when
creating the file. This means that later readdir() returns "unsent_messages" and
Mozilla compares this to "Unsent Messages" and says "this ain't no special
directory". This explains why you can "send unsent messages" too. I think bug
177418 talks of this problem. 

Is there anyone else to assign this one to, since mscott is on sabbatical until
January?

Comment 4

[Colin Blake]

Putting the ifdef'd out code back in again (and fixing the rot) did indeed fix
the problem. I think this code needs to be present on all platforms (for
correctness); its only on OpenVMS where the bug shows itself. What are my
chances of being able to check this in?

I also came up with a fix for the "unsent_messages" problem. Adding a check in
CreateSubFolders for "unsent_messages" and changing the name to "Unsent
Messages" fixed this one. This is really a VMS only fix, and I know that
platform dependant code is frowned upon. So what are my chances of being allowed
to check this one in?

John, you want a fixed image to try (you'll need to running 1.2 beta)?

cc'ing Asa to see how to proceed with this, in mscott's absense.

Comment 5

[Colin Blake]

Attachment: Add missing code

Patch to put back in the ifdef'd out code.

Comment 6

[Colin Blake]

The patch for fixing "unsent_messages" I'm posting in bug 177418.

Comment 7

[David :Bienvenu]

the reason we don't do this is that the user can select different folders for
these special folders, so the name comparison is not correct. For example, with
the account settings ui, I could set folder "Foo" as my sent mail folder.

You should look for the place where we compare the fcc pref vs a folder name to
decide if a folder should have the special flag set.  The fcc pref is stored as
a uri. The problem is that the uri isn't going to match because the file name on
disk has a different case than we expect - I'm not sure how we can deal with
that, but the attached fix isn't correct.

Comment 8

[Colin Blake]

OK, I understand what you're saying. All/most of the other code does case-blind
comparisons when comparing folder names. So how do we make the uri to folder
lookup case-blind?

Comment 9

[David :Bienvenu]

URI's in general are case sensitive so we would need to special case the
handling of these special folders, not URI folder lookup in general (which uses
the RDF methods for resolving uri's, and we can't change that to be case
insensitive). 

I believe the routine that does this is nsMsgIdentity::setFolderPref. One
possibility would be to make this routine check if the folder really exists (the
only way we have of doing this is checking if the result folder has a non-null
parent ptr). If the folder doesn't exist, we could convert the uri to lower case
and check again if the folder exists for the lower-case uri. If it does, we
could then set the pref to the lower case uri, and set the appropriate flag on
the folder.

Comment 10

[Colin Blake]

Note: a proposed patch in bug 177418 would, I thinkk, also fix this problem.

Comment 11

[Billy Newsom]

I just put a long description in a very related bug 123707.  The problem with
that old bug is that it is listed as enhancement instead of normal.  I would
hope that either this bug gets updated to include the whole Windows trunk, or
that old one gets a new lease on life with a normal bug status.

Bug 114533 seems to be similar.  Bug 166603 is related to this.

I am reporting this problem on Windows 2000 and Windows 98.  Probably all
Windows clients are affected.  I'm also seeing the bug on Mozilla 1.2.1 and
1.3a.  I use a Courier IMAP mail server on FreeBSD.  Please see my fuller
description in bug 123707.

Comment 12

[Colin Blake]

The checkin for bug 192780 has solved this problem.

Closing.