Closed Bug 114571 Opened 23 years ago Closed 23 years ago

mail message shows blank if selected/unselected/selected quickly

Categories

(MailNews Core :: Networking: IMAP, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.8

People

(Reporter: darin.moz, Assigned: mscott)

Details

Attachments

(1 file)

sorry if this has already been reported, but with build 2001121008 i noticed that if i select a message in my imap account and then quickly select another message before the first loads, when i again click on the first message it'll show empty. and, without a reload button. i suspect the memory cache has an empty imap entry since i can "fix" the problem by emptying my memory cache and then revisiting the mail message. seems like the code should check for an empty cache entry before loading the imap message from the cache... or better yet ensure an empty cache entry never gets created.
never mind this: "and, without a reload button." :P -> imap
Component: Mail Window Front End → Networking - IMAP
sometimes it could be really nice if there was some way to "force reload" of a mail message. Something like CTRL+F5 on the mail/news message would force Mozilla to reget the message from the mail/news server...
This actually isn't that hard to reproduce. I tried it with a couple of larger emails and going back to the first shows a partially downloaded message with no way to get it back. The Reload menu item doesn't do anything.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Assignee: sspitzer → mscott
Status: ASSIGNED → NEW
reassigning to mscott.
we used to invalidate the cache entry if we didn't successfully finish streaming the message into the cache. I'll have to find out why this isn't working anymore.
Target Milestone: --- → mozilla0.9.8
This fixes the problem. When the mock channel is getting canceled, if we are currently writing into a cache entry then doom the cache entry. We are already doing this in nsImapIncomingServer::LoadQueuedUrl but that wasn't happening in this particular scenario. I have to investiage some more. I may be able to remove the code in the incoming server that does this now that cancel does it too.
Scott, the patch seems fine. I'm a little surprised that the code in LoadNextQueuedUrl isn't getting called - that makes me suspect that pseudo-interruption isn't working anymore (i.e., instead of gracefully stopping the message load, we might be killing the connection and starting a new one - changes to necko occasionally break this.) I'll check it out.
scott: with this patch wouldn't cached message loads get doomed if the user doesn't wait for the full message to display? is this ok?
hey darrin, actually the opposite is happening. Notice we only doom the entry if we AREN'T reading from the cache entry. This is a bit different from our previous stance with dooming entries in imap where we we currently always doom the entry regardless of how we are using the entry. With this patch, if we are reading from the cache and you click on another message, we won't doom the cached entry. Which is good because the next time you click on the interrupted message we won't hit the network again and we'll still re-use the valid mem cache entry.
oh, right... i should have looked at your patch :-/ BTW: this looks unused: + nsCOMPtr<nsIMsgMailNewsUrl> mailnewsUrl = do_QueryInterface(m_url);
darin look 4 lines down.
Comment on attachment 61999 [details] [diff] [review] potential fix --> invalidate entry when mock channel is canceled whoops! grin grin :-D r/sr=darin
Attachment #61999 - Flags: review+
Comment on attachment 61999 [details] [diff] [review] potential fix --> invalidate entry when mock channel is canceled sr=bienvenu
Attachment #61999 - Flags: superreview+
fix checked in. I also filed a spin off bug for investigating how we can doom cache entries for queued urls when we hit the stop button which isn't happening now.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: esther → laurel
I never was able to reproduce this where the message would show blank. In the case where the first message had an image (60-85 KB jpeg), when I returned to the first message, the image was incomplete and never was able to reload. I suppose the image case should be a separate bug or do you know if we already have one, Scott?
By the way, my last comments were using jan29 commercial trunk build.
I don't think we do Laurel.
New bug about incomplete image logged as bug 122491. Will do a little more testing on this one before marking verified.
Looks ok iwth jan30 commerical trunk: win98, mac OS 10.1, linux rh6.2
Status: RESOLVED → VERIFIED
Scott mentions a spin off bug for the outstanding issue. did you log one, if so what's the number? I found a similar bug (103540) that's being nominated and minused so I want to make sure we have all the information.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: