Open Bug 168330 Opened 22 years ago Updated 4 years ago

downloading truncated message is easily aborted due to doc shell/doc loader interrupting the url

Categories

(MailNews Core :: Networking, defect)

1.9.0 Branch
x86
All
defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: pali, Unassigned)

References

Details

(Whiteboard: [dupeme])

Downloading of message that was truncated due to account settings/disk space
limit is very easily aborted by viewing another message. If I loose the message
from preview pane the download is immediately aborted. This is very bad, because
when I'm waiting for some large (that's why I set the disk space limit) message
to download I'd like to be able to do something usefull like reading other
messages. 

<rant>This bug drives me crazy!! It happens to me very often that after waiting
5 minutes for some download (i'm on a modem) I get bored and try to read some
other mail until it finished and.. kaboom - all previous waiting is waisted!</rant>
Adding dataloss keyword - I know it is not 100% appropriate because data is
still on server, but download does not continue where it stoped last time, so I
think I've lost the data that was allready downloaded. Remove it if I'm wrong
with this interpretation.
Keywords: dataloss
QA Contact: olgam → esther
I think there is a workaround here. When you want to see a big message, you can 
double click it in thread pane to bring it up in standalone message window. 
Then you can preview other messages while that message is being downloaded. You 
can switch to that message window to see it when the download is finished.
Correct me if I am wrong.
Harry: the workaround you suggested works. Sort of... If I try to do this trick
with more than one message downloading I'm back with a problem. Only one
tuncated message can be downloaded at a time. So it doesn't help much. And I
never open messages in separate window so such workaround is of little use to
me. This is my personal most hated bug in mail/news. Together with bug 53255 and
bug 149228 which are related together.
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Does this still happen? I haven't yet tried it, but it is possible, because there is no indication the message is being downloaded, or that it is done (except that it is fully displayed).
What happens when the download is interrupted? Is the original (stub message) altered? Does it still have the link to download the full version? Is the partially downloaded message (between stub and full) in the mbox file?
OS: Windows 2000 → All
it's not dataloss, but it does still happen. The doc shell/doc loader is interrupting the url, because the url that runs when you click on another message runs in the same load group/doc shell as the url that downloads the partial message. Perhaps the fix is to terminate the first url and spawn a second url that doesn't run in the same doc shell.
Assignee: mail → bienvenu
Keywords: dataloss
Maybe a temporary fix would be to simply alert the user and ask if he wants to proceed and that it interrupts the download.
There seems to be many variations on a theme with this bug. I am using Thunderbird version 3.0a1(20070429) trunk on XP pro and still have this problem. I have noted, however, that limiting incoming messages to "header only" allows the full message to be recovered while limiting the download size to "x" bytes causes the message to be lost every time. This happens on two stand alone computers at different locations. It doesn't seem to matter which mail account I use the problem is the same. I am happy to run any test you require if it helps resolve this bug. 
Sorry, I should have added that bugs 53255, 149228, 168330, 196846, 214764, 222896, 228676 and 240010 all seem to carry the same message.
FYI> I have just installed thunderbird 2.0.0 and the truncated messages download normally.
Assignee: bienvenu → nobody
QA Contact: esther → message-display
Severity: critical → major
Summary: downloading truncated message is easily aborted → downloading truncated message is easily aborted due to doc shell/doc loader interrupting the url
Whiteboard: dupeme
Sorry, 149228 was not a dupe of this, though it's related indeed.
Going through John's related list (thanks!):
bug 53255 - resolved WFM just now. old bug where link didn't work if message moved
bug 149228 - dupe of bug 53255
[bug 168330 - this bug]
bug 196846 - expired, but fixed/dupe of bug 53255
bug 214764 - fixed. a much earlier bug where the link did not work at all.
bug 222896 - resolved WFM some time ago
bug 228676 - dupe of bug 53255
bug 240010 - resolved WFM some time ago

So all are closed.
I still see this problem with Thunderbird 3.0.3.
I upgraded to version 3.1.1. This issue is still not resolved.

I have been using the download limiting for a few years, even when I used other e-mail clients. My main reason was to prevent downloading of large attachments from bulk forwarded mail, thus letting me choose to download it at a more appropriate time.

This issue is annoying. I could often have more than one truncated message and have to download one message at a time.

For me, it's two steps forward with things like tabbed browsing (I hardly open messages in seperate tabs anyway. I simply read the message in the preview) and one giant step back with this.
After posting my first comment, I realised the product was listed as Sea Monkey.

I'm not using Sea Monkey. I'm using Thunderbird version 3.1.1

Sorry if this was posted in the incorrect place but I see no way for me to edit/delete my own posts.
This appears to have morphed into a Thunderbird bug. Moving to MailNews Core as it appears to be a backend problem.
Component: MailNews: Message Display → Networking
Product: SeaMonkey → MailNews Core
QA Contact: message-display → networking
Version: Trunk → 1.9.0 Branch
Flags: needinfo?(tnyr)
Flags: needinfo?(kuno.meyer)
Whiteboard: dupeme → [dupeme]
You need to log in before you can comment on or make changes to this bug.