81290 - offsetTop and offsetLeft gives wrong values in relative and absolute positioned parents

Status: VERIFIED FIXED

(Core :: DOM: CSS Object Model, defect)

Description

[Erik Arvidsson]

The offsetLeft and offsetTop values (and getComputedStyle...) should give the 
position in the current coordinate space and not the browser viewport space.

For example an absolute positioned element positioned at 100px left inside 
another element with either position absolute or relative (fixed as well I 
guess) should return an offsetLeft value of 100 and not 100 plus the offsetLeft 
of the parent.

This is important because an element that has position absolute or relative 
should not be moved by the following statement:

element.style.left = element.offsetLeft

The offsetLeft/Top should follow the same rules as style.left/top do when it 
comes to coordinate spaces.

Build tested on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9+) 
Gecko/20010510

Comment 1

[Erik Arvidsson]

Attachment: Clicking an element alerts the offsetLeft and offsetTop values and this should be the same as the text in the element

Comment 2

[Erik Arvidsson]

Attachment: Updated the old attachment to also alert the comptedStyle and made it a little bit easier to figure out what case each div represents.

Comment 3

[Erik Arvidsson]

The last test case shows that getComputedStyle seems to return the correct 
value for an absolutetly positioned element even when it is located inside an 
element defining its own coordinate space. Why that value is different from the 
offset value is beyond me.

Comment 4

[Johnny Stenback (:jst)]

Nominating for mozilla0.9.2, not sure we can fix this completely in time for
mozilla0.9.2, but we can fix at least parts of it, and IMO that's worth doing
since this breaks alot of "dhtml".

Comment 5

[Wolfgang Schwarz]

I think this is a duplicate of bug 34398.

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** Bug 86844 has been marked as a duplicate of this bug. ***

Comment 7

[Johnny Stenback (:jst)]

Attachment: Proposed fix.

Comment 8

[Johnny Stenback (:jst)]

The patch I just attached fixes .offsetXXX to work exactly like IE does in the
attached testcase, but now I need help. I need someone to apply the patch and
build mozilla with my patch and then go through all my, and [e-mail]'s
bugs (fixed, verified, unconfirmed, new, you name it) in bugzilla that have to
do with the .offsetXXX properties and make sure that I didn't break something
that used to work. Anyone up for doing that?

Comment 9

[Bob Clary [:bc] (inactive)]

Ok, I applied the patch to 1.261 and merged with the changes from 1.262. Will
test and report in the appropriate bugs.

Comment 10

[Johnny Stenback (:jst)]

Attachment: Updated patch that applies after dbaron's interface changes

Comment 11

[Johnny Stenback (:jst)]

Moving to mozilla0.9.3

Comment 12

[Johnny Stenback (:jst)]

Fix checked in on the trunk, this should go onto the branch once we've let it
live on the trunk for a while.

Comment 13

[Markus Hübner]

current status ?

Comment 14

[Johnny Stenback (:jst)]

Fixed on the mozilla trunk, waiting for approval to check this into the Netscape
RTM branch.

Comment 15

[Heikki Toivonen (remove -bugzilla when emailing directly)]

nsBranch ok, IE compatibility, code path exercised only in this special case so
should not cause problems elsewhere.

Comment 16

[harishd]

The testcases work fine.

Verified with build ID 20010070604.

Comment 17

[Nisheeth Ranjan]

This fix has baked on the trunk for more than a week.  The only codepath that is
affected by this change is the offsetTop and offsetLeft property getter/setters.
 These properties are not used by the scripts in the Mozilla suite of
applications so the possibility of regressions is low.  These properties were
partially implemented and shipped in Netscape 6.0 to match IE's behaviour.  With
this patch checked into Netscape 6.1, we will match IE's implementation much
more closely.  Web developers will be able to use these properties to create
reliable cross-browser content.

Marking nsBranch+.

Comment 18

[Johnny Stenback (:jst)]

Fix checked in on the branch.

Comment 19

[lchiang]

Ian - pls verify this on the branch builds at your earliest convenience. Thanks.

Comment 20

[Hixie (not reading bugmail)]

VERIFIED on branch per 
   http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34822
Marking VERIFIED since trunk has already been verified.