Bug 15538 – offsetLeft/Top for absolutely positioned elements does not match Mozilla

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Marcus Better]

The offsetLeft and offsetTop values for an absolutely positioned child element of the BODY element do not match Mozilla's behaviour. This is probably a bug since WebKit mimics Mozilla in this area.

On Firefox 2 and Konqueror 3.5, the offsetLeft for the child (with position: absolute) is the sum of its left margin and left position.

On WebKit (r26570 nightly) is the sum of the child's left margin and the BODY element's padding.

[Marcus Better]

Created attachment 16696 [details]
Test case

This shows what CSS attributes are included in the offsetLeft and offsetTop.

[Marcus Better]

Created attachment 16697 [details]
The result on Firefox 2.0.0.7

This shows that Firefox includes the div margin and top/left values in the calculation of leftOffset.

[Marcus Better]

Created attachment 16698 [details]
The result on WebKit r26570

This shows that different values are used for calculating offsetLeft and offsetTop compared to Mozilla.

[Marcus Better]

Oops, it seems the problem here is something entirely different. The previous test case shows different behaviour, but it is misleading. Trying to find out more.

[Marcus Better]

So there was an error in the test case, but the bug still stands.

It turns out that WebKit includes _both_ the padding and border of the BODY element in the offsets, but excludes the elements top/left position. Mozilla does exactly the opposite.

[Marcus Better]

Created attachment 16702 [details]
Corrected test case

[Marcus Better]

Created attachment 16703 [details]
The result on Firefox 2.0.0.7

[Marcus Better]

Created attachment 16704 [details]
The result on WebKit r26570

[Dave Hyatt]

offsetLeft/Top are WinIE properties, and our goal (in general) is to match WinIE for these properties.  Can you post test results with WinIE?

[Marcus Better]

Created attachment 16717 [details]
Test result on Internet Explorer 7

As you see IE7 gives the same result as Firefox.

The comments on other bugs ([1], [2], [3]) suggest very strongly that WebKit tries to match Firefox here, which is why I assumed this was the case. But the real problem is that both FF and IE provide other methods of finding element positions, whereas on WebKit we are left with the notoriously unreliable, quirky and underdocumented offset* properties. So I guess any behaviour with a clean specification would be preferable to following the dozens of quirks in other browsers, plus some WebKit-specific ones. (From my tests, Konqueror's implementation appears to be the most predictable and useful of them all - but it's different from all the others...)

[1] http://bugs.webkit.org/show_bug.cgi?id=14722#c9
[2] http://bugs.webkit.org/show_bug.cgi?id=11109#c10

[Paul Bronshteyn]

My test case might be related to this issue. In the example the two sides are identical except for the right panels <a name=""> tag having a space as innerHTML.

offsetTop is reported differently for those elements.

http://www.pibik.com/webkit_offset_bug.html

[Jeremy Moskovich]

The test now passes on a nightly build r80201 , please reopen if you're still seeing this.