74697 - Need "TitleTip" (not tooltip) if Attachment Filename is Longer than Attachments Window

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Peter Lairo]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1), 2001-04-03, imap server

Need Tooltip or titletip if attachment filename is longer than menu.

That would be the only way to see the filetype on long filenames.

Comment 1

[Alex Bishop]

Is this a duplicate of bug 32157?

Comment 2

[Keyser Sose]

*** This bug has been marked as a duplicate of 32157 ***

Comment 3

[Peter Lairo]

Not really a dupe, but rather a *DEPENDENCY* - i suggest to keep this bug open
and make *dependant* on bug 32157.

That way, it will be possible to verify that bug 32157 really fixes this
particular issue.

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

.

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

marking new, making dependant upon 32157

Comment 6

[Peter Lairo]

renaming summary to mathch new attachments layout (it used to be a dropdown menu).

old:
Need Tooltip or titletip if attachment filename is longer than menu

new:
Need Titletip or Tooltip if attachment filename is longer than attachments window

This could also be a serious *security risk*, since the user cannot the the file
extension and accidentally activate a virus program (e.g. hooters.jpg.vbs) 
-> adding keywords to reflect this.

Comment 7

[Peter Lairo]

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

Comment 8

[Peter Lairo]

changing platforms to ALL (hope this is correct).

Upgrading severity to *major*, based on security issues.

Comment 9

[Peter Lairo]

changing platforms to ALL (hope this is correct).

Upgrading severity to *major*, based on security issues.

See also bug 80220 for a *different approach* to solving this problem. Either
one of these bugs would solve the problem. Fixing *both* bugs would be ideal.

Comment 10

[Scott MacGregor]

this is fixed on the branch and tip. 

Comment 11

[Peter Lairo]

I just realized that tooltips are not a good idea for long filenames
attachments. If there are multiple attachments, then the tooltip looks like it
belongs to an attachment further down the list. 

We really should have *titletips* here.

Comment 12

[Peter Lairo]

Also, the TitleTip should be *right justified* because the attachments window
pane is on the right edge of the screen (and therefore monitor) and the titletip
text might flow beyond the visible screen.

PS. I think the "titletips bug" (bug 32157) has been fixed, so this feature
shoud be available for this bug :)

Comment 13

[scottputterman]

as far as I can tell, this works.  

Comment 14

[Peter Lairo]

on build 2002-03-19, winNT there is only a "tooltip", but not a *titletip* as
this bug requests, and explains why using *titletips* are important (comment #11).

Comment 15

[scottputterman]

the tooltips solve the problem such that it can be nsbeta1-'d

Comment 16

[Ian Nartowicz]

I see a tooltip (not a titletip, don't think those work yet) on long attachment
names.  Unfortunately, it doesn't work properly.  It attempts to show a full
pathname, but the tooltip appears on the left and the left part of the name off
the screen.

Comment 17

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 18

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

again, do we even have tooltips there now?

I think we need jag's fix for #32157 before we get tooltips back.

Comment 19

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

> again, do we even have tooltips there now?

false alarm, the attachment bucket already has tooltips.  I was confused.

Comment 20

[Mike Cowperthwaite]

While titletips would definitely be an improvement over tooltips, as stated in comment 11, I don't see that this bug is anything but an RFE, let alone 'critical' in danger of 'dataloss'.  Given comment 19, I'm not even sure that was true when Brent upped the severity in comment 17, back in 2003.

As for the potential security hazard: note that the icon used next to the attachment in the bucket is the icon of whatever type the file is understood to have -- that is, normally, the icon of the program that will be used to open it.  While seeing the file extension is useful, it doesn't *necessarily* indicate how the file will be handled:  If, somehow, the message contains an attachment with Fred.MP3 that has a MIME type of application/pdf, the program will be opened using Acrobat (or whatever you've assigned for that type), and that's the corresponding icon that will be used as well (xref bug 243838).

There's been a lot of adjustment to how attachments are handled in the last couple years; if there's still any path to a security breakin, it's unrelated to whether the file extension is visible in the bucket or tooltip.


(In reply to comment #16)
> [The tooltip] attempts to show a full pathname, but the tooltip appears on
> the left and the left part of the name off the screen.

I see the tooltip position itself to the right of the mouse, but right-justify to the screen edge, it doesn't overrun.  (A titletip would truncate at screen edge rather than right-justify for extra display space -- or, at least, that's what Windows does when it puts a titletip over a long-named file in Windows Explorer.)

There is a maximum length to the Mozilla tooltip, looks to be about 80 characters.  (True in Thunderbird as well.)

One improvement that TB makes over the suite: when an attachment with a long name is shown in the bucket, the ellipsis is placed in the middle of the file rather than at the end, so you can see the file extension.  But (as in the suite) the tooltip is end-truncated, at about 80 characters.