Closed
Bug 28348
Opened 25 years ago
Closed 23 years ago
No progress window when sending mail
Categories
(MailNews Core :: Composition, defect, P1)
MailNews Core
Composition
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: paulmac, Assigned: bugzilla)
References
(Depends on 1 open bug, )
Details
(Whiteboard: [nsbeta1+][PDT+]Have Fix)
Attachments
(4 files)
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
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.
Comment 1•25 years ago
|
||
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.
Assignee | ||
Comment 3•25 years ago
|
||
Mark M15 for the flashy "Message Sent" dialog.
Status: NEW → ASSIGNED
Target Milestone: M15
Comment 4•25 years ago
|
||
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
Comment 5•25 years ago
|
||
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.
Comment 7•25 years ago
|
||
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
Comment 14•24 years ago
|
||
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•24 years ago
|
||
Comment 16•24 years ago
|
||
*** Bug 55165 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
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•24 years ago
|
||
moving to mozilla0.9. We need to get the progress backend first.
Target Milestone: mozilla0.8 → mozilla0.9
Comment 22•24 years ago
|
||
Re-assigning bugs to varada.
Assignee: ducarroz → varada
Status: ASSIGNED → NEW
Assignee | ||
Updated•24 years ago
|
Assignee: varada → ducarroz
Assignee | ||
Comment 23•24 years ago
|
||
reassign to myself
Assignee | ||
Comment 24•24 years ago
|
||
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
Comment 25•24 years ago
|
||
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!
Assignee | ||
Comment 26•24 years ago
|
||
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•24 years ago
|
||
Got it this time. Thanks.
Comment 28•24 years ago
|
||
moving to 0.9.1 to finish up the rest of this.
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 29•24 years ago
|
||
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?
Assignee | ||
Comment 30•24 years ago
|
||
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•24 years ago
|
||
Thanks - sorry if I missed that before.
Comment 32•24 years ago
|
||
Is this on by default now?
Assignee | ||
Comment 33•24 years ago
|
||
not hey... I'll see tomorrow if I can turn it on...
Assignee | ||
Comment 34•24 years ago
|
||
We need to fix bug 78445 before I can turn the progress dialog on by default!
Assignee | ||
Comment 35•24 years ago
|
||
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
Updated•24 years ago
|
Whiteboard: [nsbeta1+] → [nsbeta1+]Have Fix
Comment 36•24 years ago
|
||
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
Comment 37•23 years ago
|
||
adding PDT+. Please check this in as soon as possible.
Whiteboard: [nsbeta1+]Have Fix → [nsbeta1+][PDT+]Have Fix
Assignee | ||
Comment 38•23 years ago
|
||
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.
Assignee | ||
Comment 39•23 years ago
|
||
Assignee | ||
Comment 40•23 years ago
|
||
Varada, can you review both patches (the one inline and the one attached)?
Thanks.
Comment 41•23 years ago
|
||
r=varada
Comment 42•23 years ago
|
||
JF, can you attach -u diffs? I can't read contextual diffs. Thanks!
Assignee | ||
Comment 43•23 years ago
|
||
oops sorry!
Assignee | ||
Comment 44•23 years ago
|
||
Comment 45•23 years ago
|
||
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
Assignee | ||
Comment 46•23 years ago
|
||
ok, I will remove those line before check in.
Assignee | ||
Comment 47•23 years ago
|
||
Assignee | ||
Comment 48•23 years ago
|
||
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•23 years ago
|
||
r=varada
Comment 50•23 years ago
|
||
great, sr=mscott
Comment 51•23 years ago
|
||
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Assignee | ||
Comment 52•23 years ago
|
||
Fixed and checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 53•23 years ago
|
||
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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•