Closed Bug 558543 Opened 14 years ago Closed 14 years ago

Return receipt notification bar should not be displayed again if user chose to ignore/confirm a request (Local Folders / POP3 only)

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(blocking-thunderbird3.1 .1+, thunderbird3.1 .1-fixed)

RESOLVED FIXED
Thunderbird 3.3a1
Tracking Status
blocking-thunderbird3.1 --- .1+
thunderbird3.1 --- .1-fixed

People

(Reporter: flod, Assigned: Bienvenu)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

New notification bar introduced with bug 151244 is displayed every time I select a mail with a receipt request.

This is great if I want to choose later to send or ignore the request, but if I already chose to ignore that request the notification should not be displayed.
This is working fine for me on trunk builds, is this still broken for you?
(In reply to comment #1)
> is this still broken for you?

Still broken on Gecko/20100613 Lanikai/3.1.1pre. Do I have to test it with a 3.2 nightly?
Ok, I've just done a bit more testing - it appears this is broken on Local Folders / POP only. IMAP appears to be working fine.
blocking-thunderbird3.1: --- → .1+
Keywords: regression
Summary: Return receipt notification bar should not be displayed again if user chose to ignore a request → Return receipt notification bar should not be displayed again if user chose to ignore a request (Local Folders / POP only)
Confirming broken for 3.1RC2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1

Return receipt notification bar is always showing again, no matter if you ignore or confirm the request (adjusting summary accordingly)

Maybe it's related to
bug 380339 - Return receipt status is only stored in .msf file and not in mbox file which I think should be fixed along with this one
Summary: Return receipt notification bar should not be displayed again if user chose to ignore a request (Local Folders / POP only) → Return receipt notification bar should not be displayed again if user chose to ignore/confirm a request (Local Folders / POP3 only)
David, can you take a look at this one?
Assignee: nobody → bienvenu
Whiteboard: [needs patch]
This code only works for IMAP. I suppose the expectation is that some other code is supposed to clear the local hdr flag.

http://mxr.mozilla.org/comm-central/source/mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp#180
Some code was removed here (middle section):
https://bugzilla.mozilla.org/attachment.cgi?id=437900&action=diff#a/mail/base/content/mailWindowOverlay.js_sec6

That seems to remove the storing of the message flags. I just wonder why there is similar code in the c++ part, but apparently only for imap.
I have the same problem (multiple return receipt requests on same msg) with Thunderbird 3.1 and a message from my Yahoo mail account downloaded through POP.

Using Mozilla/5.0 Gecko/20100608 Thunderbird/3.1.
Attached patch proposed fix (obsolete) — Splinter Review
fix is to make sure we set the mdn sent flag locally when the request is ignored or sent, as we did before.
Attachment #454761 - Flags: superreview?(neil)
Attachment #454761 - Flags: review?(neil)
Comment on attachment 454761 [details] [diff] [review]
proposed fix

>+    if (imapFolder)
>+      return imapFolder->StoreImapFlags(kImapMsgMDNSentFlag, PR_TRUE, &key, 1, nsnull);
>+}
Not returning anything for local folders...

>+    ClearMDNNeededFlag(m_folder, m_key);
No assertion this time?
added assertion, fixed return, and combined common code.
Attachment #454761 - Attachment is obsolete: true
Attachment #454865 - Flags: superreview?(neil)
Attachment #454865 - Flags: review?(neil)
Attachment #454761 - Flags: superreview?(neil)
Attachment #454761 - Flags: review?(neil)
Comment on attachment 454865 [details] [diff] [review]
fix addressing comments

>+  var askUser = mdnGenerator.process(MDN_DISPOSE_TYPE_DISPLAYED, msgWindow, msgFolder,
>+                                     msgHdr.messageKey, mimeHdr, false);
[Should we be able to predict this value?]
Attachment #454865 - Flags: superreview?(neil)
Attachment #454865 - Flags: superreview+
Attachment #454865 - Flags: review?(neil)
Attachment #454865 - Flags: review+
(In reply to comment #12)
> (From update of attachment 454865 [details] [diff] [review])
> >+  var askUser = mdnGenerator.process(MDN_DISPOSE_TYPE_DISPLAYED, msgWindow, msgFolder,
> >+                                     msgHdr.messageKey, mimeHdr, false);
> [Should we be able to predict this value?]

we can ignore this return value - what we're really interested in is the initialization of the mdnGenerator that happens when we call mdnGenerator.process, which enables UserDeclined() to act on the right message.
fixed on trunk.
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs patch]
Target Milestone: --- → Thunderbird 3.2a1
Comment on attachment 454865 [details] [diff] [review]
fix addressing comments

very much want this for 3.1.1
Attachment #454865 - Flags: approval-thunderbird3.1.1?
Comment on attachment 454865 [details] [diff] [review]
fix addressing comments

a=Standard8 Please land this just on comm-1.9.2 default. I'll sort out what we're doing with relbranches later.
Attachment #454865 - Flags: approval-thunderbird3.1.1? → approval-thunderbird3.1.1+
Depends on: 585449
You need to log in before you can comment on or make changes to this bug.