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: