151244 - return receipt should be processed after the message has loaded

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, enhancement)

Description

[Darin Fisher]

build id : 2002-06-04/04 linux

return receipt should be processed after the message has loaded.  currently, it
is displayed after loading only the headers of the new message.  so i am
confronted with a decision to either send or not send a return receipt without
the context of the message to help me make my decision.

for example, today i received a message from someone that i've never received a
message from before.  it had a reasonable looking subject line "bug# 138246" ...
it was addressed to me, with a cc to tever.  but, the message text looked like
SPAM.  so, i didn't want to say yes to the return receipt request on the basis
of this message looking a lot like SPAM.  turns out that i was looking at the
message body from a previous message that was SPAM.  after pressing CANCEL on
the return receipt dialog a new message appeared.  now, i wouldn't have minded
sending the return receipt.  oh well.

i hope this example makes the point that the context of the message body does
matter to users.  it should be loaded before the user is prompted to send a
return receipt.  thx!

Comment 1

[grylchan]

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)"

Comment 2

[Darin Fisher]

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

Comment 3

[grylchan]

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

Comment 4

[timeless]

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.

Comment 5

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

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

Comment 6

[u32858]

Regards
JG

Comment 7

[grylchan]

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

Comment 8

[Peter Asemann]

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.

Comment 9

[Sergio Del Franco]

(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.

Comment 10

[Fernando Fernandez]

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

Comment 11

[Alexandre Leclerc]

(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.

Comment 14

[Ivan Ičin]

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.

Comment 15

[Matth78]

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)

Comment 16

[Fernando Fernandez]

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

Comment 17

[Fernando Fernandez]

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

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

Comment 18

[Nikolay Shopik]

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 19

[Michael A. Pasek]

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.

Comment 20

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: 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...

Comment 21

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: screenshot

Screenshot of the proposed UI

Comment 22

[David :Bienvenu]

Comment on attachment 420601 [details] [diff] [review]
patch v1

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

Comment 23

[Michiel van Leeuwen (email: mvl+moz@)]

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

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

Comment 24

[Bryan Clark (DevTools PM) [:clarkbw]]

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.

Comment 25

[Sergio Del Franco]

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

Comment 26

[Bryan Clark (DevTools PM) [:clarkbw]]

(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!

Comment 27

[Serge Gautherie (:sgautherie)]

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

Comment 28

[Andreas Nilsson (:andreasn)]

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.

Comment 29

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: 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 30

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 420602 [details]
screenshot

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

Comment 31

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 424433 [details] [diff] [review]
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 32

[David :Bienvenu]

Comment on attachment 424433 [details] [diff] [review]
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

Comment 33

[[:Aureliano Buendía]]

set flag for wanted-thunderbird3.1

Comment 34

[David :Bienvenu]

ping mvl for a new patch...

Comment 35

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: 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 36

[David :Bienvenu]

Comment on attachment 433753 [details] [diff] [review]
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 37

[Mark Banner (:standard8)]

Comment on attachment 433753 [details] [diff] [review]
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.

Comment 38

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: patch v4, ready for checkin

Comment 39

[Mark Banner (:standard8)]

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

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

Comment 40

[André Pirard]

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.

Comment 41

[Nikolay Shopik]

(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.

Comment 42

[Mark Banner (:standard8)]

(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.