Closed Bug 28348 Opened 25 years ago Closed 23 years ago

No progress window when sending mail

Categories

(MailNews Core :: Composition, defect, P1)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: paulmac, Assigned: bugzilla)

References

(Depends on 1 open bug,
URL
)

Details

(Whiteboard: [nsbeta1+][PDT+]Have Fix)

Attachments

(4 files)

Progress window in 4.75
13.64 KB, image/gif
Details
another patch to cleanup the progress dialog
2.77 KB, patch
Details | Diff | Splinter Review
same than last time but this time with -u2w
3.83 KB, patch
Details | Diff | Splinter Review
patch, V2
5.18 KB, patch
Details | Diff | Splinter Review
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.
Reassign to ducarroz, cc jglick. We should use some "issues meeting" time to resolve this.
Assignee: phil → ducarroz
Observations and comments from 1st Mail Bug-o-Rama, users really like the 'message being sent' dialog, even if it only flashes very quickly.
QA Contact: lchiang → esther
Mark M15 for the flashy "Message Sent" dialog.
Status: NEW → ASSIGNED
Target Milestone: M15
Mass moving to M16 to get these off the M15 radar. Please let me know if this is really an M15 stopper.
Target Milestone: M15 → M16
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.
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.
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
moving to future.
Target Milestone: M17 → Future
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?
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.
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.
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.
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.]
Summary: No progress dialogue when sending mail → No progress window when sending mail
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.
Attached image Progress window in 4.75 —
*** Bug 55165 has been marked as a duplicate of this bug. ***
Add mail3 keyword
Keywords: mail3
changing component.
Component: Mail Window Front End → Composition
marking nsbeta1+ and moving to mozilla0.8. It's unclear what this feedback will look like, but based on usability tests, we need something.
Keywords: nsbeta1
Priority: P3 → P1
Whiteboard: [nsbeta1+]
Target Milestone: Future → mozilla0.8
Depends on: 65209
moving to mozilla0.9. We need to get the progress backend first.
Target Milestone: mozilla0.8 → mozilla0.9
change qa contact->myself and cc esther
QA Contact: esther → sheelar
Re-assigning bugs to varada.
Assignee: ducarroz → varada
Status: ASSIGNED → NEW
Depends on: 67161
Assignee: varada → ducarroz
reassign to myself
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.
Status: NEW → ASSIGNED
Depends on: 76225
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!
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...
Got it this time. Thanks.
moving to 0.9.1 to finish up the rest of this.
Target Milestone: mozilla0.9 → mozilla0.9.1
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?
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).
Thanks - sorry if I missed that before.
Depends on: 78445
Is this on by default now?
not hey... I'll see tomorrow if I can turn it on...
We need to fix bug 78445 before I can turn the progress dialog on by default!
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
Whiteboard: [nsbeta1+] → [nsbeta1+]Have Fix
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)
Target Milestone: mozilla0.9.1 → mozilla0.9.2
adding PDT+. Please check this in as soon as possible.
Whiteboard: [nsbeta1+]Have Fix → [nsbeta1+][PDT+]Have Fix
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.
Varada, can you review both patches (the one inline and the one attached)? Thanks.
r=varada
JF, can you attach -u diffs? I can't read contextual diffs. Thanks!
oops sorry!
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
ok, I will remove those line before check in.
Attached patch patch, V2 — — Splinter Review
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
r=varada
great, sr=mscott
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Fixed and checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Blocks: 182265
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: