If you delete many imap messages, you can get into a state where deletes stop working until you click away to another message or wait or something (hard to say). It may have to do with deleting messages quickly, I'm not sure. Cc'ing scottip so he can mark any bugs he gets on this dups - similarly for jeff and mscott.
accepting - could be related to 21574
Status: NEW → ASSIGNED
Target Milestone: ---
For me, I notice that whenever I delete spam email which contains attached web pages that haven't finished loading yet, I can never delete any other mail afterwards.
OK, what's happening here is that somehow the m_copyState that the nsImapMailFolder holds onto during a copy is not getting nulled out when this bug happens. Then, nsImapMailFolder::InitCopyState errors out and delete is disabled. It doesn't really seem to matter what the messages you delete are; I ran into it with bugsplat notifications. I'm not sure what's causing it not to get cleaned up, and it'll be tricky to catch it in the act.
*** Bug 31389 has been marked as a duplicate of this bug. ***
My suspicion is that is related to biff going off while deleting messages. I made my biff interval 5 seconds, and ran into this problem within 20 seconds. There's something wrong with the connection cache/ url queueing mechanism, I'm pretty sure. We start the delete, but biff fires, and the delete url never runs, so we don't clear the move/copy state. It's not quite that simple, but I think that's roughly the problem.
that is a possibility. I vaguely remember turning biff off and having this still occur. I think it has to do with displaying messages. If I close the thread pane so that messages don't load, I never see this problem. If I have the thread pane open I run into this within 50 deletes and lately it's been within 10 deletes.
yes, displaying messages does seem to be involved (because it is another url that gets run), but biff makes it much much easier to create this, at least for me.
OK, I've found one cause of this - when nsImapProtocol's m_imapMiscellaneousSink is NULL at the end of ProcessCurrentUrl, we don't call SetUrlState, which means we don't know to clear the copy state on the nsImapMailFolder. In the one case I ran into, all the sinks are null. There may be some race condition which causes the sinks to get nulled out. Or, less likely, the sinks aren't initialized. Neither of these seems possible by inspection, but one of them must be happening.
So I can fix this by adding two lines to the start of nsImapProtocol::ProcessCurrentURL(): if (!m_imapMiscellaneousSink) SetupSinkProxy(); // try this again. Evil, but I'm desperate. This is probably not good, because it'll cause SetupSinkProxy to be called from an imap thread, and not the ui thread as it should be. But it does fix the problem and seems to work. I'll try to find a better fix.
marking P1 as one of my hot bugs per Steve's request. I do have a fix in hand.
Priority: P3 → P1
Target Milestone: --- → M16
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
This is OK for me using: 2000-04-14-10m16 commercial build NT 4.0 2000-04-14-11m16 commercial build mac OS 9.0 2000-04-14-09m16 commercial build linux rh6.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.