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.
Mark, what build ID are you reporting this bug against? Also, please provide an example URL or testcase attachment.
Greg: I've noticed this in all the builds, but for the recrod, I'm using Build ID: 2002092704
confirmed in 2002102104
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+)
*** Bug 202001 has been marked as a duplicate of this bug. ***
another url testcase is http://www.brodsoft.de/camino/frame.html
I guess we should we fix the caller of nsITooltipListener here: http://lxr.mozilla.org/mozilla/source/embedding/browser/webBrowser/nsDocShellTreeOwner.cpp#1122
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.
Forgive my ignorance, but why is this completely different than Firefox?
(In reply to comment #13) > Forgive my ignorance, but why is this completely different than Firefox? Because Firefox tooltips are done using XUL.
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....
I would suggest just going through screen coordinates since this can't be performance critical.
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...
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...
You could go get the document's presentation's view manager's root view's widget, that has to be correct. :-|
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?
Sure, that sounds reasonable.
Created attachment 196581 [details] [diff] [review] This makes TestGtkEmbed happy, at least...
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 on attachment 196581 [details] [diff] [review] This makes TestGtkEmbed happy, at least... Good enough for branch.
*** Bug 309074 has been marked as a duplicate of this bug. ***
Patch works in Camino. Thanks, bz!
Fixed on trunk.
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 on attachment 196581 [details] [diff] [review] This makes TestGtkEmbed happy, at least... Yup. /be
Fixed on branch