Last Comment Bug 736881 - Improve calculation of attached message size
: Improve calculation of attached message size
Product: Thunderbird
Classification: Client Software
Component: Message Reader UI (show other bugs)
: Trunk
: All All
-- normal (vote)
: Thunderbird 14.0
Assigned To: Jim Porter (:squib)
Depends on:
Blocks: 736798
  Show dependency treegraph
Reported: 2012-03-18 12:29 PDT by Jim Porter (:squib)
Modified: 2012-04-10 16:45 PDT (History)
2 users (show)
squibblyflabbetydoo: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Improve attached message sizes (9.46 KB, patch)
2012-03-18 12:29 PDT, Jim Porter (:squib)
no flags Details | Diff | Splinter Review
Fix size counting (10.32 KB, patch)
2012-03-19 01:17 PDT, Jim Porter (:squib)
mozilla: review+
Details | Diff | Splinter Review
Fix bitrot (10.35 KB, patch)
2012-04-08 20:18 PDT, Jim Porter (:squib)
squibblyflabbetydoo: review+
bwinton: ui‑review+
Details | Diff | Splinter Review

Description User image Jim Porter (:squib) 2012-03-18 12:29:30 PDT
Created attachment 606999 [details] [diff] [review]
Improve attached message sizes

Currently, there are two problems with the sizes of attached messages:

1) the size of the headers isn't included
2) for the total size, subparts of the attached message are counted twice

This patch fixes both issues, with tests.
Comment 1 User image Jim Porter (:squib) 2012-03-18 12:51:01 PDT
Comment on attachment 606999 [details] [diff] [review]
Improve attached message sizes

To be safe, this could use UI review. Aside from comment 0, the only significant thing I should mention is that when attached emails have attachments, the "total size" in the attachment pane isn't the sum of all sizes in the attachment list, since that would cause the inner attachment to be counted twice.

I think this is probably the best way to handle this, unless we want to hide inner attachments in the list entirely. I don't know if I want to do that though, since the current way makes it easier to get at those attachments.
Comment 2 User image Jim Porter (:squib) 2012-03-19 01:17:17 PDT
Created attachment 607081 [details] [diff] [review]
Fix size counting

Whoops, it turns out I over-corrected for libmime's weirdness with newlines. This should now produce consistent results for the size of attached messages, no matter whether they're displayed inline or not.
Comment 3 User image David :Bienvenu 2012-03-19 17:05:24 PDT
Comment on attachment 607081 [details] [diff] [review]
Fix size counting

When I saved a .eml attachment, the file on disk was slightly smaller (11.7 KB vs 11.8 in our UI).  The .eml file uses 8 bit encoding, so I wouldn't expect encoding to be an issue. This is on windows, so the saved file should have the same crlf endings.

Anyway, this patch does work as advertised.
Comment 4 User image Jim Porter (:squib) 2012-03-19 17:09:38 PDT
The thing I used to compare the file sizes to make sure they're correct (or, as correct as libmime gets, anyway) is to toggle "Display Attachments Inline" on and off. The sizes for the .eml should be the same in both cases. You can get the exact size with the DOM inspector by clicking on the attachment in the attachment list, navigating up to the <attachmentitem>, then looking at the "attachment" member of the JS object.

I'm not entirely surprised that the reported size is slightly different from the size you'd get when saving, since I know libmime does some weird things with trailing newlines, among other things.
Comment 5 User image Jim Porter (:squib) 2012-03-19 20:25:17 PDT
Try build in progress here:
Comment 6 User image Jim Porter (:squib) 2012-04-08 20:18:54 PDT
Created attachment 613218 [details] [diff] [review]
Fix bitrot
Comment 7 User image Blake Winton (:bwinton) (:☕️) 2012-04-10 11:12:59 PDT
Comment on attachment 613218 [details] [diff] [review]
Fix bitrot

Yeah, sure, making the number better makes sense to me.  (This is more of a ui-rs, but ui-r=me.)
Comment 8 User image Jim Porter (:squib) 2012-04-10 16:45:34 PDT
Checked in:

Note You need to log in before you can comment on or make changes to this bug.