Skip to main content

Bug Tracker

Side navigation

#8969 closed bug (duplicate)

Opened April 25, 2011 04:20PM UTC

Closed April 25, 2011 04:38PM UTC

Last modified April 25, 2011 04:38PM UTC

offset() returns incorrect value after CSS transform in WebKit

Reported by: kwantam@gmail.com Owned by:
Priority: undecided Milestone: 1.next
Component: unfiled Version: 1.5.2
Keywords: Cc:
Blocked by: Blocking:
Description

In some (most?) cases, offset() uses getBoundingClientRect(). However, there is an inconsistency between Gecko and WebKit-based browsers in the getBoundingClientRect(); in particular, WebKit returns values with the transform applied, whereas Gecko does not apply the transform to its return value.

For example,

<div id="outside">

<section id="tContainer">

<table><tr><td>test</td></tr></table>

</section>

</div>

$('#tContainer').offset() returns some value.

However, if (e.g., in Chrome) we apply a transform such as

$('#outside').css('-webkit-transform','scale(2) translate(10px, 10px)')

then $('#tContainer').offset() returns a different value. After applying the same transform (but using '-moz-transform' instead) in FF, $('#tContainer').offset() is unchanged.

It's not particularly difficult to undo the transform when WebKit is detected. It seems to me this would be more useful behavior.

Attachments (0)
Change History (3)

Changed April 25, 2011 04:32PM UTC by kwantam@gmail.com comment:1

Seems my search-fu was a bit weak. #8362 is the same issue. Apologies for the duplicate.

As penance, here's a quick way to actually undo the transform that WebKit applies (continuing the above example):

var halfWidth = $('#outside').width()/2;

var halfHeight = $('#outside').height()/2;

var elm = $('tContainer');

var pTrans = buffer.css('-webkit-transform').split(',').map(parseFloat);

var absXoff = halfWidth - (halfWidth - elm.offset().left + pTrans[4])/pTrans[3];

var absYoff = halfHeight- (halfHeight - elm.offset().top + pTrans[5])/pTrans[3];

This only works if you've applied the same scale to X and Y (in which case the transform matrix is [scale,0;0,scale]). Handling an arbitrary transform matrix is less straightforward.

Changed April 25, 2011 04:38PM UTC by timmywil comment:2

resolution: → duplicate
status: newclosed

Changed April 25, 2011 04:38PM UTC by timmywil comment:3

Duplicate of #8362.