81615 - Tooltips for elements in popups appear in unexpected position.

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[William Cook]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    -

If you try to display a tooltip on an element that is displayed in a popup 
window the tooltip will instead be displayed somewhere off to the bottom-right 
of the window.

Reproducible: Always
Steps to Reproduce:
1.  create a popup window
2.  give an element within the popup the tooltip/tip attributes
3.  open the popup and mouseover the element
4.  the tooltip will appear somewhere off to the bottom-right of the window

Actual Results:  

[tip element]

 
                     [tooltip]


Expected Results:  
[tip element]
      [tooltip]

Comment 1

[William Cook]

Attachment: XUL file containing test case.

Comment 2

[Peter Trudelle]

->pink/future

Comment 3

[Keyser Sose]

Marking NEW.

Comment 4

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 5

[Kyle Yuan]

This is because we must adjust the mouse point according to the popup object.

Taking...

Comment 6

[Kyle Yuan]

Attachment: adjust mouse point according to popup-widget's left-top corner

seeking r=

Comment 7

[Kyle Yuan]

CCing guys who can r= my patch.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Kyle, make sure you have mailed the people you want to review this patch...
bugmail is not going to be sufficient to get their attention.  :(

Comment 9

[William Cook]

Attachment: Extension of the patch to include popup elements

Extending the patch for the case where a tooltipped(?) element sits within a
popup window.

Comment 10

[William Cook]

Attachment: Updated testcase

Comment 11

[Kyle Yuan]

William, thanks for your patch, I'm going to merge them together, and revising 
them for a better job.

Comment 12

[Kyle Yuan]

Attachment: merged patch (need work)

My previous can't work with <popup> and <optgroup>. Now that was fixed.
Unfortunately it still can't work with multi-level popups. And it affects the
mouse move performance, that is unacceptable. I should cache the event target,
then do adjusting when tooltip was going to show. Will do that tomorrow.

Comment 13

[Kyle Yuan]

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

Comment 14

[Kyle Yuan]

Attachment: better fix (convert screen point by closest parent widget)

In this patch, I use the screen point, instead of client point, to locate the
tooltip window. It works fine with any kind of popup widget, such as
combobox-dropdown list (including optgroup), popup, popup menu. It doesn't
affect any tooltips of non-popup widget.

Seeking r= again.

Comment 15

[Kyle Yuan]

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

Comment 16

[Kyle Yuan]

Attachment: use the widget of target's document to convert the screen point

My previous fix is wrong, because I didn't find out the right widget to convert
screent point, so it worked incorrectly with attachment listbox.

Comment 17

[Kyle Yuan]

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

Comment 18

[Silvia Zhao]

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

Comment 19

[Jan Varga [:janv]]

kyle,

- nsIWidget::ScreenToWidget() is not implemented on all platforms
  have you tested this fix on Linux or other platform ?
- do we really need both mMouseClientX and mScreenClientX (the same for Y) ?

Comment 20

[Kyle Yuan]

Attachment: revised per varga's suggestions

Jan, you are so awesome. ScreenToWidget() doesn't work in GTK. I use
WidgetToScreen() instead. mMouseClientX/Y removed too.
Could you give me an example of tooltip for <tree>? I want to make sure that my
patch doesn't break it.

Comment 21

[Jan Varga [:janv]]

Attachment: patch to ponder

I think this bug should be investigated deeper.
Look at bug 78344. I think it has something to do with this bug
Also, this patch is not the real fix, just an inspiration.

Comment 22

[Jan Varga [:janv]]

ccing people from bug 78344

Comment 23

[Jan Varga [:janv]]

forgot to say that Kyle's patch looks good, I just want to make sure we are on
right track.

Comment 24

[:Gavin Sharp [email: [e-mail]]]

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

Comment 25

[Wayne Mery (:wsmwk)]

Does this bug appear on MACs and linux, or is it windows only?

Jan in comment #21
>..
> I think this bug should be investigated deeper.
> Look at bug 78344. I think it has something to do with this bug

Related perhaps, but this bug predates the patch for bug 78344.

is bug 344492 a dup? (fails for windows trunk, but can't speak for MACs and Jesse's comment)

Comment 26

[Wayne Mery (:wsmwk)]

Do you see this?   Comment 20 says it doesn't work in GTK. 

WFM windows attachment 90765 [details] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022502 SeaMonkey/2.0a1pre

xref bug 344492

Comment 27

[Philip Chee]

Neil Deakin rewrote most of the xul popup code for Gecko 1.9, any problem with tooltips is a different bug and none of these patches are relevant any more.

Comment 28

[Wayne Mery (:wsmwk)]

WFM then. Thanks Ratty