Closed Bug 151236 Opened 22 years ago Closed 14 years ago

mail is not POPed, hourglass shown in inbox and mail buttons

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: cristian.m.bogdan, Unassigned)

Details

Mozzila gets into a state where one cannot retrieve mail via SSL POP from
mail1.nada.kth.se (did not try IMAP). Pressing ctrl-T or choosing "get mail"
from the menu or from the Get Msgs button does not lead to a network connection.
Instead, an hourglass gets shown over the Inbox and over the mail buttons and
menus. Normal mouse actions work, despite of the hourglass.

The only way to get mail is to do a full restart. 

It is hard to reproduce the state, though I have some hunches:
- shift-delete on an Inbox message (only failed once) OR
- try to get mail when a mail-compose window is open (not sure about this one,
may simply be the one below) OR
- just open the mailer and wait (interact with the browser). after a while,
mozzila will get in that state

How I tried to avoid this
- reduce the number of inbox messages
- turn off automatic POP connections

Didn't work, so for now I have to restart mozilla every time I read mail...
OK, i tried more things
- moved away all Inbox subfolders 
- moved away all Inbox messages, started with no inbox (so mozilla generated a
new one)

however, recieving a message and doing shift-delete on it will almost surely
lead to no effect for all the next "get msgs"

i have a more precise description of getting to the hourglass effect: after "get
msgs" does nothing, just click on the mail account root, then on its inbox.
mozilla will not show the inbox, instead it will show the hourglass...
OK, since this was not allowing me to read email properly, i found this 
WORKAROUND:
I made the Inbox to _always_ be empty, by having a dummy filter at the end of
the filter list. 

Mozilla seems to compress the Inbox before getting mail and somehow that seems
to interfeer with actually connecting to the POP server, postponing it indefinitely

I'm still getting the strange hourglass effect on the pseudo-inbox I created,
but that doesn't seem to affect the connexion to the POP server.
i noticed the same problem. std pop3 (no ssl) account. hourglass remains somehow
and getmail is blocked. hourglass disappears as soon as you change the folder
(to sent or inbox subfolders/...) but reappears as soon as you switch back to
the inbox folder of ANY mail account.
I seem to have the same thing with Mozilla 1.1. I've just upgraded from Netscape
4.7, and as soon as I change mail folders, I can no longer receive new mail.
The mail indicator in the taskbar tells me there is mail waiting, but
I can't access it. Its very annoying...
I and some other people in my office have the same behaviour, since our samba
file server was switched to windows 2000. It may be a locking problem of the
mailbox file??
I have this problem since using Mozilla 0.98. Formerly it often helped to
compress the Inbox, to get the deadlock away. The last version of Mozilla 1.0
behaved better. But now with Mozilla 1.1 deAT I get this very very often. I have
to restart Mozilla many times a day to retrieve my POP3 emails.

Here some more technical information: I use Mozilla on a WindowsNT 4.0 PC
450MHz, my mailbox folders are on a Solaris which I reach through Samba. The
prolem is worth if the Inbox is bigger than say 10 messages. Then I have to
restart Mozilla after receiving once or twice mails. It shows this hourglass. It
shows in that popup bootom-right that I have _n_ new mails, but it does nothing
when asking to retrieve them. It really is a race condition, which results in a
deadlock on the inbox folder. It seems it wont even compress that folder any more.
We also have the same problem (Mozilla 1.1 and 1.2.1).

It affects only POP accounts (not IMAP).

I can reproduce it reliably by sending mail while I have a folder either 
in the pop server account or in "Local Folders" selected. It doesn't happen
if I have a folder on an IMAP server selected.  
Just a few days ago (fresh install of 1.2.0) it happened to me. Moving the mail
folder from a networked drive (where it worked before!) to a local drive solved
it. So it may also have something todo with (hidden) profile settings?!
more and more people start to be affected, and the workaround is pretty
complicated. basically people can't fetch their mail due to this... should we
raise the severity to major? 
I have the same problem with Mozilla 1.2.1 on RedHat Linux 7.3.

It happens to me as well. I'm using Linux RH 7.3 and my POP3-Inbox is networked
from a NFS file-server. Haven't tried it with storing the Inbox on the local
filesystem. Tested several Mozilla versions:  
0.99-7 (included on the RH 7.3 CD), 1.2a, 1.2.1, 1.3a, same behavior everywhere  
Have you noticed this bug is very related if not the same as 125664:   
http://bugzilla.mozilla.org/show_bug.cgi?id=125664
i would appreciate a severity change/solution for the problem - this is SO annoying!
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: olgam → message-display
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.