GNOME Bugzilla – Bug 128898
Pan reads wrong article
Last modified: 2004-12-22 21:47:04 UTC
Very rarely -- maybe once a month -- I'll click on the top of a closed
thread and Pan will read the reply instead of the original message. When I
expand the thread in the header pane, the child's got the `cached' icon and
the parent has no cached icon. The behavior is the same whether or not the
thread is expanded in the header pane. Clicking on the child has no effect.
Looks like it happens when a user replies to a multipart message, such
as a (1/1) or a (0/N) message. Pan tries to download the top article
and its children as a multipart group. Then task_save_weed_duplicates
tries to cull out duplicate parts of the multipart, and both the
parent and child have the same multipart information in their Subject:
There are a couple of things we could do here to tweak things in
header_pane_read_article(). However IMO the root cause is that we're
treating a reply as part of a multipart even though it's not.
Instead, when we derive part & parts from the Subject: in nttp.c, we
should put in some heuristic to NOT treat a text reply as part of a
multipart. A good starting point would be "if the message is less
than 200 lines, and starts with "[Rr]e:", part=parts=0."
Hm, my comment doesn't really address this bug -- although apparently
it's something I've addressed before, as nntp.c has a clause identical
to what I described ;) -- because we're trying to read the top
article, not the reply.
To read the top article, the problem is that we're confusing articles
with a Subject: containing (0/N) as part of the binary. These are
really text articles that accompany the binary, but aren't part of it.
So the solution to this is to check for (0/N) in nntp.c and, if
found, reset part=parts=0.
Fixed in CVS: