Closed Bug 93863 Opened 23 years ago Closed 22 years ago

subfolders of Drafts and Sent folders show Sender address not Receiver

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.1alpha

People

(Reporter: andrew.treloar, Assigned: sspitzer)

References

Details

Attachments

(2 files, 2 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3) Gecko/20010802
BuildID:    2001080214

When I look at the list of messages in my a subfolder of my Sent folder (stored
on the server), it displays the Sender column (which is always me, of course).
This makes it difficult to identify messages sent to a particular individual.

Reproducible: Always
Steps to Reproduce:
1. Select a subfolder of the Sent folder
2.
3.

Actual Results:  The Sender column is shown

Expected Results:  Show the Recipient column (which is what it does at the top
level of Sent)

This may be because I copied all my Sent subfolders from Local storage to the
server, but I did this copy using Communicator 4.75.
Confirmed under Mac/2001080214. It probably makes sense to treat Sent subfolders the 
same as Sent itself, in that Recipient, not Sender, should be displayed.

This should be treated as an RFE.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed on
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913

This is an actual bug since the header says recipient, but it actually lists Sender
*** Bug 101162 has been marked as a duplicate of this bug. ***
The severity of this is listed as "enhancement". It's not an enhancement, it is
a bug. As pointed out by buttler@cc.gatech.edu the column heading is recipient
but the contents of the column are sender. Furthermore, subfolders of sent
showing recipient (and not sender) is not only logical but is the way NS4 works.
Depends on: 101162
Severity: enhancement → normal
Status: NEW → ASSIGNED
Keywords: nsbeta1
OS: Mac System 9.x → All
Hardware: Macintosh → All
Summary: Sent folder shows Sender address not Receiver → Sent subfolder shows Sender address not Receiver
No longer depends on: 101162
*** Bug 101162 has been marked as a duplicate of this bug. ***
*** Bug 116666 has been marked as a duplicate of this bug. ***
*** Bug 98866 has been marked as a duplicate of this bug. ***
*** Bug 96886 has been marked as a duplicate of this bug. ***
I raised Bug 115258 a while ago, which was that when you set Mozilla to save
Sent Messages to some other folder (e.g. Inbox), it still shows Sender at the
top, but actually displays the Recipient address in the column.
I'd suspect that that is related to the problem here.
As someone who has literally 30,000 messages in
various sent folders in Netscape over the years,
I can tell you that this bug is severe, and really
makes the mail system unusable for power users of
the mail product.

I do tech support for Americart, and without good
"sent" records with proper recipient, I'm dead. Well,
not dead, but stuck with 4.7.  :)

Sorry to intrude on this bug, but our whole office is
waiting for it to be fixed.
re: wayne@cartserver.com

I couldn't agree more. I have a very similar situation. Literally thousands and
thousands of messages in subfolders of Sent. :-(
In the last few days more and more people complained about this bug and how
severe it is to them. I don't like this "feature" either, but let's take a
practical approach. Is there anything we can do to support those who have
expressed their willingness to work on this bug? Seth, what is the progress of
the work on it and how can we help?

Salut,
  Mathias
Keywords: nsbeta1nsbeta1-
*** Bug 133866 has been marked as a duplicate of this bug. ***
Firstly, an addition to my original notification. I see the same (mis)behaviour
whether the Sent folder is local or on the server.

Secondly, a cry of anguish. There has been no progress on this bug since I first
logged it. I've been hoping that a fix would show up in Mozilla 1.0, but it's
still there and (even worse!) it is currently tagged as nsbeta1-. This means
that the Netscape evaluation team has rejected it for the next Netscape release.
Without this being fixed, there is no way my university will adopt
Netscape/Mozilla as its successor to Communicator 4.7X. The longer the delay in
fixing it, the harder it will be for me to argue against the adoption of
'Outbreak Express' as the corporate email client. I've already voted for this
bug - what else can I do to increase the level of urgency? At present, searching
for sent messages is really painful.
couldn't agree more but IMHO there's no hope of this being fixed for mozilla 1.0
which also means Netscape 6.5. While this couldn't be fixed we had coloured
labels added to mail (amongst other things)... :-(
*** Bug 139792 has been marked as a duplicate of this bug. ***
*** Bug 141053 has been marked as a duplicate of this bug. ***
*** Bug 141398 has been marked as a duplicate of this bug. ***
*** Bug 141649 has been marked as a duplicate of this bug. ***
For everyone who cant wait until this is fixed officialy (maybe, if at all),
I have an inoffical fix for it. (for 0.9.9)

If you want it, (just a dll) drop me a mail.



*** Bug 142775 has been marked as a duplicate of this bug. ***
I'd like to see this bug having severity "critical".

Slava
*** Bug 143519 has been marked as a duplicate of this bug. ***
thanks for the patch reto, but this is not the right approach.

we already have code in the front end (see IsSpecialFolder() in commandglue.js) 
that does what you are trying to do.

I think the proper fix is to pass through the result of IsSpecialFolder() 
to ::Open(), instead of trying to determine it from within Open().

I'll work on the fix.
Attachment #82626 - Attachment is obsolete: true
the fix is in on the trunk. 

thanks to reto@tischhauser.com for the initial patch.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Summary: Sent subfolder shows Sender address not Receiver → subfolders of Drafts and Sent folders show Sender address not Receiver
Target Milestone: --- → mozilla1.1alpha
*** Bug 144575 has been marked as a duplicate of this bug. ***
Why isn't this bug fixed on Mozilla 1.0 RC2?
I don't understand.
It doesn't work on Mozilla 1.0 RC3 and this bug is supposed to be RESOLVED FIXED. 
Despite comment #28 claiming that the fix for this was 'in the trunk' and
despite it being listed as RESOLVED FIXED it is *still* there in Mozilla 1.0.
Can (the status please be reset to VERIFIED and resolution turned off) or (the
fix applied to the *current* trunk?)
Yes, please, could anyone change the state to REOPENED??? This is frustrating.
This is showing as not being committed until mozilla1.1alpha, correct?  So this
would explain why we are disappointed.  Hopefully this will be committed now. 
Is it in a nightly current build?  I'd try that now if I could find out that answer.
Hello Dow,
it is part of the nightly build but unfortunately didn't make it into release
1.0. Why? Don't ask me. I am as disappointed as you are.
This DLL fixes the bug in mozilla 1.0 (win-32 only, sorry.)
Don't even think to use it with any other version than 1.0

How to install :
0) exit mozilla
1) In your program installation folder,  open the "components" folder.
2) seek for the "msgbase.dll", rename it to "msgbase.dll.old"
3) copy my "msgbase.dll" there 
4) start mozilla, go into the mail-client, test
5) If it did not work, throw my dll and rename the "msgbase.dll.old" to it's
orignal name.
5) Let me know if it works on your machine.

Reto.

(Source code is included)
Win2k Mozilla 1.0 Build ID: 2002053012

After extracting msgbase.dll from attachment.cgi.exe using PKZIP I installed the
new msgbase.dll. Mail appears to be working correctly now with correct sorting
of sent mail.

Thanks Reto!
Works great :-)

Reto, very fine!
Patch 86936 works fine with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0)
Gecko/20020530
*** Bug 156073 has been marked as a duplicate of this bug. ***
*** Bug 162668 has been marked as a duplicate of this bug. ***
Ohhh, it's fixed on Mozilla by now! I have just checked it on Mozilla 1.1 Beta
(2002072104) [WinXP].

See you in other bugs ;)
*** Bug 166669 has been marked as a duplicate of this bug. ***
Is it possible, that this bug is _not_ fixed in Mozilla 1.0.1? I can't believe!
:-/
It's NOT fixed in 1.0.1...
I realise that this isn't the place really, but could someone confirm that this
bug is also present in Netscape 7.0?  If so, we'll almost certainly have to
delay upgrading from 4.7 until a future release.  *sigh*
Yes it is there in NS7.0 running it on a few boxen here.

You can roll out a default/prefs/all.js with:

user_pref("security.checkloaduri"; false);

in it to overcome the problem.

THis of course would leave a few holes open so you would have to be careful with
this one, depending on the hostility of sites visited by your users.
I'm still seeing this in 1.2 b under windows.  Are we sure it is resolved?
Mozilla 1.2b under Suse 8.0 works for me. I seem to remember 1.2b working on
Windows before I switched to Linux. Have you tried deleting the .msf indexes and
letting Mozilla mail rebuild them?
*** Bug 195757 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: