+++ This bug was initially created as a clone of Bug #654222 +++ This part hasn't been sufficiently addressed in the original bug: > There should probably be a "really maximum" value so that pathologically long > filenames don't cause problems. (Quoting bug 654222 comment #22) > is a regression if one receives messages with long but frequently meaningless > attachment names. The upper limit ... 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). A couple of suggestions how a maximum length could be defined: (a) a direct user preference specifying that value and being included in the definition of setOptimumWidth() to cap the maximum encountered width; (b) a fixed percentage (e.g., half or a third of the current window width) so that at least 2 or 3 attachments are visible (unless there are less than that in the attachment list to start with); (c) some fancy heuristics, like the 80th percentile of the encountered name widths, thus reducing the effect of a single long file name forcing a width that's not favorable for the other attachment names.

Add (d), expanding on your bug 654222 comment #22: Align names to a grid of cells, and very long file names take up more than 1 cell. (Could be annoying in case of numerous attachments just over 1 cell width, but at least would still be usable.)

Yeah, I've omitted that variant as I figured it's probably more tricky to go there, requiring the individual item widths to vary. If it turns out that version (d) is considered superior over the (a),(b),(c) variants, be my guest.

There may be some cases where one would want to see the complete filename (automated logs etc)That could be handled with a tooltip exposing the full name. This is a ridiculous example, but people do ridiculous things in email.