BoxObjects's offsetRect weird

NEW
Unassigned

Status

()

P5
normal
14 years ago
4 months ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
The boxobject gets the offsetrect in the coordinates of the innermost frame of
the root element containing the target frame.

This seems wrong.  I'll post a testcase where this leads to an offset of 0 when
I believe we should be getting a nonzero offset.

It seems to me that we want to be using coordinates relative to the _outermost_
frame containing the target frame...

Neil, is the behavior of this function actually specified, anywhere?
(Reporter)

Comment 1

14 years ago
Created attachment 173875 [details]
Testcase showing the problem

Comment 2

14 years ago
I don't really care what coordinate system box objects use as long as it agrees
with events. (And no, I don't know what coordinate system they use either.)
(Reporter)

Comment 3

14 years ago
Which exact event coordinate system?  Our events expose screenX/Y, clientX/Y,
layerX/Y, and pageX/Y.  None of those are in the same coordinate system as the
current BoxObject code in all situations, nor would they be with my proposed change.

pageX/Y comes closest, I think, except when there are non-root scrollable frames
or events in popups involved...

Comment 4

14 years ago
To clarify, the tree body frame has a method AdjustEventCoordsToBoxCoordSpace
that needs to be kept in sync with any box coordinate changes.
(Reporter)

Comment 5

14 years ago
Er... that method already seems to be out of sync (eg if the tree is inside a
scrollable div that's scrolled, the two sets of coordinates should be off from
each other, as far as I can tell).

Is there any documentation _anywhere_ on what boxObject and event should use as
their various coordinate systems?
(Reporter)

Comment 6

14 years ago
Actually, it looks like the HTML offset* code has the same problem.  In brief,
both places seem to be assuming that frame ==
GetPrimaryFrameFor(frame->mContent).  That's really not a good assumption...
(Reporter)

Comment 7

14 years ago
Note also bug 291351    	
Depends on: 291351
Assignee: general → nobody
QA Contact: ian → general
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.