330619 - boxObject positions now depend on scroll position

Status: RESOLVED DUPLICATE of bug 334765

(Core :: Layout, defect)

Description

[Dave Townsend [:mossop]]

Previous to bug 328881, the x and y attributes of boxObject for elements inside a scrolled box returned values relative to the total box size (including the invisible areas). Afterwards, the values are now relative to the scrolled viewport, so negative values come up etc.

Testcase coming.

Comment 1

[Dave Townsend [:mossop]]

Attachment: Test

This testcase contains a scrollable area with a box in it. Clicking the position button should display the same values at all times (and does so on 1.8 branch builds). On current trunk however the values change depending on where the area is scrolled to.

Comment 2

[Boris Zbarsky [:bzbarsky]]

See bug 291351.

For what it's worth, I'm pretty sure we had existing bugs on the fact that box object coords did NOT take scrolling into account.

Note that not taking scrolling into account gives you, generally speaking, completely bogus numbers if there are multiple scrollbars involved.  So I'm tempted to say we should wontfix this.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Turns out that Google Calendar is using getBoxObjectFor().x etc and my change broke it (accidentally), so I'm going back to the old behaviour. If we want position info with scrolling taken into account, I think we'll have to add new boxObject properties for that. Or maybe we should just define a new position-getting API that doesn't require box objects and acts sanely for elements with continuations and is adopted by WHATWG.

*** This bug has been marked as a duplicate of 334765 ***