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

RESOLVED FIXED in Thunderbird 3.3a1

Status

Thunderbird
Mail Window Front End
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: flod, Assigned: Bienvenu)

Tracking

({regression})

Trunk
Thunderbird 3.3a1
regression
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

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

Details

Attachments

(1 attachment, 1 obsolete attachment)

7.34 KB, patch
neil@parkwaycc.co.uk
: review+
neil@parkwaycc.co.uk
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

7 years ago
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?
(Reporter)

Comment 2

7 years ago
(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]
(Assignee)

Comment 6

7 years ago
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.

Comment 8

7 years ago
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.
(Assignee)

Comment 9

7 years ago
Created attachment 454761 [details] [diff] [review]
proposed fix

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?
(Assignee)

Comment 11

7 years ago
Created attachment 454865 [details] [diff] [review]
fix addressing comments

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+
(Assignee)

Comment 13

7 years ago
(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.
(Assignee)

Comment 14

7 years ago
fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Whiteboard: [needs patch]
Target Milestone: --- → Thunderbird 3.2a1
(Assignee)

Comment 15

7 years ago
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+
Checked into 3.1 branch and relbranch:

http://hg.mozilla.org/releases/comm-1.9.2/rev/814e33ede3c1
http://hg.mozilla.org/releases/comm-1.9.2/rev/be6d5c421ed0
status-thunderbird3.1: --- → .1-fixed
Duplicate of this bug: 577489
Duplicate of this bug: 578337
Duplicate of this bug: 578631
(Assignee)

Updated

7 years ago
Duplicate of this bug: 579642
Duplicate of this bug: 576572
Depends on: 585449
You need to log in before you can comment on or make changes to this bug.