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?
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.)
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...
To clarify, the tree body frame has a method AdjustEventCoordsToBoxCoordSpace that needs to be kept in sync with any box coordinate changes.
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?
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...
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.