Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20130114 Firefox/21.0 Build ID: 20130114031033 Steps to reproduce: 1. Launch Firefox and navigate to: http://www.mozilla.org/en-US/mission/ 2. Save the page: File menu -> Save Page As... 3. After the download is complete, open the library and the panel and observe the size. Expected results: The page is saved and the displayed size in the panel and in the library view is the same. Actual results: The displayed size in the panel is different from the size displayed in the library view.

to be investigated

that the panel just uses maxBytes reported by the download manager, while the Library also checks the file size on disk. When saving complete web pages thus the panel shows the size of all the files that were downloaded, while the Library just shows the size of the html file.

(In reply to Marco Bonardo [:mak] from comment #3) > that the panel just uses maxBytes reported by the download manager, while > the Library also checks the file size on disk. > When saving complete web pages thus the panel shows the size of all the > files that were downloaded, while the Library just shows the size of the > html file. In the Library, the size of the html file also differs even if I make the same download several times (please see the screenshot). If I close the Library window and I open it again, the size is the same for all the entries.

bug 826991 fixed part of this bug, the Library will use the same size as the panel

the most confusing part of the bug (panel showing one size, library showing another one) should be fixed, leaving this open to evaluate comment 5, but not blocking anymore. While annoying, the slightly different sizes are a minor issue and not affecting functionality.

ah sorry, I wrongly unassigned this.

Actually, given the scope of the remaining issue, off-loading this for now.

The issue in comment 5 might be related to the fact that the currentBytes property (that may be used by maxBytes for downloads with no progress indication) may not always be updated with the latest value when the download finishes. The library is supposed to read the file size from disk, but _fetchTargetFileInfo is called asynchronously and it only updates the size variables, and those may not be picked up in the metadata object in time for being displayed. The work in bug 1116176 can fix this.

(In reply to :Paolo Amadini from comment #10) > The library is supposed to read the file size from disk, but > _fetchTargetFileInfo is called asynchronously and it only updates the size > variables, and those may not be picked up in the metadata object in time for > being displayed. > > The work in bug 1116176 can fix this. Hm, on second thought, we should probably look into resolving the size issue when the Places metadata is written by the DownloadsCommon view. Bug 941063 will help by providing a reliable property with the file size. The Places view should trust the metadata and not do any additional I/O.