Opened 13 years ago

Closed 13 years ago

#8047 closed defect (fixed)

IE8: dojo.coords offset off by 2px issue

Reported by: James Burke Owned by: James Burke
Priority: high Milestone: 1.3
Component: Core Version: 1.2.0
Keywords: Cc:
Blocked By: Blocking:

Description

Investigating DOH failures with IE8, one is with dojo.coords() on an absolute positioned image. Simplified test case derived from DOH test page attached.

It seems like in dojo._base.html, the dojo._getIeDocumentElementOffset() no longer returns a top, left offset of 2, so the reported numbers for the x and y of the absolute positioned element come back as 102 instead of 100.

Attachments (1)

htmlie2.html​ (1.2 KB) - added by James Burke 13 years ago.
Place in the dojo/tests/_base directory

Download all attachments as: .zip

Change History (13)

Changed 13 years ago by James Burke

Attachment: htmlie2.html​ added

Place in the dojo/tests/_base directory

comment:1 Changed 13 years ago by James Burke

This may be part of #8081.

comment:2 Changed 13 years ago by bill

Owner: changed from anonymous to bill
Status: new → assigned

comment:3 Changed 13 years ago by bill

Resolution: → fixed
Status: assigned → closed

I think I've fixed this plus did some cleanup, in [15730] and [15731].

comment:4 Changed 13 years ago by James Burke

Resolution: fixed
Status: closed → reopened

Hmm, for IE8 standards mode, the attached test file still reports 102 and 102 for the x, y coordinates.

Comparing document.documentElement.offsetWidth vs. window.offsetWidth gives a difference of 4 pxs, so I can see where half of that might be used to get the 2px difference. Same with the offsetTop properties. Not sure I like relying on window. Maybe that is the way to go, still need to consider more.

comment:5 Changed 13 years ago by James Burke

Owner: changed from bill to James Burke
Status: reopened → new

So I think IE8 still needs to go through getIeDocumentElementOffset() too, and this offset calculated, btw. Need to also consider how RTL might be affected.

comment:6 Changed 13 years ago by bill

You are right.... I checked in some code for IE8 in [15776], it seems to work in both strict and quirks mode.

It takes into account a margin setting on <html> (admittedly, that has no purpose, but our test case does it), and the scroll of the browser window.

comment:7 Changed 13 years ago by bill

Resolution: → fixed
Status: new → closed

(In [16052]) Fix dojo.coords() on IE in quirksmode. Patch from Nic (CLA on file), thanks Nic! Fixes #8047, refs #8247 !strict.

comment:8 Changed 13 years ago by James Burke

Resolution: fixed
Status: closed → reopened

The attached htmlie2.html test file (renders in IE8 standards mode) still reports x and y as 102 instead of 100, so I think there is still some work to be done related to the offset. I am going to try to reduce the test case to plain JS and see if I can ask Microsoft about it.

comment:9 Changed 13 years ago by bill

Summary: IE8: dojo.coords offset issue → IE8: dojo.coords offset off by 2px issue

comment:10 Changed 13 years ago by bill

(In [16418]) IE8: Fix problem with dojo._abs() when page is scrolled. Fixes #8429, #8441, #8460. Refs #8047 but that is still an open issue. !strict

comment:11 Changed 13 years ago by James Burke

Priority: normal → high

comment:12 Changed 13 years ago by James Burke

Resolution: → fixed
Status: reopened → closed

(In [16485]) Fixes #8047: IE8rc1 is much better now, and we do not need an offset calculation for nodes. There is still an issue with rtl direction and the offsetLeft, but will open a separate bug on that, but I believe it is Microsoft's to fix, it is a strange negative number. \!strict

Note: See TracTickets for help on using tickets.