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•6 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
•