Open
Bug 281684
Opened 20 years ago
Updated 2 years ago
BoxObjects's offsetRect weird
Categories
(Core :: DOM: Core & HTML, defect, P5)
Tracking
()
NEW
People
(Reporter: bzbarsky, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(1 file)
521 bytes,
application/xhtml+xml
|
Details |
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•20 years ago
|
||
Comment 2•20 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•20 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•20 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•20 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•20 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...
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: ian → general
Comment 8•7 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•