Closed
Bug 178999
Opened 22 years ago
Closed 17 years ago
Mail folder listing in threaded view causes duplicates
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: baffoni, Assigned: Bienvenu)
References
Details
Sometimes when email comes in, and I'm viewing in threaded view, it shows up
twice. Open/closing the "+" grippy next to the thread makes more duplicates of
the message show up - it is like the close doesn't grab the sub folder view, and
clicking the open duplicates the contents (but the wierd thing is it duplicates
the parent email, not just the contents).
Using IMAP.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021105
Comment 1•22 years ago
|
||
I might be able to provide more info. I get it on IMAP as well, but on a Linux
build of 1.3 (Xft version).
It appears to affect messages with attachments, however not all messages with
attachements. I can't replicate it at will, but it does occur reasonably often.
I don't recall it occurring with a non-attachment message.
Clicking the "+" shows 3 copies of the first message, but not the unread
message. Clicking '-' after removes just the second from top, leaving 2 dangling
below the top one. This occurs no matter how many unread messages are below it.
Repeating does the same, leaving 4 dangling and so on. Switching to "All", no
threading, shows all of the repeats and not the unread messages, all one after
the other. Changing to unread finally shows the unread messages.
Changing folders and coming back does not help, but restarting Mozilla does.
Deleting the original message marks all the duplicates with an empty subject and
01/01/70 as the date, but doesn't remove them. If you then change folders and
come back, the next message in the thread has the same effect, except that
pressing plus shows no messages below it (just puts the grey dots under the
plus), and the plus/minus remains.
So it appears the internal state of mozilla is corrupted regarding that thread,
but not IMAP itself. However, it does start affecting other messages, marking
them unread so I don't really feel safe continuing to use it once it first
happens, and I restart.
Hope this helps!
related to bug #154403
Assignee | ||
Comment 3•22 years ago
|
||
are these in-line attachments? i.e., attachments that are displayed when the
message is selected? Does the view get messed up when the new messages are
downloaded and inserted in the view, or when you read one of the new messages?
Reporter | ||
Comment 4•22 years ago
|
||
The duplication occurs during the message download phase (although I don't
recall if it ever occurs during the initial Message-client startup, but I don't
think so, as the work around is to reboot Mozilla and the message duplication
goes away). Reading of (valid) new messages works fine. Sorry, I haven't had
this happen in a while so it is hard to tell if it has been fixed, or just the
phase of the email moon is not quite right.
Assignee | ||
Comment 5•22 years ago
|
||
there was a fix checked in for something quite like this a few months ago. I
don't know if this is a dup of an earlier bug. Does anyone see this with recent
builds?
Comment 6•22 years ago
|
||
To address these comments:
- I have seen this in the 1.3 release (see comment #1).
- I haven't seen it happen with inline attachments, definitely happens with
those that aren't (.doc files mostly).
- I think it could be related to interrupting the loading phase by clicking
away, but not sure.
Comment 7•22 years ago
|
||
I would like to verify as well that yes, indeed, this bug is still present in
1.3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312).
I witnessed this bug again this morning. See here for screenshot:
http://www.ultraemail.net/~jbj1/mozilla-screenshot.png
I moved this message to an IMAP account on my linux box so I could easily get
at the full message to put it up for inspection as well and when I did that
the two "extra" message lines in the list remained but now their subject was
blank and the time on the message shows 12/31/1969 6:00pm (I'm in US/Central
time zone so looks like the UTC time on this message would be 1/1/1970 0:00).
Here's a screen shot of this:
http://www.ultraemail.net/~jbj1/mozilla-screenshot2.png
I should not that I suspect that in all cases where I've seen this behavior
the sender's MUA has been Outlook (Express). The email (full rfc822) in
question I have also put here in case that would help someone:
http://www.ultraemail.net/~jbj1/offending-email.eml
Comment 8•22 years ago
|
||
Also, it looks like http://bugzilla.mozilla.org/show_bug.cgi?id=194444 is a
dup of this bug.
Comment 9•21 years ago
|
||
*** Bug 193940 has been marked as a duplicate of this bug. ***
Comment 10•21 years ago
|
||
*** Bug 236555 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
This problem is also present when reading newsgroups.
Look at my closed bug 236555.
Assignee | ||
Comment 12•21 years ago
|
||
can anyone recreate this with 1.6 or 1.7?
Assignee: sspitzer → bienvenu
Reporter | ||
Comment 13•21 years ago
|
||
Even with the nightlies (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7a) Gecko/20040219), but also on some of the prior milestones, I still see
occaisional problems with a bunch of empty parent and subtree items when they
are deleted from the last message in the window position, usually by the spam
filter (on IMAP, happens after the messages come in, a bunch are deleted
leaving wierd sort of empty placeholders) that stick around until I change
folders then go back. I'll take a screenshot the next time I see this.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 14•19 years ago
|
||
Reporter | ||
Comment 15•17 years ago
|
||
FYI, I haven't seen this is quite a while. Currently running Tbird 2.0.0.6 and SeaMonkey 1.1.4. Should I set this WFM?
Reporter | ||
Comment 16•17 years ago
|
||
No reoccurrence in a while. Marking WFM.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•