57678 - dataloss when "send" using offline POP

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[johng]

Repro:

- Use pop email, build 2000101709, win95
- Launch offline (either choose offline at profile manager screen or not - same
results either way)
- compose a message, press the "Send" button.

Bad Results:

- The mail compose window goes away, but nothing is saved or sent.  The email
you've just composed vanishes (dataloss) with the status indicator continously
indicating that it is trying to send the message, but it never stops trying, and
there is no way to recover the text of the message you just composed.

Expected Results:

- If the message is not sent, the mail compose window with the message should
reappear, and the user should at least be told that the message was not sent.
- Better would be to tell the user about the "send later" command (took me a
long time to discover that).
- Even better it would do the right thing and, if the user is offline, it would
just put it into the "Unsent messages" folder, or give the user the option in a
dialog pop-up box that says something like "Message could not be sent at this
time.  Do you want to put it into the Unsent Messages folder to deliver later or
do you want to reopen the message.

Whatever the work around, we should not accept dataloss.  Even after I
discovered the "Send Later" feature, I made the mistake of hitting the Send
button and lost all the work I did on a long email.

This kind of dataloss makes offline POP something less then dogfood, because I'm
bound to lose data be accidently hitting the Send button by habit.

Comment 1

[johng]

adding keywords dataloss and rtm.

Also adding keyword regression because I *think* this behavior used to lead to a
warning message that the email was not sent (though I wish that dialog mentioned
the "Send Later" command).  cc'ing verah incase there is discussion about the
contents of the dialog box.

Comment 2

[scottputterman]

we haven't attempted to support offline operations in mail. [marking rtm-]

Comment 3

[johng]

We don't support offline imap, but we DO support offline pop.  Correct?

renominating, and cc'ing kmurray

Comment 4

[kmurray1115]

Yeah, the critical thing here is that the user, when offline, will not think to
hit "Send Later" and will simply hit "Send" when offline, which reproduces the
behavior John indicates. If the user is offline, it makes sense 6hat, when they
send a message, they should get a dialog telling them what their options are.

Comment 5

[selmer (gone)]

Would it possibly be trivial to convert send to send later whenever we're
offline?  Otherwise we'd have to disable this feature entirely since we can't
make UI changes.

Comment 6

[Jean-Francois Ducarroz]

Yes, the fix should be very simple, we just need to detect that we are offline
and then usethe right send command... Should be a matter a few line of JS

Comment 7

[kmurray1115]

If we proceed with this, what would then happen once the user reconnects? Is 
there an indication then, that the user is required to take action and send the 
unsent messages?

Comment 8

[Jean-Francois Ducarroz]

Messages that you have send using "send later" go into the unsent message folder
in your local folder account. However, we never tell the user that there are
unsent messages in this folder, it's up to the user to select the command
"File/Send unsent messages" and if possible when he/she is online.

Comment 9

[Jean-Francois Ducarroz]

There is two ways to fix this problem without touching any localisable file:

1) The ugly one but very simple: Just before sending the message, I detect if we
are offline. If yes, I do a SendLater instead of a
Send now. The major problem with this solution is that the user won't be aware
that the message wasn't really send but was filed
into the unsent message folder. It my stay there for a while before the user
realize that! However, this is the most simple fix and
therefore very safe.

2) The best but more complex: When you are offline, I disable the menu item
"File/Send" and I rename the toolbar button Send to
"Send Later", also, I remove its tooltip which currently say "Send this message
now". When the user come back online, I do the
reverse. I have a fix for this solution.

Comment 10

[Jean-Francois Ducarroz]

Attachment: propose patch for solution #2

Comment 11

[kmurray1115]

I think #2 is a good proposal. LEt's get the signoff of UE berfore you proceed
though. Jen, comments?

Comment 12

[kmurray1115]

Adding I18N folks to the bug.

Comment 13

[Jean-Francois Ducarroz]

Also, the branch version of the compose window doesn't have a online/offline
icon on it's status line. I would have to add it, in order to let the user go
back online when composing a message by clicking on this icon. The Trunk version
already has this icon.

Comment 14

[Jean-Francois Ducarroz]

BTW, the patch I posted is for the trunk. I'll post soon a branch version.

Comment 15

[selmer (gone)]

Please get r=, sr=, and move to rtm+ so we have a chance of getting this in the 
release.

Comment 16

[Jean-Francois Ducarroz]

Attachment: same patch but for the branch (with a small optimization)

Comment 17

[jglick]

RTM Fix:
ducarroz's #2 seems ok for a quick fix. But this also involves a wording change 
(Send changes to Send Later) that I don't know if international will approve. 


Optimal/Post RTM Solution:
I like the "do the right thing" approach. If the user is offline and sends the 
message, we place a copy of the message in the "Unsent Messages" folder and 
popup a dialog informing the user what happened.  

If the user is offline, "Send" should be disabled in the File menu. "Send Later" 
becomes the behavior of the Send button. (wording of the Toolbar button doesn't 
need to change since we display a dialog).

The dialog should state (Vera/Robin, please re-word as you see fit): "You are 
currently offline. A copy of this message has been placed in the "Unsent 
Messages" folder. Once you are online, select "Send Unsent Messages" from the 
File menu.

How do we get this better fix in for 6.5? File a separate bug?

Comment 18

[Jean-Francois Ducarroz]

The wording change I did does not require any action from I18n folk as I reuse
the labe for the Send Later menu item.

Comment 19

[ekrock's old account (dead)]

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

Comment 20

[Scott MacGregor]

Clicking on yoru offline icon in the compose window isn't going to actually do
anything right? If you click on it from the compose window, do you indeed get
re-connected to the net?

So you are saying, if the state is offline we change the send button to Send
Later, and when you actually hit Send, we call some existing SendLater code.
This code already throws up the diaog telling the user what is going on?

assuming you've tested that clicking on the offline button actually does
reconnect you,

sr=mscott

Comment 21

[Jean-Francois Ducarroz]

>Clicking on yoru offline icon in the compose window isn't going to actually do
>anything right? If you click on it from the compose window, do you indeed get
>re-connected to the net?
The overlay take care of that. When you click on the offline icon, it call the same code than the offline icon in the 
browser window does. The only think that append if that we toggle the state of the flag offline in the ioService and 
I will later change the label of the send button (either Send or Send Later) 

>So you are saying, if the state is offline we change the send button to Send
>Later, and when you actually hit Send, we call some existing SendLater code.
>This code already throws up the diaog telling the user what is going on?
Send Later has never threw a dialog. We just "silently" file the message under local/unsent message

>assuming you've tested that clicking on the offline button actually does
>reconnect you,
Yes it does. However others windows want redraw their offline icon to show the new state. This is not a new 
problem but rather a generic problem that every window has with the offline indicator as we cannot register a 
listener yet!

Comment 22

[Jean-Francois Ducarroz]

R=varada (by email). Now that I get all the needded reviews, I move this bug to [rtm+]

Comment 23

[Phil Peterson]

PDT marking [rtm need info] because we would like the localization folks to
agree that this change is ok. It probably is ok, but we should still double check.

Comment 24

[msanz]

I have one question; at some point in the report you mention "deleting the
tooltip", is this deleting a string? I'm almost positive this will break the
language packs.
As for changing "send" to "send later", approved. I will forward this bug to the
localization engineers and to Dublin folks. Thanks for checking!

Comment 25

[Jason Eager]

Since the localization people say it's ok, it should go back to rtm+.

Comment 26

[Jean-Francois Ducarroz]

I didn't delete any string. What I did is to remove/disable the tooltip attached
to the send/send later button when we are offline as the tooltip meanings in
that case is wrong. However when we are online, I put back the tooltip.

Comment 27

[Phil Peterson]

Marking rtm+. This bug is in candidate limbo

Comment 28

[Jean-Francois Ducarroz]

Fix checked in the trunk only.

Comment 29

[msanz]

Thanks for the explanation, Jean-Francois.

Comment 30

[selmer (gone)]

rtm-, not a stop ship.

Comment 31

[Jason Eager]

Umm..no. It would be better to ship WITHOUT the "Work Offline" feature then to
subject people to unexpected MAJOR dataloss like this.

There are NO other mail clients that LOSE the message when the person is
offline, they ALL queue it.

Moving back to RTM+ and waiting for PDT's justification that major dataloss like
this isn't a "stop ship".

Comment 32

[Jim Roskind]

JCE: Again, please stop moving ratings involving RTM.  This field is meant to
communicate between Netscape managers and contributors.  You are hindering our
work, and making it difficult to ship a product.
This bug was marked RTM-minus on Friday.
Since this is fixed on the trunk, and won't be fixed in the Netscape RTM
release, I'm going to mark the bug fixed.
It already has a release not keyword for RTM.

Comment 33

[Asa Dotzler [:asa]]

OK, in verifying this in the trunk I see a couple of problems but the dataloss
bug is fixed.  The mailnews online/offline icon doens't reflect the offline
state. The Send Unsent Messages menu item is active even when you are still in
offline mode and we get no dialog that it wasn't send if you try to send unsent
while still offline.  Also the unsent message should have a Send button on it
when you open it in a standalone window.
This dataloss bug is Verified FIXED in 110604 win32 mozilla trunk build on NT4,
110604 mac mozilla trunk build on OS9 and 110606 linux mozilla trunk build on
RedHat6.2.  The "Send" button becomes a "Send Later" button and the message is
copied to the Unsent folder.  Setting bug to Verified and removing vtrunk keyword.