271108 - hourglass but no status

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[6e77a 70 6e 6e7a]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: version 0.9 (20041103)

My (kind of slow) server sorts incoming mail into many different folders and
allows me to access these folders through IMAP.  Mozilla and Thunderbird will
both check these folders for new messages in IMAP and show me an hourglass, but
they tell me nothing about what they're trying to accomplish.  I assume they are
either checking several of my folders and/or applying junk mail filters to some
messages.

Reproducible: Always
Steps to Reproduce:
1. Create lots of folders in IMAP
2. Select "check this folder for new messages" under each folder's properties
3. Set TB to check for mail once per minute
4. Put new email messages into the folders
5. Click on a folder to view its messages
Actual Results:  
You get an hourglass with no status message

Expected Results:  
It should tell me what it's doing and what percentage complete it is.

Comment 1

[Gervase Markham [:gerv]]

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/

Comment 2

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 3

[6e77a 70 6e 6e7a]

This bug is not resolved, it has ben _ignored_.  I encounter it every day, and I
have tried three different servers and two different client computers.

Comment 4

[David :Bienvenu]

Have you tried 1.5beta 2?

Comment 5

[6e77a 70 6e 6e7a]

I verified today that it is still happening in 1.5beta 2.  I believe it happens when the IMAP server is loading a folder with a huge number of messages.

Comment 6

[David :Bienvenu]

Attachment: fix case where you click on an imap folder which is already running a url

This might just be a related issue, but this fixes a problem where you click on an imap folder which is already currently having an operation run on it. In some cases, we would never remove the hourglass cursor because we only cleared the hourglass when the url finishes if we thought we were updating the folder:

http://lxr.mozilla.org/mozilla/source/mailnews/base/util/nsMsgDBFolder.cpp#1295

When the user clicks on an imap folder, we call nsImapMailFolder::UpdateFolder, but in some situations, we don't run a url, if the folder is currently running a url:

http://lxr.mozilla.org/mozilla/source/mailnews/imap/src/nsImapMailFolder.cpp#813

This patch changes that test to a test of whether we're running a url that will send a folder loaded notification when done. If not, we run the select url (which will get queued after the current op finishes).

Comment 7

[David :Bienvenu]

Attachment: fix case where we retried the url from an idle connection that was bad.

If we start to run a url, and get an error going out of IDLE, we weren't sending a start running notification because we thought we already had sent one. Then, since we didn't send a start running notification, when we finish and send a stop running notification, the url basically ignores it, because nsMsgMailNewsUrl::SetUrlState ignores a notification that matches it's known state, which would be "not running".

This may also help with spin on copy to imap sent folder, when an idle connection is re-used, and has gone bad.

Comment 8

[David :Bienvenu]

fixed on trunk and branch.