28348 - No progress window when sending mail

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P1)

Description

[Paul MacQuiddy]

This is more of a design issue than anything else, but I miss the progress 
dialogue that came up in 4.x when you send a message. 

With the current mail client, I don't feel very confident that my mail has been 
sent successfully. The only feedback I get is the throbber starting and stopping 
in the mail window, and you only see that if you that is the window directly 
underneath the mail compose window, which is not always the case if you are 
switching windows a lot.

I'd also be curious if testing has been done sending very large attachments, and 
shutting down all visible windows before the mail is actually fully sent. It 
seems it would be weird to have something still going on in the background.

I imagine this should be assigned to a marketing or usability person.

Comment 1

[Phil Peterson]

Reassign to ducarroz, cc jglick. We should use some "issues meeting" time to
resolve this.

Comment 2

[jglick]

Observations and comments from 1st Mail Bug-o-Rama, users really like the 
'message being sent' dialog, even if it only flashes very quickly.

Comment 3

[Jean-Francois Ducarroz]

Mark M15 for the flashy "Message Sent" dialog.

Comment 4

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 5

[scottputterman]

I'd be surprised if we do this.  We can probably move this out a few milestones,
though he does have a good point about not really being able to see the feedback.

Comment 6

[jglick]

I think if we don't do this one we will really hear about it and it will 
reflect badly on the product. Even if that dialog comes and goes really quickly, 
it gives users the sense that something has happened. I think if we don't have 
it, users will doubt if their message was really sent or not. That doubt will 
reflect badly on our product.

Novice users have even requested the feature of a modal dialog that pops up when 
a message is sent, so they can be REALLY sure it was sent!

cc'ing Lake so she can maybe relate some of her experiences with this in the 
usability lab.

Comment 7

[selmer (gone)]

Mass moving M16 to M17 - look for nsbeta2 before anything else.

Comment 8

[scottputterman]

moving to future.

Comment 9

[jglick]

I disagree with marking this one future. This is important feedback to the user 
that indicates that something is really happening when they click the "Send" 
button.  As noted above (please see above comment) this was one of the top 
items requested during bug-o-ramas.  Sol, comments?

Comment 10

[sol]

OK - just to muddy the waters ...

There is a big advantage in not presenting a status dialog on a Send operation:
Seamonkey "feels" really fast, since the compose window dismisses, and the user
can go on with their work, while the Send operation processes in the background.

I would not want to introduce a status dialog that interupts the user's work -
it makes the product feel a lot slower.

The ideal solution would be some confirmation (perhaps in the 3-pane window)
that confirms the message has been sent, but allows the user to continue
managing their email.

A status dialog is most useful when the user first begins using the product.
After the user "trusts" the product to send email messages, confirmation of
message send is less critical.

Comment 11

[jglick]

The status dialog in 4.x comes and goes so quickly (unless you have a huge file) 
that it doesn't interupt the user's work.  I don't think having this dialog 
will make users think SeaMonkey isn't fast.  

In fact, the 4.x dialog is so fast I would guess many users don't even 
consciously notice it.  But subconsciously, you see the action happen (and it 
happens fast - what a fast product), and if you do want to watch for it you can. 
 And if the message is taking a longer time to send, you see it.  I don't think 
advanced users are bothered by this dialog, they probably don't even notice it 
anymore.

Status/feedback that the message was send in a different part of 3 pane mail is 
an idea, but i'm not sure users will notice it.  Its already been shown that 
people don't notice most of the messages that appear in the status bar.

Comment 12

[sol]

I'm not sure that I agree that the progress dialog "comes and goes so quickly" 
for most users. If you're accessing the server using a dial-up connection (which 
the majority of our users still have), the dialog stays up for some time.

I do agree, however, that users are not very aware of the messages we provide in 
the status bar.

Comment 13

[Matthew T (active 1999-2002)]

What version of 4.x has a progress window? All the versions I've used just 
disable the composition toolbar and the message body, and use status bar text in 
the composition window before the composition window disappears. This is nice, 
because it is visually akin to an envelope sealing up before your eyes and flying 
off into the distance. If this is too slow for the user, they're probably the 
sort of user who should be running their e-mail program offline and sending all 
their messages at once anyway.

It's also important to leave the composition window open until the message has 
been fully sent, otherwise you're in trouble if there's an error in sending and 
the user needs to save the message or whatever for trying again later.

So the only place where you'd want a separate progress window is when choosing 
`Send Unsent Messages' -- in which case it would be the beginnings of a proper 
`Synchronize' progress window, for when we get proper off-line support again, or 
a `Send & Receive' command like Outlook has. Something like this:

+-------------------------------------------+
| Sending & Receiving ::::::::::::::::::::::|
+-------------------------------------------+
| Messages remaining to be sent:          2 |
|                                           |
| [#######)::::::::::::::::::::] (  Stop  ) |
|                                           |
| V Time remaining: less than 5 seconds     |
|                                           |
|  Sending message: "UI spec for progre..." |
|           Status: waiting for server      |
|                                           |
+-------------------------------------------+

[Resummarizing: we want a progress window, not a dialog. Progress windows are for 
showing progress, dialogs are for making decisions.]

Comment 14

[jglick]

I'm using 4.75 for windows.  The progress window comes and goes really fast.  If 
the message is large (has an attachment) it hangs around longer.  Even when it 
comes and goes quickly, I think that it is re-assuring to users that their 
message has been sent. 

Comment 15

[jglick]

Attachment: Progress window in 4.75

Comment 16

[Asa Dotzler [:asa]]

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

Comment 17

[jglick]

Add mail3 keyword

Comment 18

[scottputterman]

changing component.

Comment 19

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8.  It's unclear what this feedback will
look like, but based on usability tests, we need something.

Comment 20

[scottputterman]

moving to mozilla0.9.  We need to get the progress backend first.

Comment 21

[Sheela Ravindran]

change qa contact->myself and cc esther

Comment 22

[varada]

Re-assigning bugs to varada.

Comment 23

[Jean-Francois Ducarroz]

reassign to myself

Comment 24

[Jean-Francois Ducarroz]

I have checked in the progress dialog code but due to a bug in xpapp about modal
dialogs, I cannot turn it on by default. If you want to have a pick at the
progress dialog, you need to set the following pref to true in your perfs.js file:

mailnews.show_send_progress

Be award that if something goes wrong during the send, you might freeze.

Comment 25

[kmurray1115]

JF - this didn't work for me. What is the *exact* entry in prefs.js? 

I tried:
user_pref("mailnews.show_send_progress")

and:

user_pref("mailnews.show_send_progress", true);

 and neither worked. Help!

Comment 26

[Jean-Francois Ducarroz]

it's:
user_pref("mailnews.show_send_progress", true);

But your profile should not be currently in use when you edit the prefs.js file. Also be sure you edit the right one...

Comment 27

[kmurray1115]

Got it this time. Thanks.

Comment 28

[scottputterman]

moving to 0.9.1 to finish up the rest of this.

Comment 29

[kmurray1115]

jf - this is great. I have one comment though. It looks like the status bar
doesn't actually move. The dialog box comes up fine, but when the message send
is in progress, It says "Sending Message, and then "Copying to Sent Folder," but
the status bar doesn't reflect the progress (it stays empty). I would definitely
expect to see the bar *fill up* as the send progresses, from left to right, as
in 4.x. I tried it with messages with large attachments to see if I was just not
giving the operation enough time to occur. Are you seeing this?

Comment 30

[Jean-Francois Ducarroz]

Right, once mscott finish is part in smtp & nntp (he has a bug logged for that),
we should the progress metter moving like in 4.x. Also you are currently not
able to cancel the smtp process (when we physically send the mesage).

Comment 31

[kmurray1115]

Thanks - sorry if I missed that before.

Comment 32

[kmurray1115]

Is this on by default now?

Comment 33

[Jean-Francois Ducarroz]

not hey... I'll see tomorrow if I can turn it on...

Comment 34

[Jean-Francois Ducarroz]

We need to fix bug 78445 before I can turn the progress dialog on by default!

Comment 35

[Jean-Francois Ducarroz]

now that I will checkin the fix for the remaining blocker, I will turn on by
default the progress dialog:

Index: mozilla/modules/libpref/src/init/mailnews.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/init/mailnews.js,v
retrieving revision 3.106
diff -w -u -2 -r3.106 mailnews.js
--- mailnews.js	2001/05/03 21:24:48	3.106
+++ mailnews.js	2001/05/10 22:21:49
@@ -328,3 +328,3 @@
 pref("mail.content_disposition_type", 0);
 
-pref("mailnews.show_send_progress", false); //Will show a progress dialog when
saving or sending a message
+pref("mailnews.show_send_progress", true); //Will show a progress dialog when
saving or sending a message

Comment 36

[Marek Z. Jeziorek]

changing TM to 0.9.2 per PDT meeting (you can check the fix into 0.9.1 trunk
until Friday, 18/May/01 or after the 0.9.2 is open)

Comment 37

[scottputterman]

adding PDT+. Please check this in as soon as possible.

Comment 38

[Jean-Francois Ducarroz]

I'll attach another patch, this one doesn't replace the previous one. It's just 
about removing the cancel button and the keep window open check box as those 
functionalities doesn't work correctly yet.

Comment 39

[Jean-Francois Ducarroz]

Attachment: another patch to cleanup the progress dialog

Comment 40

[Jean-Francois Ducarroz]

Varada, can you review both patches (the one inline and the one attached)? 
Thanks.

Comment 41

[varada]

r=varada

Comment 42

[Scott MacGregor]

JF, can you attach -u diffs? I can't read contextual diffs. Thanks!

Comment 43

[Jean-Francois Ducarroz]

oops sorry!

Comment 44

[Jean-Francois Ducarroz]

Attachment: same than last time but this time with -u2w

Comment 45

[Scott MacGregor]

The changes look ok, but I'd rather us get rid of the lines for the checkbox
instead of commenting them all out. I guess that's just me 'cause I don't think
the checkbox is very helpful and I doubt we ever implement it.

Certainly commenting out the cancel button is okay because we are going to be
putting that back in if I ever get permission to land my back end stuff. 

sr=mscott

Comment 46

[Jean-Francois Ducarroz]

ok, I will remove those line before check in.

Comment 47

[Jean-Francois Ducarroz]

Attachment: patch, V2

Comment 48

[Jean-Francois Ducarroz]

ok, this time I have fully removed the code to keep the window open, that will 
give us a smaller JS therefore that will speep up a little bit the load of the 
window :-)

Varada, can you review it again? Thanks

Comment 49

[varada]

r=varada

Comment 50

[Scott MacGregor]

great, sr=mscott

Comment 51

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 52

[Jean-Francois Ducarroz]

Fixed and checked in

Comment 53

[Chad Austin]

verified

win2k - 2001061504
linux - 2001061508
macos - 2001061508

oh my god, that was painful...  MacOS mailnews is so crash today it took about
seven tries to actually *send* a message without crashing.