Closed
Bug 209894
Opened 22 years ago
Closed 11 years ago
[RFE] Lengthy actions abort too easily and confuse UI
Categories
(SeaMonkey :: MailNews: Message Display, enhancement)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: krellan, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
When Mozilla's email client is working on a lengthy operation, there are two
problems:
1) It aborts much too easily, and inconsistently. Clicking anywhere in the UI
could abort the operation, or not. It seems random which UI elements cause an
abort and which UI elements allow it to continue. Generally, clicking another
email folder will guarantee an abort, but this is not 100%.
2) The UI, especially the status bar, gets confused when two or more lengthy
operations are taking place at the same time. It will often leave a message in
the status bar without removing it when the task is done. This is a symptom of
overlapping tasks.
This is a generalization of bug 188330.
Examples of lengthy operations include:
* Downloading the list of messages from an email server
* Downloading a very large message
* Decoding an attachment
* Running filters on a folder
* Running junk-filtering on a folder, including moving of junk messages
* Moving messages from one folder to another
* Uploading outgoing email
* Uploading email to a server-side folder on an IMAP server
When doing one of these long operations, Mozilla can't do anything else without
aborting. It would be very nice to be able to view an email while still
downloading other emails in the background, for instance.
The Eudora email client has the "tasks" display that can be turned on. Every
lengthy operation is shown as one line, with its own progress bar, that can be
aborted independently of other tasks. It is similar in appearance and
functionality to Mozilla's Download Manager. This UI for handling lengthy email
operations is great, and would be fantastic to have in Mozilla!
Also, a benefit of this is that would allow tasks to be more atomic, and
separated easily. It is messy to have to clean up after Mozilla when it moves
only half of a folder, or filters only half of the messages. Mozilla appears to
get confused now when multitasking, and a better UI would help to clear this up,
and make it apparent to the user what is going on.
Reproducible: Always
Steps to Reproduce:
1. Start a lengthy operation, such as downloading and filtering mail.
2. Click on another email folder.
3. The download/filter is interrupted!
Actual Results:
See above.
Expected Results:
Mozilla should have continued to do the lengthy operation in the background, and
still let me use the UI.
If two or more lengthy operations are started at the same time, the status bar
should not be confused with overlapping status messages.
A better UI would allow me to view each task individually, perhaps in a view
similar to the Download Manager, with one row for each task, and allow me to
abort one task without aborting them all.
| Reporter | ||
Comment 1•22 years ago
|
||
Sorry, I meant to say this is a generalization of bug 168330, not 188330.
Updated•21 years ago
|
Product: Browser → Seamonkey
Updated•21 years ago
|
Assignee: sspitzer → mail
Comment 2•20 years ago
|
||
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
| Reporter | ||
Comment 3•20 years ago
|
||
Yes, this bug still happens (the progress UI in Thunderbird is essentially
unchanged).
This is especially noticeable when dealing with slow IMAP servers, and/or when
offline synchronization is enabled. It's very easy to accidentally click the
wrong thing and cancel a long operation you had in progress, such as
auto-filtering of incoming mail!
Updated•17 years ago
|
QA Contact: esther → search
Updated•17 years ago
|
Assignee: mail → nobody
QA Contact: search → message-display
Comment 4•11 years ago
|
||
NOT reproducible with EN-US Seamonkey 2.33.1 (German Language pack) Gecko/20100101 Build 20150321194901 (Default Theme) on German WIN7 64bit
This one has never been reproduced with SeaMonkey?
Additionally I can't imagine what the core of this report or request might be
a) MailNews blocked as long as a time consuming process (like "Compact Folders"
is active? Indeed, SeaMonkey usability if time consuming process processes
(may be with high CPU consumption) are active is not optimum, but currently
I can't see any relation of this problem to this report.
b) time consuming processes become aborted by other access to UI or even
simple click on screen: I cna't reproduce this.
So I close this one, because it's not reproducible and because description does not allow to reproduce the problem.
Please feel free to reopen this Bug if you still can reproduce with a current SeaMonkey version and a current OS and if you can contribute a step by step instruction what will allow to reproduce the problem.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•