mail message shows blank if selected/unselected/selected quickly

VERIFIED FIXED in mozilla0.9.8


17 years ago
10 years ago


(Reporter: darin.moz, Assigned: mscott)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
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.

Comment 1

17 years ago
never mind this: "and, without a reload button." :P

-> imap
Component: Mail Window Front End → Networking - IMAP

Comment 2

17 years ago
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...

Comment 3

17 years ago
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.
Keywords: nsbeta1


17 years ago
Assignee: sspitzer → mscott

Comment 4

17 years ago
reassigning to mscott.

Comment 5

17 years ago
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

Comment 6

17 years ago
Created attachment 61999 [details] [diff] [review]
potential fix --> invalidate entry when mock channel is canceled

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.

Comment 7

17 years ago
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.

Comment 8

17 years ago
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?

Comment 9

17 years ago
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.

Comment 10

17 years ago
oh, right... i should have looked at your patch :-/

BTW: this looks unused:

+    nsCOMPtr<nsIMsgMailNewsUrl> mailnewsUrl = do_QueryInterface(m_url);

Comment 11

17 years ago
darin look 4 lines down. 

Comment 12

17 years ago
Comment on attachment 61999 [details] [diff] [review]
potential fix --> invalidate entry when mock channel is canceled

whoops! grin grin :-D

Attachment #61999 - Flags: review+

Comment 13

17 years ago
Comment on attachment 61999 [details] [diff] [review]
potential fix --> invalidate entry when mock channel is canceled

Attachment #61999 - Flags: superreview+

Comment 14

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → FIXED


17 years ago
QA Contact: esther → laurel

Comment 15

17 years ago
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?

Comment 16

17 years ago
By the way, my last comments were using jan29 commercial trunk build.

Comment 17

17 years ago
I don't think we do Laurel. 

Comment 18

17 years ago
New bug about incomplete image logged as bug 122491.
Will do a little more testing on this one before marking verified.

Comment 19

17 years ago
Looks ok iwth jan30 commerical trunk: win98, mac OS 10.1, linux rh6.2

Comment 20

17 years ago
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.