120502 - Reply to a newsgroup message replies to wrong message

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P1)

Description

[scottputterman]

Using the 1/16 build on Win 2000.

I saw this while investigating Bug 116044.

go to msnews.microsoft.com
subscribe to microsoft.public.msdn.magazine
put yourself in threaded mode.
Look for the 1/7/2002 6:22am message from MATEUSZ Z. titled "o grach"

Display it and then reply to it ( you don't need to send it).

Then look for 1/14/2002 2:32AM message from Casper van Dijk titled "Question on
Jay Allens article in jan 2002 issue (Client side controls)"

Display it and then reply to it.

Result:  The reply shows the reply to the first message and not the message
that's selected.

Comment 1

[jay garcia]

Win98SE 2002011703 - confirmed, same bug but in a different group on the same
server.

Comment 2

[scottputterman]

I forgot to mention that I'm using the recycled compose window.  I don't know if
that makes a difference.

Comment 3

[Sheela Ravindran]

I tried the same message without the recycle compose window and it replies to
the correct message. I was on threaded mode.  I am using 2002-01-17-06 build on
win98.  I will try a few other groups and messages to see if I see the problem
without recycle compose window. 

Comment 4

[Sheela Ravindran]

I also could not reproduce this with recycle compose pref using today's build.  

Comment 5

[scottputterman]

I still see this with the 1/17 build on my Win 2000 machine.  I didn't see this
with my Win NT machine with a build from 1/15.

Comment 6

[scottputterman]

I just realized that on my machine at work I was probably set to reply in
plaintext which wouldn't exhibit this problem.

Comment 7

[[e-mail] (gone - use [e-mail] instead)]

I see this:

news://msnews.microsoft.com:119/#$pU4Z4lBHA.2524@tkmsftngp02 is the message from
MATEUSZ

and

news://msnews.microsoft.com:119/#kCXzaOnBHA.2040@tkmsftngp02 is the message from
Casper van Dijk.

Displaying either message is fine, but replying does exactly was Scott points
out for my 2002-01-18-03 Windows 2000 build.

Comment 8

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Casper

Comment 9

[[e-mail] (gone - use [e-mail] instead)]

Attachment: MATEUSZ

Comment 10

[[e-mail] (gone - use [e-mail] instead)]

My setup was WITHOUT threading, just a flat view, sorted by read/unread status
(with read at top), no recycled compose windows.

Comment 11

[Sheela Ravindran]

Yes I am able to see this problem too. I was not reading the other message so I 
did not see this problem before.  
Stephend checked this on linux too and it happens on linux.  So changing os to 
all platforms.  

Comment 12

[Jean-Francois Ducarroz]

This problem is caused by the fact some of the microsoft messages have a message
ID which start with a #. That totally confuse nsIUrl when we add the query
?quote=body as the # sign is interpretted as a reference. Here is example of the
news URLs we try to process:

1)news://[e-mail]/\?header=quotebody#$pU4Z4lBHA.2524@tkmsftngp02
2)news://[e-mail]/OcJomT7mBHA.1716@tkmsftngp02\?header=quotebody
3)news://news.mozilla.org/[e-mail]\?header=quotebody

2 and 3 are ok but 1 which give various result but most of the time will return
the wrong message!

I don't know at this point if it's legal to have a # sign in a message-id and if
 the fact nsIURL put the reference after the query is the right thing to do.

Comment 13

[Jean-Francois Ducarroz]

after consulting RFC 2822 ( the updated version of 822), the # sign is a legal
character in a message-id.

Comment 14

[Jean-Francois Ducarroz]

Per RFC 2396, the reference should go after the query, therefore nsIURL does the
right thing.

Comment 15

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 119750 has been marked as a duplicate of this bug. ***

Comment 16

[Jean-Francois Ducarroz]

my guess is that the solution should be in nsNNTPProtocol::ParseURL. Reassign to
sspitzer

Comment 17

[(not reading, please use [e-mail] instead)]

Attachment: fix

fix.  the problem isn't in ::ParseUrl(), but it is in the news code.

Comment 18

[(not reading, please use [e-mail] instead)]

that patch also allows the user to cancel posts with # in the message id.

the other part of the patch is to reduce the code by using GetMessageIdForKey() 
instead of getting the msg hdr from the key, and then calling getmessageid()

great find, putterman.

this has r/sr=bienvenu, marking fixed.

note to stephend, to test this, you can try this:

about line 687, nsMsgSend.cpp, add this:

  if (mCompFields->GetMessageId() == nsnull || *mCompFields->GetMessageId() == 
0)
  {
    char * msgID = msg_generate_message_id(mUserIdentity);
+   msgID[1] = '#';
    mCompFields->SetMessageId(msgID);
    PR_FREEIF(msgID);
  }

that will generate [bad] message ids, but the will contain #, useful for 
posting to netscape.test for reply and for cancel verification.

don't check that in, of course

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

The 1st part of this bug is Verified FIXED:

Replying to both of those messages separately yields each message quoted correctly.

2002-02-18-10, Mac OS X 10.1.2
2002-02-18-10, RedHat Linux 7.2
2002-02-18-03, Windows 2000.

Now, on to part #2, which is about cancelling posts with # in their message ID.

Comment 20

[[e-mail] (gone - use [e-mail] instead)]

news://news.mozilla.org:119/#[e-mail]

Was the message ID, and replying to it was fine.

Also, I tested cancelling of it.

Worked fine.

Verified FIXED with builds mentioned above.