Bug Tracker

Modify

Ticket #3508 (closed bug: fixed)

Opened 5 years ago

Last modified 4 years ago

Problem with IE and offset/getBoundingClientRect

Reported by: jeffkretz Owned by: brandon
Priority: undecided Milestone: 1.3
Component: dimensions Version: 1.2.6
Keywords: offset Cc: brandon, paul, jeffkretz
Blocking: Blocked by:

Description

After plumbing for quite a while, I've finally isolated what I believe is the source of an offset problem with IE, and I think it is related to a bug in the getBoundingClientRect function as applies to the documentElement.

Please see test case at  http://test1.scorpiondesign.com/LocalTest2.htm.

You'll notice in IE6/7 when you scroll the window down and then drag, the position "jumps" the amount of the scroll bar.

Now watch the counters displaying information about it.

The helper is the <table> element. It's offset parent is the <html> element.

In FF3 and Opera you'll see the parent's offset is calculated correctly. You'll also notice that the document.documentElement.getBoundingRect() function returns a negative value, which is handled by adding in the document.scrollTop.

In IE6 and IE7, the parent's offset is calculated INCORRECTLY, and the document.documentElement.getBoundingRect() returns the top position of the HTML element (rather than the viewport), so when adding in the scrollTop, you get a wildly wrong offset top.

FF2, Chrome and Safari do not implement getBoundingRect, but the alternative calculation comes out correctly.

I wasn't sure the best approach here -- should the offset function do a MSIE detection and adjust the getBoundingClientRect values for the HTML element?

JK

Attachments

offset.patch Download (1.1 KB) - added by jeffkretz 5 years ago.

Change History

comment:1 Changed 5 years ago by john

  • Cc brandon, paul added

Hmm, not sure which aspect might be causing this - any thoughts Paul or Brandon?

comment:2 Changed 5 years ago by jeffkretz

Any feedback on this? It seems browser detection on the getBoundingRect function may be necessary.

What do you think?

JK

comment:3 Changed 5 years ago by jeffkretz

I hesitate to fiddle with such a core component of the system, but I've put in a browser-detection workaround which has solved the issue for me.

The patch is attached.

Can someone review this for potential inclusion?

JK

Changed 5 years ago by jeffkretz

comment:4 Changed 4 years ago by dmethvin

  • Cc jeffkretz added

Jeff, if this is still an issue can you attach the test case? The link no longer works.

comment:5 Changed 4 years ago by jeffkretz

I've restored the test case -- the link works again. JK

comment:6 Changed 4 years ago by jeffkretz

This ticket should be closed as handled, I just tested the problem with 1.3 and everything is working fine. JK

comment:7 Changed 4 years ago by brandon

  • Status changed from new to closed
  • Resolution set to fixed

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.