When saving news message attachments the article is retrieved from the news/nntp server a second time (re-read/re-downloaded)

NEW
Unassigned

Status

15 years ago
2 years ago

People

(Reporter: svk+bugzilla, Unassigned, NeedInfo)

Tracking

Bug Flags:
wanted-thunderbird3 ?

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030628
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030628

If I try to save an attachment of a news article that has already expired from
the news server, the saving fails.

It's rather irritating because I can see the article, I can see that it has an
attachment, I can see the uuencoded data in the message source view (Ctrl+U),
but I cannot save the attachment because for some strange reason Mozilla tries
to retrieve the message a second time from the news server when saving the
attachment.

Reproducible: Always

Steps to Reproduce:
1. View a news article with an attachment
2 [review]. Wait for the article to expire or otherwise be removed from the server
3. Try to save the attachment

Actual Results:  
Mozilla tries to retrieve the message a sencond time (verified with network
packet-sniffer).
Saving attachment fails since the article does not exist any more on the server.
A zero-length file is saved.
Mozilla shows the standard "Article Expired" screen.


Expected Results:  
Mozilla should not try to retrieve the message a sencond time.
Saving attachment should succeed since the attachment data is cached in the
local message store.
The file should be saved normallly.

Workaround:

Copy attachment data from the view message source window (Ctrl+U) into a file
with an .uue file extension and use an external program to extract the attached
file.
(Reporter)

Comment 1

15 years ago
I suppose this issue has been resolved by the fixing of bug 46233. Haven't
verified it yet though.

Comment 2

14 years ago
Could Bug 108107 be related to this? See bug 108107 comment 13.
Product: MailNews → Core

Comment 3

14 years ago
Per comment 1, and the fact that the purported dupe has long been fixed, marking 
this WFM.  (I'd dupe it over, but if I'm mistaken and Sebastian's problem is 
still there, all that bugmail would be pointless.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME

Comment 4

13 years ago
This bug has not been fixed and the WFM is not a valid resolution.  Bug still
exists in TB 1.0.2 on Win32 platform. 

In addition to this behavior, TB insists on doing this for all attachments that
the client user wishes to save, regardless of the NNTP mesages expiration status
on the server.  This represents a huge waste of my time as the content is d/l
twice. Once with the original text and again as a file save.  

Comment 5

13 years ago
You're correct; I just confirmed this with TB 1.0+0506, Win2K.

I put a message in netscape.test (subject: 123KB attachment) for testing.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 6

13 years ago
I'm not sure if bug 46233's patch was working for news or not -- that bug was 
originally reported for IMAP but has many complaints therein about news 
behavior; and I don't understand the patch's code enough to figure out if it was 
specific to news, imap, or both.  If it *was* for news, then this bug is a 
regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

13 years ago
Mike,
From the last commend by David in bug 46233 I read that the patch NEVER landed
on the TB or Moz Mail/news trunk.  That note for the M4 landing, IIRC, pertained
to a special build that mScott did as a demo for a client.  This said because
the timeline was years past the Moz M4 milestone build, combined with a comment
mScott made elseware about the M1 build shown in the TB FTP folder tree.

The referenced bug got a lot of IMAP debug traffic, yet Davids later comments
point to a different module.  Seems two or three issues were rolled into that
bug.  I also draw your attention to comment #7 with it's note that NC4.5+ showed
this as an unresolved regression in NC.

Suggest getting that M4 build and testing it aginst this issue.  If it works
then the question in my mind is "Did it get into the TB trunk?"  If not, mScott
 may know why, and I guess want to make a decision about landing it for the TB
1.1 release. 

Comment 8

13 years ago
no, the fix for the imap case was checked into the trunk as well as the m4
branch. The news problem was never fixed. It's similar, but not the same. The
imap fix may be neccessary for news to get fixed, but it's not sufficient.

Comment 9

13 years ago
(In reply to comment #8)
> The news problem was never fixed. It's similar, but not the same. The
> imap fix may be neccessary for news to get fixed, but it's not sufficient.

Would my obervations of what a users sees when right clicking the attachment
open option be useful to evaluating why the save option is reloading from the
server?

Comment 10

13 years ago
Bug 273032 is a similar problem for IMAP.

Comment 11

13 years ago
Did a quick and dirty POP test. May not be valid, but behavior was as expected
by users.

Opened a POP mail in my TB 1.0.2 WinME JUNK folder of my POP account.  Selected
a mail with a paperclip icon and viewed.  In View > Msg Source I saw it was
multi-part with an image inserted with a CID value. The mail display is set to
view attachments inline.

Images were displayed.  I selected one for right click > Save Image As... and
selected a My Documents folder.  Clicked Save and TB processed the save promptly
from cache.  There was no activity on the DUN link to ISP's remote server.

Question.  Was this action valid only when the attached content is linked
internaly in HTML by a CID (Content ID).  If so, then test needs repeat with a
text/plain POP mail with an attachment.  I do not have such a sample available
currently.

Is this an Aviary1.1 blocker?

Comment 12

13 years ago
(In reply to comment #11)
> Did a quick and dirty POP test. May not be valid, but behavior was as expected
> by users.
> 
> Opened a POP mail in my TB 1.0.2 WinME JUNK folder of my POP account.  Selected
> a mail with a paperclip icon and viewed.  In View > Msg Source I saw it was
> multi-part with an image inserted with a CID value. The mail display is set to
> view attachments inline.

Does POP have anything to do with that? Principles of POP are different, imho -
POP mail is downloaded and stored locally, unlike IMAP mail, which is supposed
to be stored on a server.

Comment 13

13 years ago
The issue being investigated is the handeling of attachments.  While the focus
is on related IMAP and News attachments handeling, I did my POP test to see how
TB processed a user action saveing an attachment from a POP mailbox. POP mail is
also capable of storing mail on the server. 

Updated

13 years ago
Assignee: sspitzer → nobody
OS: Windows 2000 → All
QA Contact: stephend
Hardware: PC → All
Summary: When saving news message attachments the article is retrieved from the news server a second time → When saving news message attachments the article is retrieved from the news/nntp server a second time (re-read/re-downloaded)

Comment 14

13 years ago
*** Bug 246206 has been marked as a duplicate of this bug. ***

Comment 15

13 years ago
Still seeing the issue for NNTP in the TB 1.5 release build. If anything the behavior is worse.  With the 1.0.x releases smaller attachments seemed to open from memory.  Now I see even attachment open actions reloading the attachment from NNTP server.  No apparent attempt to use the memory cache.

This bahavior may be caused by the memory cache being saturated and not purging to create room for new attachments to be cached.

Updated

10 years ago
QA Contact: attachments
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core

Comment 16

10 years ago
Carrying this bug forward as the behavior still exists in Shredder 3.0b2pre nightlies.  Comment #8 states the IMAP equivalent fix may be precursor to a NNTP fix.

Setting flag nominating Wanted Tb3.
Flags: wanted-thunderbird3?

Updated

3 years ago
See Also: → bug 373040

Comment 17

3 years ago
Are the Attachment management issues related to explanation of https://bugzilla.mozilla.org/show_bug.cgi?id=108107#c13 made by mozilla@davidbienvenu.org
Flags: needinfo?(Pidgeot18)
You need to log in before you can comment on or make changes to this bug.