using brnch build: 2002-11-01-12-1.0/ on xp 2002-11-03-05-1.0/ on mac os x 10.1.5 This is a regression from rtm builds (8/23 brnch builds don't exhibit this behavior). For either global or custom return receipts, if you set the pref to return your Return Receipts to your 'sent folder', it results in the receipt being sent to your inbox instead of sent folder. I'm sure it's related to this bug: bug 146935. whatever caused that bug (trunk only) somehow got added to branch? steps to reproduce: 1.From global or custom: Set up return receipts to request a return receipt for a mesg you send and when a receipt arrives: 'move it to my sent folder' 2.Make sure in Copies&Folders your sent folder is under your online imap account and not local folders (bug 135987 ) 3.Send yourself a mesg or to someone with MDN on 4.Get that mesg and send back the return receipt result: return receipt mesg is in inbox expected: return receipt mesg to be in sent folder
imap only. pop ok
Adding adt1.0.2 keyword. (removing from status whiteboard)
Discussed in bBird team meeting. Even though a regression, we don't see this as a stop ship.
Narrowed down the builds. This is broken in 9/25 branch builds. 9/24 builds work fine. Commercial builds: For windows: 2002-09-24-08-1.0/ 9/24/2002 10:07:00 AM worked 2002-09-25-08-1.0/ 9/25/2002 10:09:00 AM doesnt work for OS X 2002-09-24-05-1.0/ 9/24/2002 9:47:00 AM worked 2002-09-25-05-1.0/ 9/25/2002 9:55:00 AM doesnt work But when i did a query on cvs using the tag "MOZILLA_1_0_0_BRANCH " it came up empty between those dates. Checked commercial branch and it also came up empty. I don't know what could be causing the problem.
the reason this broke is that we're no longer requesting all imap headers, for performance reasons. But the real problem is that the filter that the mdn code sets up for moving return receipts to the sent folder sets the search attrib as nsMsgSearchAttrib::OtherHeader, which doesn't work - for some reason, you have to set the attrib to > OtherHeader - I'm not sure why we have to number these attribs. I don't think 4.x made you do this - you could just set the attrib to OtherHeader and the str contained the header you were interested in. But at this point, I think I'll have to fix the filter code to use one of the reserved attributes for other headers, somehow.
Created attachment 105278 [details] [diff] [review] proposed fix this is how I would fix it, but I'll leave it up to Navin.
Comment on attachment 105278 [details] [diff] [review] proposed fix wrong bug, sorry.
Cavin, can I get a review? thx.
Comment on attachment 106010 [details] [diff] [review] proposed fix sr=sspitzer I asked david: "will it work correctly if I define my own custom headers?" he says: "yes, this patch is just for mdn filters that it auto-adds. I don't think those custom header numbers are really used, except in the UI"
would this fix the trunk verison of this bug, bug 146935? The trunk was broken much earlier than branch (before headers were pulled out) so I don't know if there is another bug in trunk in addition to the one you are fixing for branch. just asking. I think the answer is no.
Comment on attachment 106010 [details] [diff] [review] proposed fix r=cavin.
fixed on trunk. I think the same fix will work on the branch.
fix checked into branch as well - I'm sure you're eager to try it out, Gary :-)
by branch, I meant the ishmail branch
was hoping this was going to get checked into 1.0 branch. But since that's not going to happen. I verified in the ishmail branch (11/20) build that this is fixed. I verified the fix for this in mozilla trunk in bug 146935 already. marking as verified.