250462 - Regression: painfully slow (25-30 sec.) attachment Save As/Save All with UI freeze

Status: RESOLVED DUPLICATE of bug 159107

(MailNews Core :: Attachments, defect)

Description

[Z. Smith]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707

As of Mozilla 1.7 RC2 up to the current build am trying now (did not test RC1),
mail attachments of any type take a painfully long time to Save As/Save All in
any local directory. During the time the attachments are being saved, the UI
freezes; further use of the UI is impossible until the attachment finishes
saving. This "freeze time" averages between 25 and 30 seconds.

Am using a profile dating from 1997 (Netscape) :). Always have fully uninstalled
the program before installing new builds/releases.

This problem was not evident when upgrading to Mozilla 1.5 and 1.6 (and possibly
1.4, don't remember). Mail attachments with those builds saved instantly and
control returned to the UI within a second or two. This problem is also not
evident in Thunderbird 0.7.1/0.7.2--having transferred my ancient mail profile over.

This problem _was_ evident in earlier builds of Mozilla that I've tried--at
least at 1.3 that I can remember. I continued to use Netscape 4.x mail up until
this problem was resolved as of about Mozilla 1.4.

As I receive many (many) attachments during the day, this problem is a Mail/News
blocker for me (have switched to Thunderbird for mail).




Reproducible: Always
Steps to Reproduce:
1.Receive an email with an attachment of any type (ZIP, JPG, etc.)
2.Right-click the attachment. Choose either Save As or Save All.
3.After the directory selection box appears, choose a directory (or use the one
shown) and click the "Save" button.



Actual Results:  
The UI freezes for 25 to 30 seconds (until the attachment is finished saving in
the chosen directory).

Expected Results:  
The attachment should have either: A) saved instantly after Reproduce Step #3
above as happens in Mozilla 1.6 or 
B) control should have been returned instantly to the UI while the attachment
was taking its sweet time saving.
A) is far prefereable to B).

Comment 1

[Z. Smith]

Follow up: reproducible only in a certain circumstance. That circumstance being a very large (several megabytes in size) DOWNLOADS.RDF file in the user's profile folder (on a FAT32 drive). I kept that file increasing in size without deleting as it makes tracking download history for backups, etc. easier. Once it starts approaching several megabytes in size (at the time I filed this report originally, it was 7 MB+ in size), the slowdowns on file saves as mentioned in the previous post in are readily apparent.

The solution is to delete the entries in DOWNLOAD.RDF using the user interface. The slowness in file save operations goes away. Even so, that is still unexpected behavior. And unlike in Firefox, in Mozilla the user has to delete the download entries manually. Which for many users, means that this file could start approaching the size when slowdowns in file save management become apparent.

Comment 2

[OstGote!]

So clearly a dupe. See bug 132755 too.

(In reply to comment #1)
> Follow up: reproducible only in a certain circumstance. That circumstance
being a very large (several megabytes in size) DOWNLOADS.RDF file in the user's
profile folder (on a FAT32 drive). I kept that file increasing in size without
deleting as it makes tracking download history for backups, etc. easier. Once it
starts approaching several megabytes in size (at the time I filed this report
originally, it was 7 MB+ in size), the slowdowns on file saves as mentioned in
the previous post in are readily apparent.
> 
> The solution is to delete the entries in DOWNLOAD.RDF using the user
interface. The slowness in file save operations goes away. Even so, that is
still unexpected behavior.

*** This bug has been marked as a duplicate of 159107 ***