Closed Bug 654222 Opened 13 years ago Closed 13 years ago

Attachment list should resize to fit long names

Categories

(Thunderbird :: Message Reader UI, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 10.0

People

(Reporter: squib, Assigned: squib)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file, 1 obsolete file)

The attachment list currently crops any long filename, even when that doesn't save any space (e.g. there is only one attachment). We should be able to dynamically set the width for the list items based on the maximum width needed to fit the text.

There should probably be a "really maximum" value so that pathologically long filenames don't cause problems.
OS: Linux → All
Hardware: x86 → All
Related to this:  Some perpetrators of virus/worm infections use pathologically long file names to make it look like their attachment names end in something innocuous like .txt, when in fact they have a whole load of spaces thereafter before the real extension (.exe or whatever).  So if you do have to crop, be sure that whatever change you make to this leaves the real extension on the end (after the ellipsis).
We already do this, but noted.

We could also be smart and fold whitespace to take up less space. For the latter, I guess you could debate how many consecutive spaces to allow, e.g. "if there are more than 5 consecutive spaces, delete the remainder of them".
The solution to this problem has already been noted on mozillaZine, 4 years ago.

http://kb.mozillazine.org/Attachment_filename_truncated_%28Thunderbird%29

The solution given there works for my Thunderbird 5.0 on Windows XP 

Why not put this into the standard? It's a huge improvement on the way the attachment box has worked since it appeared (in TB3?)
(In reply to comment #4)
> Why not put this into the standard? It's a huge improvement on the way the
> attachment box has worked since it appeared (in TB3?)

Because that's a hack, not a fix. The attachment list should be laid out like a grid, just like any file list (e.g. Windows Explorer, Nautilus, etc). When there are multiple rows of attachments, the layout is completely broken by that hack. It's not that simple.
I totally disagree. Using this solution, whether you call it a fix or a hack, means that in the majority of cases (mine certainly), the attachments all fit on one line, and so this layout is unquestionably FAR superior, as it shows the entire filenames, without the ... shortenings.

In cases where the number/length of filenames makes the attachment box span over multiple lines, the fact that the names are not in a grid is a slight disadvantage, but still hugely outweighed by the fact that the full filenames are visible. 

Analyse your emails with attachments, and tell me which method produces a better display in the majority of cases, even if you hold that a grid is preferable. I struggled to even find one e-mail which went over two lines, and I'm only running with a narrow window.

If you really think the current method is better, make it user-selectable.
(In reply to comment #6)
> If you really think the current method is better, make it user-selectable.

It already is, through the magic of userChrome.

However, I'm not going to have a debate over whether the hack is "good enough". I have a proper fix in mind, but have other, higher-priority work to do on improving the attachment pane. I see absolutely no point in adding something like this as a temporary workaround in Thunderbird when it would be not much harder to fix it properly. However, that depends on bug 630759 getting checked in, since this would touch the same code, and the patch on that bug is essentially done.
With respect, it's a bit late to come over all perfectionist. I've no problem with perfectionism per se., but the time for this is during the development of the feature, not in fixing the bugs post release. 

You may consider the creation of a userChrome.css file user selectable, and perhaps in the Linux world it is a reasonable thing for someone to do. But in Windows, the vast majority of users wouldn't attempt this, so it should be considered a dirty hack. 

If it isn't hard to fix properly, why did it get released in this state? Many people will look at TB, think "I can't see my attachment names" and move on to another e-mail program. No-one would ever get similarly excited about a very occasional lack of alignment in a large list of attachments.
Calm down, Matthew. No-one's killing themselves over not being able to see their attachment file names.
Sorry if I seem a bit agitated. It's just that I've now had to add no fewer than four fixes to TB5 to stop losing features that TB2 had and which have been removed. (1. Extra folder columns, 2. Attachment Options, 3. Can't read the menus. 4. this one) It's almost as if someone is deliberately trying to make the programme unusable in little chunks.
Certainly the last two things you mentioned are bugs, and are in the process of being fixed.

I'm not sure what feature the Attachment Options add-on gives you that TB5 doesn't have, but I would like to hear what it is.  (Preferably through email.  I'm at <bwinton@mozilla.com>.)

Finally, I wonder if you would be interested in starting a collection <https://addons.mozilla.org/en-US/thunderbird/collections/> of the add-ons you use to get TB5 to where you want it to be.  If you're running into these annoyances, I suspect other people are too, and having a "TB3 for TB5" collection might help them as well.

Thanks,
Blake.
(In reply to comment #11)
> annoyances, I suspect other people are too, and having a "TB3 for TB5"
> collection might help them as well.

Which, if I read comment 10 correctly, would be a TB2 for TB5 collection...

Otherwise, I was wondering if Jim and Matthew are talking about the same thing... comment 0 and Jim's comments seem to be more about the received attachments presentation in the mail reader, whereas Matthew's comments and the css-hack seem to be more about composition's attachment list. But I'm not very sure. Jim, could you post a mockup how, after your intended fix for this bug, the attachment lists for reading and composing would look like with a mixture of short and long attachment file names?
(In reply to comment #12)
> Otherwise, I was wondering if Jim and Matthew are talking about the same
> thing... comment 0 and Jim's comments seem to be more about the received
> attachments presentation in the mail reader,

Both of us are talking about the reader. It's easy enough to fix truncation in the composer: just resize the attachment pane. The ".attachmentBox" in the CSS hack only affects the reader anyway.
Attached patch WIP patch (obsolete) — Splinter Review
Here's a WIP patch to handle this. It requires the latest patch from bug 630759 to work. Not much to say yet, since it's still a bit messy, but it works for the common case.
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
Depends on: 677021
Here's a patch for this. Holding off on review for the moment, since it depends on a couple of other things in my queue.
Attachment #550016 - Attachment is obsolete: true
Jim, could you post a screenshot how multiple (say 8) mixed short and long filenames look after the patch?
Does this patch fix attachment file name truncation in the composer as well?
(In reply to Thomas D. from comment #17)
> Does this patch fix attachment file name truncation in the composer as well?

No, but that was never really a problem, since you can easily drag the pane to any size you need.
Comment on attachment 559738 [details] [diff] [review]
Adjust the width of each attachment item so all of the names fit

Ok, this should apply cleanly to trunk now. Bwinton, do you mind looking at this? There aren't any tests, but if you think there should be, I can probably whip something up.
Attachment #559738 - Flags: review?(bwinton)
Comment on attachment 559738 [details] [diff] [review]
Adjust the width of each attachment item so all of the names fit

Review of attachment 559738 [details] [diff] [review]:
-----------------------------------------------------------------

The code seems okay to me.  Obviously, I'm a fan of tests cause they can exercise some really odd cases (like two files whose names would take up 75% of the screen each, or one file which would take up 150% of the screen), but I think I'm going to say "r=me", and we can do the tests in a follow-up patch.

Thanks,
Blake.
Attachment #559738 - Flags: review?(bwinton) → review+
Checked in: http://hg.mozilla.org/comm-central/rev/973e669c921c

(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #20)
> The code seems okay to me.  Obviously, I'm a fan of tests cause they can
> exercise some really odd cases (like two files whose names would take up 75%
> of the screen each, or one file which would take up 150% of the screen), but
> I think I'm going to say "r=me", and we can do the tests in a follow-up
> patch.

For what it's worth, I've manually tested both of these cases and everything works as you'd expect.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 10.0
Joining the party here a bit late, but it sure is a regression if one receives messages with long but frequently meaningless attachment names. The upper limit mentioned in comment #0 is the width of the attachment window, thus one may end up with one attachment per row (it's a similar problem with the "ls" command on Linux, a single long file name will force it to 1-per-line, leaving plenty of unused space). Maybe some solution where a long name is allowed to span multiple cells while retaining the old grid spacing for those that fit would have been a compromise between the "all sizes equal" and "free floating" extremes...

Once again there is no off switch for this feature, but fortunately the "width" attribute as set in setOptimumWidth() apparently can be overridden with a CSS rule, thus - if desired - the following reinstates the old behavior if put into your userChrome.css:

attachmentlist[orient="horizontal"] attachmentitem {
  width: 15em !important;
}

attachmentlist[orient="horizontal"][view="tile"] > attachmentitem {
  width: 9em !important;
}

Change "15em" and "9em" to other values as you like them if a fixed grid is preferred, where I don't know if the min/max-width specifications will hit at some point.
Blocks: 697870
(In reply to Thomas D. from comment #16)
> Jim, could you post a screenshot how multiple (say 8) mixed short and long
> filenames look after the patch?

Can someone post some screenshots of some of the pathological cases (or even just a normal mixed-length case) after this patch? Comment 16 was expecting some of the regressions mentioned in comment 22, but unfortunately there was no reply...
Let's continue in bug 697870. It's fairly easy, just create a text file with a very long filename and a couple of other ones with "normal" name sizes, then attach them to a new message and save as draft. It should be obvious what I mean.
Depends on: 698272
No longer depends on: 698272
You need to log in before you can comment on or make changes to this bug.