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!
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
Last Resolved: 8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.