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)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.8
People
(Reporter: darin.moz, Assigned: mscott)
Details
Attachments
(1 file)
1.05 KB,
patch
|
darin.moz
:
review+
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•23 years ago
|
||
never mind this: "and, without a reload button." :P
-> imap
Component: Mail Window Front End → Networking - IMAP
Comment 2•23 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•23 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.
Status: NEW → ASSIGNED
Keywords: nsbeta1
Updated•23 years ago
|
Assignee: sspitzer → mscott
Status: ASSIGNED → NEW
Comment 4•23 years ago
|
||
reassigning to mscott.
Assignee | ||
Comment 5•23 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
Assignee | ||
Comment 6•23 years ago
|
||
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•23 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.
Reporter | ||
Comment 8•23 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?
Assignee | ||
Comment 9•23 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.
Reporter | ||
Comment 10•23 years ago
|
||
oh, right... i should have looked at your patch :-/
BTW: this looks unused:
+ nsCOMPtr<nsIMsgMailNewsUrl> mailnewsUrl = do_QueryInterface(m_url);
Assignee | ||
Comment 11•23 years ago
|
||
darin look 4 lines down.
Reporter | ||
Comment 12•23 years ago
|
||
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 13•23 years ago
|
||
Comment on attachment 61999 [details] [diff] [review]
potential fix --> invalidate entry when mock channel is canceled
sr=bienvenu
Attachment #61999 -
Flags: superreview+
Assignee | ||
Comment 14•23 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
now.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 15•23 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•23 years ago
|
||
By the way, my last comments were using jan29 commercial trunk build.
Assignee | ||
Comment 17•23 years ago
|
||
I don't think we do Laurel.
Comment 18•23 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•23 years ago
|
||
Looks ok iwth jan30 commerical trunk: win98, mac OS 10.1, linux rh6.2
Status: RESOLVED → VERIFIED
Comment 20•23 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.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•