After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 128898 - Pan reads wrong article
Pan reads wrong article
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
0.14.2.90
Other Linux
: Normal normal
: 0.14.3
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2003-12-09 15:27 UTC by Charles Kerr
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4



Description Charles Kerr 2003-12-09 15:27:37 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.
Comment 1 Charles Kerr 2003-12-09 17:38:31 UTC
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:
header.

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."
Comment 2 Charles Kerr 2003-12-09 17:47:41 UTC
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.