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.
I suppose this issue has been resolved by the fixing of bug 46233. Haven't verified it yet though.
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
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.
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 → ---
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
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.
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.
(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?
Bug 273032 is a similar problem for IMAP.
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?
(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.
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.
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)
*** Bug 246206 has been marked as a duplicate of this bug. ***
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.
Product: Core → MailNews Core
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.
Are the Attachment management issues related to explanation of https://bugzilla.mozilla.org/show_bug.cgi?id=108107#c13 made by firstname.lastname@example.org
You need to log in before you can comment on or make changes to this bug.