Closed Bug 154403 Opened 23 years ago Closed 18 years ago

threaded view goes postal

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.2beta

People

(Reporter: jud, Assigned: Bienvenu)

References

Details

(Keywords: regression)

Attachments

(4 files)

image
57.38 KB, image/jpeg
Details
image 2
57.75 KB, image/jpeg
Details
Threading problem
4.01 KB, image/png
Details
Incorrect Threading
20.65 KB, image/gif
Details
using today's trunk win2k build. when doing heavy threaded header navigation, child msgs get out of sync. for example, deleting one message in the middle of a thread series, will cause the remaining msgs to move up but not over to replace the vertical position of the deleted message. I've also noticed that selecting multiple messages inside a thread (using the keyboard) and hitting delete, will wipe out the subject line in header view of the deleted messages, but, the thread structure remains. I've also seen the message body and headers get duplicated for a series of messages in a thread that were deleted.
reassigning to naving. Can you see if this is or isn't related to 152895. Jud, does this only happen to you on the trunk? What about with an earlier build?
trunk only. I wasn't seeing this a few days ago, but, then again, I wasn't hammering my trunk build that hard then.
really reassigning to naving.
Assignee: sspitzer → naving
the indentation has never been corrected when a parent message is deleted (unless the parent is the root message). So I'd ignore that in the sense that it's unrelated to the other display issues, which I have not seen.
QA Contact: olgam → laurel
I am seeing these 2 of what was reported first >when doing heavy threaded header navigation, child msgs get out of sync. for >example, deleting one message in the middle of a thread series, will cause the >remaining msgs to move up but not over to replace the vertical position of the >deleted message. >I've also noticed that selecting multiple messages inside a thread (using the >keyboard) and hitting delete, will wipe out the subject line in header view of >the deleted messages, but, the thread structure remains. But I *haven't* seen this >I've also seen the message body and headers get duplicated for a series of >messages in a thread that were deleted.
As I explained before, that first one (the indentation one) has been that way since 4.0 so it's not new, and is unrelated to the new regression. The one to concentrate on is: >I've also noticed that selecting multiple messages inside a thread (using the >keyboard) and hitting delete, will wipe out the subject line in header view of >the deleted messages, but, the thread structure remains.
Keywords: regression
Attached image image —
thread structure after deleting multiple msg inside a thread. David, do you see this as indentation problem or something more?
that's just the indentation problem.
Attached image image 2 —
another image. looks like indentation problem to me, though of a different kind.
yes, same problem (indentation of children not updated when parents deleted)
Removing regression keyword. That is all I have been seeing.
Keywords: regression
How does the indentation problem happen when you are not deleting messages? I have this problem a few times a day in various newsgroups and I don't delete any messages, and Mozilla is set to keep all posts. I advance through the group with "T" and then get new messages after I've been through the whole group to see my posts. It's usually when I get the new posts that the threading goes nuts. In my case, it appears to just lose track of the proper heirarchy and place messages willy-nilly.
Attached image Threading problem —
The two messages that are out of whack in this screenshot belong one line up. No messages were deleted from this thread to cause this to happen. It happened after " Get Msgs".
BTW - collapsing the thread and re-expanding it puts the messages right.
Further testing seems to indicate that this is happening when new messages are added to a thread that is already expanded. It doesn't happen everytime on these threads, but it does happen frequently (maybe about 30%).
I think I see what's going on here. Mozilla simply appends new messages to an open thread in date order without regard to a message's actual relationship to the thread heirarchy. This will cause problems when a reply to a separate part of the thread comes chronologically before another message that should be above that one. Illustration: Initial state of the thread on firt reading looks like this ------------------------------------------- Thread View Goes Postal - Re: Thread View Goes Postal - Re: Thread View Goes Postal - Re: Thread View Goes Postal ------------------------------------------- Now imagine that two new people have posted messages to that thread. One reply is to the parent message of the thread, and it comes before the other message in time. The other message is a reply to the most deeply nested message in the heirarchy. After these messages have arrived on the NNTP server, you press your Get Msg button in Mozilla. If this thread is already expanded, here's what's going to happen: ------------------------------------------- Thread View Goes Postal - Re: Thread View Goes Postal - Re: Thread View Goes Postal - Re: Thread View Goes Postal - Re: Thread View Goes Postal* - Re: Thread View Goes Postal* ------------------------------------------- * - New messages ------------------------------------------- The last message should have been shown one line above it's current position in the heirarchy, but since the date header is later it is not. So, in summary, Mozilla appends messages to threads in date order without regard to heirarchical structure. The indentation is correct, but the vertical positioning is not.
that would be a bug, and a relatively recent one - the code that inserts messages into expanded threads does attempt to place the reply immediately below the message it's a reply to.
Sorry for all this spam, but this is driving me crazy. Further tests indicate that this is worse than I thought with my previous comment. Mozilla can't even get one new message right. If you have... threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal and a reply is posted to the third message, Mozilla will place it under the 4th. Like so... threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal Should be... threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal - Re: threaded view goes postal So, it is not required that the special circumstance of two separate messages come in a particular order. This just happens all the time.
Keywords: regression
Anyone have an idea when this regression might have happened? I am willing to try tracking it down, but a starting point would be good. Adding 4xp and mail3 keywords
Keywords: 4xp, mail3
I've only started to see it in the Mozilla latest 1.1 branch for win32. (2002081419) as of this time and perhaps a couple of days earlier
Attached image Incorrect Threading —
It seems the replies are going to the bottom of the parent's parent rather than to the bottom of their parent container.
Just a friendly ping. Is there a target milestone for this that isn't "Future"?
taking.
Assignee: naving → bienvenu
Target Milestone: --- → mozilla1.2beta
related to bug #178999
*** Bug 155860 has been marked as a duplicate of this bug. ***
I think what's going on is conflicting interpretations of the References header and the In-Reply-To: header. For instance, the type of message that normally scres up threaded view for me, is one that has In-Reply-To:some text<messageid> as opposed to the normal usage of In-Reply-To:<messageid> mh for emacs, at least in the config of one of my colleagues, does this, and normally causes his replies to be placed as replies to the parent, no matter what, based on the subject. The actual <messageid> is valid, so the threading should work. [In-Reply-To:<messageid>some other text] works fine, (elm behaviour) Likewise, pine will use both the References: field _and_ the In-Reply-To: field. I don't think this is helping :) Cheers, Karl P
I thought there was a bug in handling in-reply-to: some text<message-id>, and that it was fixed. I'll go look at the code. Maybe the fix was never checked in.
I don't think that bug is related to this one except for superficially in appearance. Threads are still broken as described by me previously. All replies added to an already expanded thread are attached to the parent of the reply's parent. Doesn't matter whether In-Reply-To, References, or just threading by subject is used.
Original post of this bug indicated three symptoms, all of which appear to be display oddities related to deleting messages within a thread view. - The indentation display problem is similar to bug 102997; see also the fairly new bug 208324. - The "subject lines wiped out" problem I haven't seen duplicated anywhere else. - The duplicated-entry problem may be related to bug 178999, but I really don't think so; that bug is about arriving mail, with attachments. Judson Valeski, are all (or any) of these original symptoms still a problem in current builds (1.3 or 1.4) of Mozilla? Jerry Baker's complaint, starting in comment 12, seems to be about out-of-order display of new messages arriving; this looks to me like bug 93426.
Blocks: 236849
*** Bug 164995 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
no longer seeing this.
(In reply to comment #31) > no longer seeing this. Could you give a timeframe for that? What's the last version where you saw the problem, vs the version you're using now? Maybe you could opine on whether one of the bugs cited in comment 29 is a dupe?
->WFM? (In reply to comment #32) > (In reply to comment #31) > > no longer seeing this. > > Could you give a timeframe for that? What's the last version where you saw... judson writes: "no clue... haven't seen this bug in years." bug 208324 STM unrelated - so perhaps fixed by bug 93426.
closing WFM. Please reopen if anyone sees otherwise. Or, pick up on one of the bugs still open. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090302 SeaMonkey/2.0a1pre
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
No longer blocks: 236849
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: