80220 - Allow bigger attachments list pane width in msg header wider for long filenames

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Peter Lairo]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010509

Need ability to make attachments window in msg header wider for long filenames.

It should be able to drag the left edge of the attachments window to make the
window wider (or narrower) to show long filenames.

Comment 1

[Peter Lairo]

nsCatFood because reading filenames of attachments is important and highly
visible to the user.

Comment 2

[Peter Lairo]

see bug 80221 for a different approach to solving this problem. Either one of
these bugs would solve the problem. Fixing both bugs would be ideal.

Comment 3

[(not reading, please use [e-mail] instead)]

I'm not sure I agree.  having tooltips seems like an alternative approach.

over to mscott.

Comment 4

[(not reading, please use [e-mail] instead)]

#80221 covers tooltips.

I'm able to drag the left edge and make the attachment window bigger.

Comment 5

[Peter Lairo]

I can't drag *any* edge to make the attachments window larger - what exactly did
you do?

Comment 6

[(not reading, please use [e-mail] instead)]

sorry peter, I was being dumb and was using an older version.

confirming.

Comment 7

[Peter Lairo]

The long filenames display should of course dynamically adapt to the changing
(expanding) attachments window size.

So if someone makes the window wider, the cut of part of the filename becomes
legible.

See alo message compose module: This is currently not the case when *creating
mails* with attachments. The currently ledgible part of the filename is all that
is ledgible AFTER widening the attachments window. The cut-off part is not drawn.

Comment 8

[Peter Lairo]

adding keywords (correctness, nsbeta1, ui) to indicate danger of opening
attachments that are high risk because user couldn't see file extension.

Comment 9

[James Green]

A quick fix (and not a very satisfactory one) would be to change the text to
truncate in the middle rather than at the end (thus showing the file extension).

Comment 10

[Joerg Sievers]

*** Bug 86841 has been marked as a duplicate of this bug. ***

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Upping severity a little because of the potential security risk. After all, it
was a similar attachment-extension confusion that allowed the ILOVEYOU virus to
work.

Comment 12

[scottputterman]

Mitch, how big of a thread do you think this is?  When the user choose the
attachment we bring up a dialog asking them which application they want to use
so they still have to take some action on their own.

Comment 13

[scottputterman]

that should be "threat", not "thread".

Comment 14

[Peter Lairo]

adding KW: "dataloss", and upping "severity" because a virus could *easily* be
activated by a (thoughtless) double-click (e.g., hooters.jpg.vbs).

Making platform = ALL (hope this is true)

Comment 15

[timeless]

imo this isn't catfood, no one from ns has expressed any belief that it is, i'm 
taking mstoltz's comment as indicating support of nsbeta1. There is no 
dataloss.

Comment 16

[Peter Lairo]

SPAM: If the keyword "dataloss" doesn't apply, then we need a KW for "Potential
Security Threat".

Comment 17

[timeless]

over asa's dead body?

Comment 18

[Scott MacGregor]

Attachment: show a tooltip when you hover over attachments in the tree

Comment 19

[Scott MacGregor]

this has been checked into the trunk so adding the vtrunk keyword. You should
see a tool tip when you mouse over an attachment showing you the full attachment
name.

Comment 20

[Peter Lairo]

The tooltip is a nice fix, BUT this bug is about making the attachments window
wider by dragging the left edge to the left.

BTW, I think "Titletips" are better than "tooltips" when displaying lists.

Comment 21

[scottputterman]

When the branch is open, please check this into it today.

Comment 22

[Scott MacGregor]

this is fixed on the branch. I'm spinning up a new bug for the trunk based on
peter's initial comments to actually make the attachments window wider. That
problem was harder than adding a title tip. This was the right thing for the
branch but we'll want a more complicated solution to the tip. 

new discussion should go in: 89516.

Fix checked into the branch. 

Comment 23

[Peter Lairo]

The tooltip patch fixes bug 74697 (partially, because a titletip is better for
lists). [e-mail], please check in your patch into bug 74697 where it
belongs.

This bug is still valid and open for the fix to widen the attachments window.
Nothing has changed on this.

Reopening.

Comment 24

[Scott MacGregor]

the branch fix of showing a title tip has been checked in. We'll look at making
the attachment pane wider in a future release. 

Comment 25

[Peter Lairo]

the other bug actually only added a "tooltip" (not a "titletip") which is a far
less desirable solution because the tip is below the actual file and could be
mistaken for the filename of the file below, thus prompting the user to delete
the wrong message (and leaving the one that does contain a virus).

I therefore suggest (and request) that this bug maintain its KWs: nsbeta1 & nsBranch

Comment 26

[Scott MacGregor]

Mail news triage meeting --> .9.5

Comment 27

[Scott MacGregor]

triaging.

Comment 28

[laurel]

*** Bug 89516 has been marked as a duplicate of this bug. ***

Comment 29

[scottputterman]

what about middle truncating so the extension shows?  The tooltip would show the
full name.

Comment 30

[Peter Lairo]

File another bug on "middle truncation". Either way, we still need UI to expand
the size of the attachments window for those who want to see the *whole* filename.

Comment 31

[scottputterman]

Filed http://bugzilla.mozilla.org/show_bug.cgi?id=112162 to solve similar
problem of not knowing the extension type.  Moving this bug out.

Comment 32

[Peter Lairo]

Uh, how is bug 112162 (middle trunkate) nsBeta1+ and TM: 0.9.9 and this bug got
degraded, when both would solve the same problem (seeing the file extension)? 

In addition to solving the file extension problem, *this* bug would allow the
user to see the *entire* filename. Therefore, this bug is more valuable and
should be re-upgraded to where it was (nsBeta1+ and TM: 0.9.9). Life is so
unfair - Waaah).


NOTE: 
If the user expands/collapses the attachments window, then the other header info
(subject, To:, CC:, BCC:) need to reflow and linebreak to remain readable and to
make space for the attachments window.

Comment 33

[Peter Lairo]

Still no titletips nor expandable attachments window. Security hole is still
gaping. Adjusting keywords.

Comment 34

[Michael Buckland]

Discussed in 2/25 Mail News bug mtg with Engineering Mktng and PjM.  Decision
was to nsbeta1 minus this bug.

Comment 35

[R.K.Aa.]

*** Bug 157292 has been marked as a duplicate of this bug. ***

Comment 36

[resigned]

Please could someone explain why my separate bug (157292) was marked as a
duplicate of this one?

The discussion of this bug seems to centre on how to display as much as possible
of the filename.

My bug resolved on the fact that even when the contents is too wide for HOWEVER
much is being displayed, there is no horizontal scrollbar.

Quote from the other bug:
"1) There is NO HORIZONTAL scrollbar (but there is a vertical one)."

Surely, these are two separate issues? (e.g., fixing the scrollbar issue is
perhaps v.easy, and would alleviate the problem of this bug until this bug can
be resolved?)

Comment 37

[Peter Lairo]

RE comment #36: IMO adding a horizontal scrollbar would make the attachments
window so small in the vertical direction that only 1-2 attachments would be
viewable. Therefore the horizontal scrollbar idea is a good candidate for WONTFIX.

RE comment #0: Also, if this bug is fixed, mozilla should perhaps *remember* the
user selected size (width) across mails and sessions.

Adjusting KW milestone and renominating for nsbeta...

Comment 38

[Peter Lairo]

oh, and Bug 157292 should NOT be duped to this one. They are two separate bugs.

Comment 39

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 40

[Kenneth Libeson]

Adding to the security issue of not being able to easily see the full name of
the files attached, we have a bunch of users complaining about not being able to
quickly see all of the attachments if more than three exists. It gets
complicated for them if they are only downloading a portion of them and they
have to scroll up and down.

Can I recommend moving the attachments window just below the header section. It
should also include the collapse feature. When it is not collapsed it would
simply state the filenames seperated by commas, when it is expanded it would
show the filenames with icons. I find this makes it much easier for users to
realize there are attachments included in the email as the natural progression
is top to bottom as opposed to top left, read the body, then top right to check
if there are attachments. 

This new solution would deal with the security issue of seeing the complete
filenames as well as seeing all the files at once.

Comment 41

[Daniel Hyde]

In addition to comment #40, I would suggest that the text reading "Attachments:"
(Mozilla 1.7.2) should read "Attachments (n):", where n is the number of
attachments there are.

At present, if there are more than three attachments, and one or more contain a
longish file name, and your Mail & News window is not sufficiently wide to
display the full attachments area, you cannot see the scrollbar, and thus have
no indication that there are more than three attachments.

Adding the number of attachments to the heading above the list would provide a
convenient way of quickly seeing how many attachments there are; and then you
can take steps to retrieve the attachments that you otherwise wouldn't be aware
of (eg, resizing the window, scrolling the list with the keyboard, etc).

Comment 42

[Tony Mechelynck [:tonymec]]

3½ years without a comment

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008033101 SeaMonkey/2.0a1pre

Attachment pane is not resizable, has no horiz scrollbar.
Longish filenames get ellipsis in the middle.
Hovering the mouse does not display any balloon (or tooltip or whatever you want to call it).

IMHO a balloon would be good, a resizable pane would be good in a different way, both would be best.

Thunderbird's solution (a full-width attachment pane at bottom, just above the status bar) is another approach to this problem. Its downside is that attachments, when present, reduce the real estate available to read text until the pane is explicitly collapsed (but it will reopen the next time you view a mail with an attachment).

Comment 43

[Tony Mechelynck [:tonymec]]

No reply to comment #42. Resetting A+QA to see if anyone is watching.

Comment 44

[kjell]

OK, so I see that the ellipsis is in the middle, allowing me to see the file extension and that a ballon text shows the complete filename whe hovering the mouse over it, but it would be a lot more valuable to be able to expand the attachment compartment's width. I have A LOT of completely empty space to the left of it, which would be much better used for a wider attachments compartment.

Why hasn't this been fixed in almost 15 years? Is it complicated? No priority whatsoever? Somewhat strange considering the amount of discussion and number of people in the CC list. All that said with full respect to the dev team - this is free software after all.

Comment 45

[Rainer Bielefeld]

Remove uncommon whiteboard tag.
If this would have been considered a security issue there would have been more activity to fix this. This one seems to be considered an enhancement request, so I modify importance 
I agree, the current behavior is not optimum, and I also often would be happy with a more flexible behavior.

My test with unofficial (from <http://seamonkey.callek.net/contrib/>)  en-US SeaMonkey 2.44a1  Mozilla/5.0 (Windows NT 6.1; x64; rv:47.0)  Gecko/20100101 Firefox/47.0 Build 20160208090255  (Default Classic Theme)  on German WIN7 64bit:

1. Email Client, Classic Pane view, 3 panes, select an email with log name
   PDF attachment
2 [review]. Drag and drop right folder pane border as far as possible to the right and 
   then slowly back to the right, observe Attachments List pane:
   »a At start Attachments List Pane is completely hidden, From/Date/To becomes
     visible first
    »b Attachments List Pane appears and becomes wider and wider, From/Date/To
      stays truncated at the right
     »c When ALP has reached it's maximum size, more and more of the reight end of
         From/Date/To becomes visible 
      »d even when all From/Date/To has become visible, ALP width will not become
         bigger, long attachment file name keeps "..." placeholder in middle.
  
Behavior starting with "d" should be improved, if there is free space in the mail header area it should be used to increase ALP width to make the whole name visible.