GetBounds() always returns (0, 0) on Linux and Mac

VERIFIED WONTFIX

Status

()

P3
normal
VERIFIED WONTFIX
19 years ago
19 years ago

People

(Reporter: sharon.bregante-candau, Assigned: blizzard)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
****This needs to be reassigned to blizzard@mozilla.org, it didn't work when I
tried to do this************

There is an awful disparity between the unix and windows widget library
implementations.

On windows, GetBounds() on a nsIWidget will give you the (x,y) relative
to the parent.

On unix (and on the mac too, i think), GetBounds() will always return
(0,0) for the (x,y) coordinates.

I think you can use an alternate API to set up the (x,y) so that a
plugin eventually gets coordinates that are useful.

You will have to change the plugin code in mozilla that sets this up.
You can use:

http://lxr.mozilla.org/seamonkey/ident?i=WidgetToScreen

On both the widget in question and its parent.  The (x,y) of the widget
will be the difference.  I think ???  pavlov@netscape.com will know
more.

Now, the real solution to this would be for the gtk implementation to do
the same thing as windows.  Cache the (x,y) bounds in nsWidget and have
GetBounds() return them as opposed to (0,0).

The last time I tried this, a lot of things broke, like XP menus, and
absolutely positioned <div>.

blizzard: I bet superwin fixed this!

-re
(Reporter)

Updated

19 years ago
Assignee: pavlov → blizzard
(Assignee)

Comment 1

19 years ago
Pav, don't you have a fix for this?
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

19 years ago
I've played with this a little bit.  It breaks menus pretty badly but I think
it's fixable.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 3

19 years ago
I don't know what this breaks.

Comment 4

19 years ago
after careful consideration, marking this bug VERIFIED
Status: RESOLVED → VERIFIED
(Assignee)

Updated

19 years ago
Assignee: blizzard → blizzard
Status: VERIFIED → NEW
(Assignee)

Comment 5

19 years ago
Please ignore the spam.  Changing address.
(Assignee)

Comment 6

19 years ago
bustage from my reassign
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
(Assignee)

Comment 7

19 years ago
bustage from my reassign
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.