Return Receipt's prompt before allowing the mail to be read.

Hey Darin,
You do make a good pt. I tried 4.79 and it basically
does the same thing. The only slight difference between
current branch & 4.79
  -branch: you keep the previous mesg in the Mesg pane window
           and when you click on the new mesg, the prompt appears
           but it doesnt load in Mesg pane window
  -4.79: when new mesg arrives and you click on it, the header
         of the new mesg is loaded in mesg pane window (not the body)
         and you get the prompt.

I talked to David and he mentioned:
"- the only thing I can imagine is that putting up the RR dialog prompt is
preventing layout from finishing the laying out/display of the underlying
message, so it would be an event
processing problem (thos modal dialogs tend to prevent other things from
happening)"

how about making the RR dialog non-modal? or how about deferring it until the
msg has completely loaded?

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

Bug 166165 Message confirmation is too invasive Comment 0:
I'm reading mail, I should be able to read a message and at the end decide
whether I want to confirm receipt of the message.

What actually happens: I get the message and have to decide to confirm before I
read the message.

It's true that in physical certified mail you have to sign on the dotted line
before you can read the message. However this is email, and it makes more sense
to allow the reader to decide to confirm receipt after reading instead of before.

I scan my mail quickly and then go back to things which are important (real
people do the same thing with real mail, although they tend to only look at the
envelope -- unfortunately the envelope for email isn't always helpful in
indicating importance).

My parents and relatives actually send me MDN'd messages, but while they do want
to know that I got the message, they're almost always more interested in knowing
that I actually *read* the message. Usually the message is an invitation or
indication about an event of some sort. If my computer has received the message
and i've marked it as read because i was skimming through my mail, but i didn't
actually read the message, then the notification is useless and misleading.

IMO a better UI would be chrome at the bottom of the message "The sender has
requested a receipt. <send receipt reply>" with a little receipt icon in the
envelop chrome which links to the bottom of the message.

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

Regards
JG

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

I'd like to have the possibility to manually send a return receipt after reading
the eMail as well.

It'd be great to have a "send receipt now" option in the context menu of
messages that requested a receipt but did not yet get any.

It'd be even greater to have an "always return receipt to people in my personal
addressbook in groups X, (...)" option or something in the Mail&Newsgroups
preferences - but that'd be another feature request, I suppose.

(i am assuming, as all people who comment this bug, that this bug refers to a situation where return receipt (RR) options are setted to "Ask me")

I think this could be a good way to handle this bug:
When you open/preview a message with return receipt, a msgBox pop ups:

    +-----------------------------------------------------+
    |"The sender of this message request a return receipt.|
    |If you want send it, use the button in headers bar. |
    | [ OK ] |
    +-----------------------------------------------------+

And a bar is added, similar to the junk-mail one.

    ---------------------------------------------------------------------------
    The sender of this message request a return receipt. [ Send ][ Never send ]
    ---------------------------------------------------------------------------
    [+] Subject: .............. From: .......... ##/##/#### ##:##
    ---------------------------------------------------------------------------
    (mail body)

This way you can read the mail entirely before send confirmation, or you can leave it and be warned by msgBox next time you read it, or you can click on "Never send" and skip further annoyance.

PS: A column "RRReq" (values = {Yes, No}) in mail list also helps, and it's easily visible than a special icon.

sergiodf wrote:
> think this could be a good way to handle this bug:
>When you open/preview a message with return receipt, a msgBox pop ups:
>
> +-----------------------------------------------------+
> |"The sender of this message request a return receipt.|
> |If you want send it, use the button in headers bar. |
> | [ OK ] |
> +-----------------------------------------------------+
>
>And a bar is added, similar to the junk-mail one.

I believe this is an overkill, althoug a nice one. :-)

The message header are already displayed, but no text, when the current dialog asks if receipt should be sent. The only thing that is needed, IMHO, is to display the full text message before launching the modal dialog box, so that we might have a clue on whatever is the mail about.

Fernando

(In reply to comment #9)
> And a bar is added, similar to the junk-mail one.

This is exactly what I was imagining. Some web mail client do that and I find this very user friendly and you can take the decision to send or not a return receipt at any moment! Even a week later :)

I would simply display the feature un the "header/subject" bar; no popup at all (this would be one of the methods to act upon a return receipt: auto-send, ask-me, display in "header/subject" bar for manual processing).

But no more popup please ;)

But if you keep the actual 'ask me' feature, I agree that the message should be displayed first. This was my original intention when I searched for this bug/feature.

Best regards.

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

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

I don't know whether my idea was simpler to implement, but here it is:

Besides Yes and No, there should be also and "not now" button, like in password manager in Firefox. So, when you click not now and revisit the message, the same dialog is offered again, until you decide yes or no.

I don't understand why this bug is not taken seriously. It has been around for age yet I'm sure a lot of people won't/don't use thunderbird in a professional context because of it.

I think the idea of Ivan is great, we should have an additional "not now" button. Maybe I'm wrong but I don't feel like it would be too difficult to implement.
Meanwhile the close button could be use in the dialog to work like a "not now" button instead of a "no button". I think it would be more natural since clicking on close doesn't explicitly mean to not return a receipt. (When people use the close button instead of yes or no it is because they don't know yet whether to send a receipt or not)

Meanwhile, I moved to Thunderbird. (In reply to comment #10)

The same bug has been filed on Thunderbird! Vote for it!

https://bugzilla.mozilla.org/show_bug.cgi?id=375556

TB should ask about sending Return Receipt after you mark message as read thats what is done for. Problem is in TB you can't mark messages read unread by yourself it done automatically after whatever seconds. I'll like to let some messages unread in outlook just because I have not read it property or don't want send read notification now.

Comment #15:
> I don't understand why this bug is not taken seriously. It has been around for
> age yet I'm sure a lot of people won't/don't use thunderbird in a professional
> context because of it.

Hear, hear! Filed in 2002, so I hardly think its status could be considered "NEW"....

The Return Receipt should not, however, be a Dialog Box. A simple button in the message pane/window should be sufficient, with maybe a warning dialog if you attempt to delete a message that requested a Return Receipt and one has not yet been sent.

Created attachment 420601
patch v1

This initial patch makes the prompt 'async'. It is now handled by the UI code, instead of inside the MDN code. The UI is now a notification bar, just like remote images etc. It will continue to show one mails with a mdn request until the user either agrees or denies to send.
I had to change the idl to make it possible to have some sort of callback. I opted to split the generation of the mdn message in two parts. First, initializing and prefs checking is done. The second part is the actual sending of the the reply. Part 1 may call part 2 directly, depending on the preferences.

In my opinion, this change makes receiving mdn request much less annoying. At least you can actually read the message before sending a note that you have read it...

Created attachment 420602
screenshot

Screenshot of the proposed UI

Comment on attachment 420601
patch v1

are the nsMsgDBFolder.cpp and OSXIntegration changes supposed to be in the diff?

(In reply to comment #22)
> (From update of attachment 420601 [details])
> are the nsMsgDBFolder.cpp and OSXIntegration changes supposed to be in the
> diff?

No, they are not. Just ignore them. Sorry about that.

The inline notification bar looks pretty good. I'm adding Andreas to take a look at it as well because I think we'll need an icon and I want to change the layout a bit.

I'd like to reword and re-layout the notification bar a little bit. There are two audiences I'd like to address a little better. One is the audience of users who know what a return receipt is and the others who don't understand what it means.

For the users who don't know what this is about I think it's best if we avoid using the word "receipt" at least in the buttons as I feel like it's not quite clear what is happening. However for the users who understand this process I think we still want to use the wording of "return receipt" in the notification bar itself.

So a message more like this:

*The sender would like confirmation that you've received this message*
/$SENDER has requested a return receipt for this message/

Which emphasizes "confirmation" in the main text but also talks explicitly about return receipts in the secondary text.

And with actions buttons like these: ( Ignore ) ( Send Confirmation )

I like the word "Send" in the positive action because I think we want to confirm the notion that you're 'sending' something back.

Still need a bit of work on the exact text and layout but I think that's a bit closer.

Bryan: I like your re-layout.
Perhaps you should use "The sender would like to confirm that you have received this message".

(In reply to comment #25)
> Bryan: I like your re-layout.
> Perhaps you should use "The sender would like to confirm that you have received
> this message".

That sounds much cleaner, thanks!

Given bug 539066, should this bug be moved to MailNews Core (or even Thunderbird)?

Some quick thoughts about this:
* I think it would be good if we could keep the height of this (and other messages) on one line only, in order to save some height from other more important parts, such as the message itself. This would mean we need to shorten things down though.
* "requested" sounds very authoritive, a bit like a order, even though there is no harm in ignoring to do that (or is it?). I wonder if "asked for" is better.

This doesn't address the target audiences as well as Bryans idea, but it might work, and is a bit shorter:
"John Doe would like a confirmation that you got this e-mail and have asked for a return receipt (Ignore) (Send confirmation)"

Not sure if it's possible to say "to know" instead of confirmation, as it's good to repeat it in both the text and the button, but it would be shorter.

Created attachment 424433
patch v2

Updated the patch: removed unrelated changes, removed left-over test code.
The wording hasn't changed yet, because no decision has been made.

Comment on attachment 420602
screenshot

in general this is excellent. i'll add myself to the patch for the final wording review

Comment on attachment 424433
patch v2

For now if we assume the label is "The sender would like to confirm that you have received
this message" with buttons ( Ignore ) and ( Send confirmation ) I can ui-r+ this.

Later if we have a better layout for notification bars we can rearrange the ui fairly simply. Thanks!

Comment on attachment 424433
patch v2

Thx very much for the patch - this will be so much nicer than what we have now.

I think this diff is incomplete - when I try it, I get

JavaScript error: chrome://messenger/content/messenger.xul, line 1: SendMDNRespo
nse is not defined

Perhaps you were overzealous in removing diffs that weren't part of the patch?

Reviewing what is there:

+ var askUser = mdnGenerator.process(MDN_DISPOSE_TYPE_DISPLAYED, msgWindow, msgFolder,
+ msgHdr.messageKey, mimeHdr, false);
+ if (askUser) {
+ gMessageNotificationBar.setMDNMsg(mdnGenerator, msgHdr);
+ }

no need for the braces in the if clause. Can you use let instead of var for askUser (or get rid of the var entirely, though I can see that it makes the code a bit more readable).

+ * @param folder The folder the message is is

should be "is in".

+ * @returns true if the user need to be asked for permission
+ * false in other cases (whether the message was send or denied)

I think that should be "user needs to be asked", and "whether the message was sent or denied".

+ * May only be called when |process| returned |true|. Behavious is

Behavior

+ {
+ if (!m_autoSend) {
+ *needToAskUser = PR_TRUE;
+ rv = NS_OK;
+ } else {
+ *needToAskUser = PR_FALSE;
+ rv = CreateMdnMsg();
+ UserAgreed();
+ }
+ }

should use non K&R braces to be consistent. This also looks like it's 4 spaces indented instead of 2.

This comment was copied from somewhere else? It should be fixed. Or the code and comment just removed.

+ // do some complex action, check whether the action's results were what are expected here
+ // this is just an example, so we assert that true == true

set flag for wanted-thunderbird3.1

ping mvl for a new patch...

Created attachment 433753
patch v3

Patch updated to review comments. I indeed removed a bit too much in the previous version.
One thing I didn't change is the 2 vs 4 spaces in the .cpp file. That file is a mix of both, and I used the style form the function that I changed.

Comment on attachment 433753
patch v3

thx very much, this works. r=me, with some nits:

+ * @param autoAction true if the request action led to sending the mdn
+ * reply was an automatic action, false if it was user initated

"initiated"
+ * Must be called when the user was asked for permission and declined to
+ * sending the mdn reply.

"declined to send"

+ * May only be called when |process| returned |true|. Behavious is
+ * unspecified in other cases.

"Behavior"

Comment on attachment 433753
patch v3

>- rv = GetStringFromName(NS_LITERAL_STRING("MsgMdnWishToSend").get(),
>- getter_Copies(wishToSend));
>- rv = GetStringFromName(NS_LITERAL_STRING("MsgMdnIgnoreRequest").get(), getter_Copies(ignoreRequest));
>- rv = GetStringFromName(NS_LITERAL_STRING("MsgMdnSendReceipt").get(), getter_Copies(sendReceipt));

These strings need removing from the mail version of msgmdn.properties. sr=Standard8 with these removed.

In theory the suite/ ones need removing as well, but I've commented about that on bug 539066.

Created attachment 437900
patch v4, ready for checkin

Checked in: http://hg.mozilla.org/comm-central/rev/77fe4fa534da

(Note: I forgot to put the ui-review on the check in comment).

Much much better indeed, thanks to the authors of the patch.
Unfortunately, TB 3.1 no longer remembers whether the RR was sent.
It requests sending another one each time the e-mail is opened.

In general, for many good ideas about e-mail design, look at good old Eudora.
Eudora prompts for sending RR when closing the message with Send/Postpone/Ignore.

(In reply to comment #40)
> Unfortunately, TB 3.1 no longer remembers whether the RR was sent.
> It requests sending another one each time the e-mail is opened.
Please fill separate bug on this, cuz I don't see any problem with that.

(In reply to comment #40)
> Much much better indeed, thanks to the authors of the patch.
> Unfortunately, TB 3.1 no longer remembers whether the RR was sent.
> It requests sending another one each time the e-mail is opened.

Make sure you are using version 3.1.1 or later - there was a bug in 3.1 final that caused return receipts to be forgotten.