171229 - [FIX]Tooltip locations in frames and iframes are wrong

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: GRE Core, defect, P1)

Description

[Mark Kawakami]

When a tooltip is within an iFrame, it will be mis-positioned. The position
should be relative to the iFrame's origin, but it comes up relative to the
iFrame's parent. In other words, the tooltip usually  appears higher and further
to the left than it should.

Comment 1

[Greg K.]

Mark, what build ID are you reporting this bug against? Also, please provide an
example URL or testcase attachment.

Comment 2

[Mark Kawakami]

Greg:
I've noticed this in all the builds, but for the recrod, I'm using Build ID:
2002092704

Comment 3

[Steve Smart]

confirmed in 2002102104

Comment 4

[Simon Fraser [no longer active]]

To pink.

Comment 5

[Jasper]

Update please...

Comment 6

[Martin Girschick]

Just to provide a testcase. Look at http://www.sparkasse-darmstadt.de/. Besides
the fact, that this page looks really ugly with the current Panther-Bug the
Tooltips are all positioned wrong.

Tested with build 2004020303 (v0.7+)

Comment 7

[Jasper]

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

Comment 8

[Mike Pinkerton (not reading bugmail)]

another url testcase is http://www.brodsoft.de/camino/frame.html

Comment 9

[Simon Fraser [no longer active]]

Attachment: iframe doc (part of testcase)

Comment 10

[Simon Fraser [no longer active]]

Attachment: Testcase

Comment 11

[Simon Fraser [no longer active]]

I guess we should we fix the caller of nsITooltipListener here:

http://lxr.mozilla.org/mozilla/source/embedding/browser/webBrowser/nsDocShellTreeOwner.cpp#1122

Comment 12

[Simon Fraser [no longer active]]

nsITooltipListener states that the coordinates supplied are relative to the top,
left of the browser content area, so we should make that so.

This means that ChromeTooltipListener (in nsDocShellTreeOwner.cpp) needs to
convert the clientX/clientY coords of the mouse move event into coords that are
relative to the top DOMWindow. In order to do this, I guess it has to know which
subframe the event was targed at, in order to know what clientX/clientY are
relative to, then it has to walk the windows and fix up the offets. I'm not sure
of the best way to do that.

Comment 13

[Andy Lyttle]

Forgive my ignorance, but why is this completely different than Firefox?

Comment 14

[Simon Fraser [no longer active]]

(In reply to comment #13)
> Forgive my ignorance, but why is this completely different than Firefox?

Because Firefox tooltips are done using XUL.

Comment 15

[Boris Zbarsky [:bzbarsky]]

And more to the point, Firefox doesn't use nsITooltipListener, or nsWebBrowser
or nsDocShellTreeOwner...  :(

roc, what's our current One True Way on trunk and 1.8 branch to get from an
event to coords in a given docshell's coordinate system?  Do we just go through
screen coords, or do we have something better?

I do think we should fix this for 1.8....

Comment 16

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

I would suggest just going through screen coordinates since this can't be
performance critical.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Asa, why is this not blocking Gecko 1.8, exactly?  If we're not caring about
embeddors being able to usefully use Gecko 1.8, just let me know and I'll stop
worrying about whole classes of bugs here...

Comment 18

[Boris Zbarsky [:bzbarsky]]

Attachment: Not quite working

This doesn't quite work in TestGtkEmbed because for some reason the parent
widget for the docshell is the outer window, as far as I can tell, and the
docshell's offsets are 0.

roc, do we have a guaranteed way to get at the widget _inside_ the docshell? 
That's the one we really want to be using here, I think...

Comment 19

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

You could go get the document's presentation's view manager's root view's
widget, that has to be correct. :-|

Comment 20

[Boris Zbarsky [:bzbarsky]]

Yeah... I was kinda hoping to avoid that, if only because we might be making
those widgets go away at some point, no?  And I'd really rather this code didn't
break then, esp. since it's unfortunately not tested in Firefox-land.

Perhaps we could consider exposing a getter for its screen coords on a docshell
or something?

Comment 21

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

Sure, that sounds reasonable.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Attachment: This makes TestGtkEmbed happy, at least...

Comment 23

[Boris Zbarsky [:bzbarsky]]

I'll file a followup bug on a better API for this, but I'd really rather not
change apis on branch at this point if I can avoid it...

Comment 24

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

Comment on attachment 196581 [details] [diff] [review]
This makes TestGtkEmbed happy, at least...

Good enough for branch.

Comment 25

[Adam Guthrie]

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

Comment 26

[Simon Fraser [no longer active]]

Patch works in Camino. Thanks, bz!

Comment 27

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 28

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 196581 [details] [diff] [review]
This makes TestGtkEmbed happy, at least...

We should take this on the 1.8 branch...  Only affects embedding clients, and
is pretty safe.

Comment 29

[Brendan Eich [:brendan]]

Comment on attachment 196581 [details] [diff] [review]
This makes TestGtkEmbed happy, at least...

Yup.

/be

Comment 30

[Boris Zbarsky [:bzbarsky]]

Fixed on branch