173874 - tooltips for attachments do not work correctly

Status: VERIFIED FIXED

(MailNews Core :: Attachments, defect)

Description

[NorthMan]

User-Agent:       Mozilla/5.0 (Windows 2002 Government Server Edition; en-US) Gecko/2002100808
Build Identifier: Mozilla/5.0 (Windows 2002 Government Server Edition; en-US) Gecko/2002100808

If you get an email with an attachment, and you point at the filename in the
attachments section of the preview window, a yellow label (similiar to an "alt
text" label) will appear showing the file's name.  On short filename's (less
than 8 characters or so + file extension, the label appears way over on the left
side of the screen near the folders for each of my mail accounts.  On longer
filenames, like ones with 30 characters or so + the file extension, the label
actually is located 50% off the screen.  It appears about half-way down the
screen (same as always), and about halfway off the screen (on the left), kind of
like it was created off the screen, for some weird reason.

Reproducible: Always

Steps to Reproduce:
See above.

Comment 1

[NorthMan]

Corrected my misnomer.  When I said label/alt text thing I meant tooltip. ;-)

Comment 2

[parish]

Confirmed on WinXP Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b)
Gecko/20021007 CVS build and also in nightlies for the last couple of days.

The position of the tooltip varies with the size of the Mail/News window, i.e.
it isn't a constant distance or percentage of the window size.

Comment 3

[Ryan Pertusio]

Yes.. I can also confirm (WinXP)

It DOES indeed appear to be based off the dimensions of the screen, rather than
the position of your Mozilla window.

I've noticed:
~ The same occurs when Composing a message (See attachment)
~ The tooltip will 'move' on the screen based on resizing of the window
~ Below is an interesting 'test' to show that tooltip position is based off the
screen, rather than the window position.

(This test will work while composing, or 'previewing' a message with attachment.
It is also assumed that your Mozilla windows are not maximized)
1) Create a New Message, and add attachment (no need to 'send')
2) Hover the attachment, and notice the position of the tooltip
3) Move the compose window left or right (do not resize)
4) Hover the tooltip again, and notice that it is the same X coordinate of your
screen, with no relation to the actual position of the window.

Related, but NOT duplicate bugs:
Bug 74697 - Need "TitleTip" (not tooltip) if Attachment Filename is Longer than
Attachments Window
Bug 32157 - Title tips (tooltips) for cropped text

See 2 Attachments (below) for an example of this bug.

--> Confirming as NEW

Comment 4

[Ryan Pertusio]

Attachment: Attachment tooltip positioning in "Message Preview"

Comment 5

[Ryan Pertusio]

Attachment: Attachment tooltip positioning in New Mail Message

Comment 6

[Benjamin Mucci]

Same under MacOS 8.6

Comment 7

[NorthMan]

Changing Platform/OS to All as this is reproducable on multiple OSes.

Comment 8

[parish]

Attachment: Patch

The fix for bug 73970 highlighted this (existing) bug.

When a tooltip will be off the edge of the screen it is repositioned to keep it
visible. At the right hand edge of the screen the old method simply flipped the
tooltip from the right hand side of the cursor to the left. The fix for bug
73970 changed that to just shift the tooltip far enough to the left to keep it
visible (BTW, this wasn't the original problem reported in bug 73970).

This bug already existed but, because the tooltip remained with the cursor, it
wasn't obvious. With the current behaviour if you drag the mail/news window off
the left hand edge of the screen so that the attachments pane is within the
left ~25% of the screen the tooltip will appear on the left. As you move the
window further right it will eventually "stick" to the screen. Prior to bug
73970 being checked-in this is the point at which the tooltip would switch from
the right of the cursor to the left, which is wrong.

Note also that the positioning behaviour in Y is wrong as well (this patch
fixes that as well); if you have an e-mail with several attachments and move
the mouse over them you will see that for some the tooltip is above the cursor
and sometimes below. Since the fix for bug 73970 didn't change the behaviour in
Y we don't see a big displacement like we do in X.

The code that this patch removes appears to have been a workround that is no
longer needed (read the comment above the code, which I've also removed).

Comment 9

[parish]

> left ~25% of the screen the tooltip will appear on the left.

Duh!

s/left/right of the cursor/

Comment 10

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

Comment on attachment 111919 [details] [diff] [review]
Patch

I'm not a layout hacker, so over to roc for review.

(you might consider asking 
[e-mail]
[e-mail] or
[e-mail])



according to cvs, this change was made on 3/1/2000 by pink:

1.77	pinkerton%netscape.com	Mar 1 2000		rewrite of popup
positioning code to avoid placing a popup on top of the parent frame it is
anchored to and to prevent moved popups from coming up under the mouse when
they are too big or too close to the edge of the screen. Fixes bugs 29141 21155
23191. r=saari,hyatt a=jevering.

Comment 11

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

over to [e-mail], since he has the patch.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This code is horrific. It's practically impossible to see what it's trying to do
and I'm pretty sure that it's just a pile of empirically tested hacks that have
evolved to give the right answers most of the time. This code is desperately in
need of a rewrite.

Having said that, I'll accept this patch if you can assure me that you've tested
context menus in mailnews with various window positions and sizes and they
always pop up in reasonable locations without ever going off the screen.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's expecially irritating because what nsMenuPopupFrame is trying to do is not
fundamentally that hard ("adjust popup position to account for screen geometric
constraints") and people just didn't understand the invariants that govern
layout, so they wrote tons of hacky code to account for all sorts of special
cases, some of which are unnecessary and some of which are bugs that should have
been fixed somewhere else.

Sadly, this probably isn't important enough to spend time rewriting anytime soon.

Comment 14

[parish]

Thanks Robert. I thoroughly tested context menus before I submitted the patch;
like you I was concerned that it would (adversely) affect context menus. I have
also been running this patch locally since I submitted it (over 6 weeks) and
have never seen any unusual behaviour of context menus.

Comment 15

[parish]

Hold on a minute, I've just spotted another place that this bug manifests
itself; The column select dropdown (above the scrollbar). The (new) tooltip for
the button itself is OK but the tooltips for the menu items are wrong. Guess I
missed that because I never use the list.

New patch coming up.

Comment 16

[parish]

Forget it. The patch stands. The issue with the Column Select tooltips is a
separate issue that appears to be caused by bug 194876

roc: does this get an r= from you?

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 111919 [details] [diff] [review]
Patch

r+sr=roc+moz

Ok, let's see how it goes.

Comment 18

[parish]

Thanks. Can you check it in to the trunk for me please? Also, should I seek
approval for check-in to 1.3 as well, since it's not a major bug?

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No way are we checking this into 1.3.

I'll check this in for you.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked in.

Comment 21

[NorthMan]

Verified fixed 2003032014.

Tested with 8 character, 16, and 32 character long attachments (not including 4
char extension).  Looks great!