[FIX]Tooltip locations in frames and iframes are wrong

VERIFIED FIXED in mozilla1.8beta5

Status

Core Graveyard
Embedding: GRE Core
P1
normal
VERIFIED FIXED
15 years ago
a year ago

People

(Reporter: Mark Kawakami, Assigned: bz)

Tracking

({fixed1.8})

Trunk
mozilla1.8beta5
PowerPC
Mac OS X
fixed1.8
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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

15 years ago
Mark, what build ID are you reporting this bug against? Also, please provide an
example URL or testcase attachment.
Summary: Tooltips in iframes are positioned relative to parent viewport → Tooltips in IFRAMEs are positioned relative to parent viewport
(Reporter)

Comment 2

15 years ago
Greg:
I've noticed this in all the builds, but for the recrod, I'm using Build ID:
2002092704
(Reporter)

Updated

15 years ago

Comment 3

15 years ago
confirmed in 2002102104
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

15 years ago
To pink.
Assignee: saari → pinkerton

Updated

15 years ago
Summary: Tooltips in IFRAMEs are positioned relative to parent viewport → Tooltip locations in frames and iframes are wrong
Target Milestone: --- → Chimera1.1

Comment 5

14 years ago
Update please...

Comment 6

14 years ago
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

13 years ago
*** Bug 202001 has been marked as a duplicate of this bug. ***
another url testcase is http://www.brodsoft.de/camino/frame.html
Target Milestone: Camino1.1 → Camino1.0

Comment 9

12 years ago
Created attachment 184745 [details]
iframe doc (part of testcase)

Comment 10

12 years ago
Created attachment 184746 [details]
Testcase

Comment 11

12 years ago
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

12 years ago
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

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

Comment 14

12 years ago
(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....
Flags: blocking1.8b5?
I would suggest just going through screen coordinates since this can't be
performance critical.

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5-
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...
Attachment #196394 - Flags: review?(roc)
You could go get the document's presentation's view manager's root view's
widget, that has to be correct. :-|
Attachment #196394 - Flags: review?(roc)
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...
Attachment #196394 - Attachment is obsolete: true
Attachment #196581 - Flags: superreview?(roc)
Attachment #196581 - Flags: review?(sfraser_bugs)
(Assignee)

Updated

12 years ago
Attachment #196581 - Flags: superreview?(roc)
Attachment #196581 - Flags: review?(sfraser_bugs)
(Assignee)

Updated

12 years ago
Assignee: pinkerton → dougt
Component: General → Embedding: GRE Core
Product: Camino → Core
QA Contact: winnie
Target Milestone: Camino1.0 → ---
Version: unspecified → Trunk
(Assignee)

Updated

12 years ago
Attachment #196581 - Flags: superreview?(roc)
Attachment #196581 - Flags: review?(sfraser_bugs)
(Assignee)

Updated

12 years ago
Assignee: dougt → bzbarsky
Priority: -- → P1
Summary: Tooltip locations in frames and iframes are wrong → [FIX]Tooltip locations in frames and iframes are wrong
Target Milestone: --- → mozilla1.8beta5
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.
Attachment #196581 - Flags: superreview?(roc)
Attachment #196581 - Flags: superreview+
Attachment #196581 - Flags: review?(sfraser_bugs)
Attachment #196581 - Flags: review+

Comment 25

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

Comment 26

12 years ago
Patch works in Camino. Thanks, bz!
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
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.
Attachment #196581 - Flags: approval1.8b5?

Updated

12 years ago
Flags: blocking1.8b5- → blocking1.8b5+
Comment on attachment 196581 [details] [diff] [review]
This makes TestGtkEmbed happy, at least...

Yup.

/be
Attachment #196581 - Flags: approval1.8b5? → approval1.8b5+
Fixed on branch
Keywords: fixed1.8

Updated

12 years ago
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.