Bug 15538 - offsetLeft/Top for absolutely positioned elements does not match Mozilla
Summary: offsetLeft/Top for absolutely positioned elements does not match Mozilla
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac (Intel) OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-17 04:41 PDT by Marcus Better
Modified: 2011-03-04 08:17 PST (History)
2 users (show)

See Also:


Attachments
Test case (1.50 KB, text/html)
2007-10-17 04:44 PDT, Marcus Better
no flags Details
The result on Firefox 2.0.0.7 (19.20 KB, image/png)
2007-10-17 04:46 PDT, Marcus Better
no flags Details
The result on WebKit r26570 (49.10 KB, image/png)
2007-10-17 04:55 PDT, Marcus Better
no flags Details
Corrected test case (1.67 KB, text/html)
2007-10-17 06:59 PDT, Marcus Better
no flags Details
The result on Firefox 2.0.0.7 (16.61 KB, image/png)
2007-10-17 07:04 PDT, Marcus Better
no flags Details
The result on WebKit r26570 (47.95 KB, image/png)
2007-10-17 07:04 PDT, Marcus Better
no flags Details
Test result on Internet Explorer 7 (35.31 KB, image/x-png)
2007-10-18 00:57 PDT, Marcus Better
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Better 2007-10-17 04:41:28 PDT
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.
Comment 1 Marcus Better 2007-10-17 04:44:21 PDT
Created attachment 16696 [details]
Test case

This shows what CSS attributes are included in the offsetLeft and offsetTop.
Comment 2 Marcus Better 2007-10-17 04:46:43 PDT
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.
Comment 3 Marcus Better 2007-10-17 04:55:57 PDT
Created attachment 16698 [details]
The result on WebKit r26570

This shows that different values are used for calculating offsetLeft and offsetTop compared to Mozilla.
Comment 4 Marcus Better 2007-10-17 06:29:12 PDT
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.
Comment 5 Marcus Better 2007-10-17 06:58:06 PDT
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.
Comment 6 Marcus Better 2007-10-17 06:59:08 PDT
Created attachment 16702 [details]
Corrected test case
Comment 7 Marcus Better 2007-10-17 07:04:01 PDT
Created attachment 16703 [details]
The result on Firefox 2.0.0.7
Comment 8 Marcus Better 2007-10-17 07:04:47 PDT
Created attachment 16704 [details]
The result on WebKit r26570
Comment 9 Dave Hyatt 2007-10-17 11:46:11 PDT
offsetLeft/Top are WinIE properties, and our goal (in general) is to match WinIE for these properties.  Can you post test results with WinIE?
Comment 10 Marcus Better 2007-10-18 00:57:22 PDT
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
Comment 11 Paul Bronshteyn 2009-11-10 22:05:16 PST
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
Comment 12 Jeremy Moskovich 2011-03-04 08:17:33 PST
The test now passes on a nightly build r80201 , please reopen if you're still seeing this.