User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 Mozilla in several cases does not cache properly what it has already downloaded once, e.g. while displaying the message. If you after displaying the message save attachments, they get downloaded again. In the more general case, whatever has been loaded once should never ever again get pulled over the wire, unless it changed. This breaks offline working / working over slow modem lines and is a serious regression over what to expect by IMAP/IMAP-disconnected mode Reproducible: Always Steps to Reproduce: 1.open mail with large attachment, see how it gets downloaded 2.save all on attachments 3. see them get downloaded again Actual Results: multiple downloads of cachable material Expected Results: cache everything it has already downloaded. never ever again download what you already pulled over the wire.

related: bug 46233

Repeated downloading happens also if no inline attachments exist and for all attachment types (different from 46233 original report). It also reloads the attachment when displaying the message again, or stepping out and back into the folder. In general, the attachments fail to cache properly when working online.

Related: 183068

Have been using Netscape/Mozilla for a few years, I really want to see the improvement. For Netscape 4.x on UNIX (Solaris/Linux), it doesn't handle nicely for large attachment or it doesn't cache the attachment at all. The netscape messenger will download the attachment first, when you open it, it will download it again. From my laptop (Windows), Netscape 4.x (e.g. 4.79/4.8) has the offline options, basically it works fine. While for Netscape 7.0/7.01/7.02 or Mozilla 1.2.1/1.3, the large mail attachment is still a headache on Windows or Solaris/Linux. I came across the exact problem stated in the bug 181842. Once you set the offline option, it works well as long as you maintain the same session and the attachment is still not that big (e.g. 1~3MB). Once it is large enough (say more than 4 MB), even if you set the offline option, the attachment is not cached, it will be downloaded whenever you access this very message, and download again when you want to save it locally. To make it worse, when you restart netscape/mozilla, all the emails/attachments have to be downloaded again and again. Highly appreciate if it could be fixed in the upcoming release. Thanks a lot! Honglin

Is anyone working on this bug? This is a major problem with mail handling that was reported last year and yet the problem is still evident in Mozilla 1.4 and is driving several people that I support who use IMAP nuts. It seems like it should be fixable without a huge amount of effort.

Whats worse, mozilla downloads *whole* message again for every attachment it saves. I just got an email with more than 10 small attachments (30-100k). Whole message size is about 1Meg. I choose "Save All" from Attachments menu, and now I'm sitting for about an hour looking on "Downloading message" status bar, which is going from 0 to 100% for every attachment, then back to 0%. After every drop to 0%, next attached file appears in directory specified for saving files. Modem link is fully used all that time according to netload applet, and as there're no other applications consuming bandwidth, I think that mozilla downloads whole 1Meg again and again. I can provide IMAP log if needed. Linux nightly build 20030801 here.

solving Bug #131586 would probably solve this one this is not proper IMAP behavior and could some one put here blocking Flag

Why did R.K.Aa say this was "related" to bug 46233 in comment 1, rather than a dupe? I don't see a difference... Bug 46233 comment 7 says "this happens for all attachments" which is contrary to comment 2 here, and the summary was updated at that point. I also don't see any distinction about inline attachment in that bug after the original report.

agreeing with comment 8 and duping to bug 46233 *** This bug has been marked as a duplicate of 46233 ***

Verified dup.