Last Comment Bug 171229 - [FIX]Tooltip locations in frames and iframes are wrong
: [FIX]Tooltip locations in frames and iframes are wrong
Status: VERIFIED FIXED
: fixed1.8
Product: Core Graveyard
Classification: Graveyard
Component: Embedding: GRE Core (show other bugs)
: Trunk
: PowerPC Mac OS X
: P1 normal (vote)
: mozilla1.8beta5
Assigned To: Boris Zbarsky [:bz] (TPAC)
:
Mentors:
http://www.workbookstock.com/test/chi...
: 202001 309074 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-27 10:50 PDT by Mark Kawakami
Modified: 2016-06-23 14:32 PDT (History)
14 users (show)
brendan: blocking1.8b5+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
iframe doc (part of testcase) (1.77 KB, text/html)
2005-05-27 23:57 PDT, Simon Fraser
no flags Details
Testcase (329 bytes, text/html)
2005-05-27 23:59 PDT, Simon Fraser
no flags Details
Not quite working (4.88 KB, patch)
2005-09-16 22:37 PDT, Boris Zbarsky [:bz] (TPAC)
no flags Details | Diff | Splinter Review
This makes TestGtkEmbed happy, at least... (6.88 KB, patch)
2005-09-18 13:11 PDT, Boris Zbarsky [:bz] (TPAC)
roc: review+
roc: superreview+
brendan: approval1.8b5+
Details | Diff | Splinter Review

Description Mark Kawakami 2002-09-27 10:50:14 PDT
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. 2002-09-27 15:44:19 PDT
Mark, what build ID are you reporting this bug against? Also, please provide an
example URL or testcase attachment.
Comment 2 Mark Kawakami 2002-09-27 16:31:46 PDT
Greg:
I've noticed this in all the builds, but for the recrod, I'm using Build ID:
2002092704
Comment 3 Steve Smart 2002-10-24 18:54:46 PDT
confirmed in 2002102104
Comment 4 Simon Fraser 2002-12-31 17:45:02 PST
To pink.
Comment 5 Jasper 2003-09-02 13:57:46 PDT
Update please...
Comment 6 Martin Girschick 2004-02-06 10:17:52 PST
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 2004-11-08 16:02:54 PST
*** Bug 202001 has been marked as a duplicate of this bug. ***
Comment 8 Mike Pinkerton (not reading bugmail) 2005-01-18 07:28:45 PST
another url testcase is http://www.brodsoft.de/camino/frame.html
Comment 9 Simon Fraser 2005-05-27 23:57:53 PDT
Created attachment 184745 [details]
iframe doc (part of testcase)
Comment 10 Simon Fraser 2005-05-27 23:59:04 PDT
Created attachment 184746 [details]
Testcase
Comment 11 Simon Fraser 2005-05-28 00:02:54 PDT
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 2005-09-09 23:14:48 PDT
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 2005-09-10 01:18:21 PDT
Forgive my ignorance, but why is this completely different than Firefox?
Comment 14 Simon Fraser 2005-09-10 09:34:56 PDT
(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 [:bz] (TPAC) 2005-09-11 21:11:39 PDT
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) 2005-09-11 23:12:54 PDT
I would suggest just going through screen coordinates since this can't be
performance critical.
Comment 17 Boris Zbarsky [:bz] (TPAC) 2005-09-15 21:59:29 PDT
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 [:bz] (TPAC) 2005-09-16 22:37:31 PDT
Created attachment 196394 [details] [diff] [review]
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) 2005-09-17 20:18:14 PDT
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 [:bz] (TPAC) 2005-09-18 08:31:27 PDT
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) 2005-09-18 12:52:06 PDT
Sure, that sounds reasonable.
Comment 22 Boris Zbarsky [:bz] (TPAC) 2005-09-18 13:11:08 PDT
Created attachment 196581 [details] [diff] [review]
This makes TestGtkEmbed happy, at least...
Comment 23 Boris Zbarsky [:bz] (TPAC) 2005-09-18 13:14:44 PDT
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) 2005-09-18 13:37:11 PDT
Comment on attachment 196581 [details] [diff] [review]
This makes TestGtkEmbed happy, at least...

Good enough for branch.
Comment 25 Adam Guthrie 2005-09-18 15:18:04 PDT
*** Bug 309074 has been marked as a duplicate of this bug. ***
Comment 26 Simon Fraser 2005-09-18 20:11:39 PDT
Patch works in Camino. Thanks, bz!
Comment 27 Boris Zbarsky [:bz] (TPAC) 2005-09-18 20:21:19 PDT
Fixed on trunk.
Comment 28 Boris Zbarsky [:bz] (TPAC) 2005-09-18 20:21:41 PDT
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] 2005-09-18 23:15:15 PDT
Comment on attachment 196581 [details] [diff] [review]
This makes TestGtkEmbed happy, at least...

Yup.

/be
Comment 30 Boris Zbarsky [:bz] (TPAC) 2005-09-19 10:32:12 PDT
Fixed on branch

Note You need to log in before you can comment on or make changes to this bug.