If I interupt email message loading by clicking to another message - repeatedly - I crash. Note: I had to switch messages about a dozen times before I could bring down Mail, and I am running IMAP. Build ID - 2000-03-10-13 commercial, on WinNT Steps to reproduce: 1. Launch Seamonkey 2. Launch Mail (and authenticate if necessary) Note: I am running IMAP 3. Find some large messages in your Inbox 4. Click on a large message in the thread pane, and before it has completed loading, click to another message in the thread pane. Repeat this many times. Expected: Message displayed in message pane stops loading when you click to another message, and newly selected message begins loading (every time). Actual: Message displayed in message pane generally stops loading when you click to another message, but: (a) sometimes the message pane gets out of sync with the thread pane - this can be remedied by slowing down your clicking (b) after repeatedly clicking to another message in the thread pane before the previous message is loaded - you crash. I estimate it took me between 10 and 12 messages before I crashed the app.

Talkback incident ID 6644791. Trigger Reason: Access violation Thread ID: 228 Call Stack: (Signature = 0x0c08b80a 355968a7) 0x0c08b80a PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 557] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 520] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1013] USER32.dll + 0x1820 (0x77e71820)

Phil found a way to weasel out of owning this bug. Reassigning.

Wouldn't stop beta2 for this.

I think this will be very easy to run into and it's a crash.

"Note: I had to switch messages about a dozen times before I could bring down Mail" doesn't sound that easy to me. Assigning to bienvenu, looks similar to the delete problems.

Lisa, I'd appreciate it if you could come up with an easily reproducible test case for this. I tried it for an hour without any luck.

I will do so on Monday.

This is also on my list of things to do, but I didn't quite get to it last week. Will be back on Tuesday and try if Lisa doesn't get a chance.

Putting on [beta2-] radar.

I can't get it to crash using 2000-04-18-09m16 commercial build on NT 4.0. After trying for quite awhile, I was easily able to get into the state where the message pane was mismatched to thread pane selection and throbber was stopped/Document Done. I could select another message in the thread pane and most often it would load (correctly), but sometimes either nothing would load (it would stay on the last displayed contents in message pane) or it would load a message other than what I selected (it would load a message which I'd selected previously, but had interrupted then selected another message ... so the worst I got was continuing mismatched thread to message pane. I could select another folder and return and all was hunky dory. This was all done on a slow machine, 166mhz.

Mail Review recommends this bug as beta2 stopper. Adding nsbeta2 keyword.

Putting on [nsbeta2+] radar for beta2 fix.

pretty hopeless. I can't reproduce this at all. I would recommend not nsbeta2+ myself.

I can reproduce a few problems in this area if I just cursor down through a bunch of small messages. It turns out that we are dropping the imap connection all the time if you do this, because the doc loader now interrupts the mock channel, which causes us to think we've been stopped, even if we should just be pseudo-interrupted (which means we just wait for the current chunk of the current message to finish loading and then load the next message. For a small message, this just means wait for the current message to finish loading.) I'm trying to fix this by paying attention to the m_pseudoInterrupted flag in DeathSignalReceived (ignoring the mock channel status if we've been pseudo interrupted). This makes things better, but I'm still working on it. I also found that we end up with a lot of idle connections that are not in the selected state but have the inbox as their selected mailboxname - this confuses the connection cache, so I changed GetSelectedMailboxName to make sure the connection is actually in the selected state.

Oh dear! That's not good. I could have sworn I added code to play nicely using the psuedo interrupted flag in conjunction with incoming cancel requests on the mock channel...I guess I didn't. my bad. =(

OK, I have a basic fix for this, involving the stuff mentioned above, and the crucial change of NOT running queued urls that have already had their mock channel cancelled - they've basically been pseudo interrupted without ever getting a chance to run, so loadqueuedurl just removes them and looks for the next url to run. This works so that we never kill connnections when cursoring through a bunch of messages. I do have a strange problem where m_channelListener is null in nsImapProtocol::BeginMessageDownLoad now, that I'm trying to track down.

OK, I've figured out the m_channelListener problem. It is an interaction with the memory cache. The pseudo interrupted message loads that never got a chance to run still have memory cache entries because nsImapMockChannel::AsyncRead is called before the imap url is ever run, and creates a cache entry. Later, when we try to load the message for real, the storage stream associated with the memory cache entries think there's a write in progress (mWriteInProgress is TRUE) so it fails to create an output stream. This means the call to InterceptAsyncRead fails to create a channel listener. So, somehow, I need to either remove the cache entry when we decide not to run the url (if it's 0 length, I guess) or I need to somehow convince the cache entry that there's not a write in progress, either when I decide not to run the url, or when I try to run it again.

well, the cache code STILL doesn't allow you to remove entries. That's very unfortunate. I'm probably screwed unless I can find some way to trick the cache entry into thinking it's not being written to.

my mistake - apparently, you tell the cache entry to delete itself, instead of telling the cache manager to delete the entry. That's just a guess, but it's worth a try. It seems like perhaps the correct way of handling this is to abort the mock channel in such a way that makes the cache do the right thing and realize the cache entry is bogus. The mock channel is already getting cancelled - I'm not sure what else should happen.

note that all of the above discussion is not for the crash - I've not been able to reproduce the crash.

fix checked in.

No problems seen using IMAP, NT 4.0 with july13 commercial build.