Bug 15897 – Please implement getBoundingClientRect and getClientRects

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Marcus Better]

The getBoundingClientRect method on HTMLElement is a reasonably clean way to find the position of an element. It was originally implemented in Internet Explorer [1] and has now been added to Gecko [2, 3]. Also its companion function getClientRects [4] could be useful.

The only option currently is an error prone summation along the offsetParent chain, followed by another one up the DOM tree to add in scrolling. This is very error-prone. Having a way to find element positions is absolutely necessary for rich web applications.

Since the request to add getBoxObjectFor (bug #8154) was rejected, please consider implementing this instead.


[1] http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/getboundingclientrect.asp
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=174397
[3] http://developer.mozilla.org/en/docs/DOM:element.getBoundingClientRect
[4] http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/getclientrects.asp

[Mark Wubben]

I'd also like to see this added to Webkit. Especially getClientRects is useful for text editing applications.

[José Jeria]

Note that this has now also been implemented by Opera 9.5

[Sjoerd Visscher]

See also the new W3C spec for these methods: 
http://www.w3.org/TR/cssom-view/

[Robbert Broersma]

I would also very much appreciate this feature being implemented.

[William J. Edney]

Webkit guys -

I'll vote for this one as well. See John Resig's post here:

http://ejohn.org/blog/getboundingclientrect-is-awesome

on why this method is cool and useful.

Note that Firefox 3 is deprecating their getBoxObjectFor() method in deference to this mechanism.

Cheers,

- Bill

[Alexey Proskuryakov]

<rdar://problem/6139669>

[Simon Fraser (smfr)]

Another reason to do this is that getBoundingClientRect() will take transforms into account, and therefore provide something better than offsetLeft/offsetParent.

[Sam Weinig]

Created attachment 27427 [details]
First pass

Uploading an initial implementation of the feature.  Some things to note:
1) It needs tests
2) It is based of the January 23, 2009 Draft found at http://dev.w3.org/csswg/cssom-view/ .
3) I don't think we handle SVG correctly according to that draft.
4) I am not sure what to do about transformations/zoom.

[Sam Weinig]

Created attachment 27443 [details]
Take 2

This takes care of transformations and adds a test.

[Sam Weinig]

Created attachment 27471 [details]
patch

I think this is ready for review now.  There are few known cases where we don't work correctly, but those can be handled in follow up bugs.

[Eric Seidel (no email)]

Comment on attachment 27471 [details]
patch

Soo so sad that we're propagating the silly term "client rect" even further. :(

[Dave Hyatt]

Comment on attachment 27471 [details]
patch

My big high-level concern here is that absoluteQuads isn't going to be a match for what you want.  It's really sort of doing just what Web inspector needs it to do, and so is very inconsistent.  It doesn't include visible overflow for blocks (or any spillage from floats/positioned elements).  For inlines, taller elements on the line *are* included, etc.

Ultimately absoluteRects/Quads may need a big set of options passed into them regarding what kind of rects we return.

We will need a lot of tests to know if these methods are a good fit.

[Sam Weinig]

Created attachment 27535 [details]
updated patch

This updated patch includes a few more tests, some of which are known to fail, and a fix to RenderInline not to include children in the absoluteQuad/absoluteRect functions.  I will file bugs on all the remaining known issues so we can follow up on them individually.

[Dave Hyatt]

Comment on attachment 27535 [details]
updated patch

r=me

[Sam Weinig]

Landed in r40837.

[Robert O'Callahan]

I was actually hoping the spec would treat CSS transforms like foreignobject, as establishing a new viewport.

[Garrett Smith]

Created attachment 28118 [details]
Example (testcase) showing failure in Webkit

When the window is scrolled, the value returned is incorrect.

getBoundingClientRect method is designed to return the distance from viewport's top/left [1].  It works this way in IE, Gecko, Opera. 

However in Webkit, getBoundingClientRect returns the distance from the top/left of the documentElement. 

[1]http://msdn.microsoft.com/en-us/library/ms536433(VS.85).aspx

This means that if the viewport is scrolled, the returned position of box.top is incorrect. This is because the position is taken from documentElement, not viewport.  The example result shows that to be true.

Test Results:
Gecko, Opera:
  top: -100
  left: -99

Webkit:
  top: 0
  left: 1

Comment #10, Sam, can you please specify which known cases do not work correctly? 

Comment #4, it seems strange that work on this bug began without tests. Even more strange that the work got checked in. However, since I see no tests, it seems to be true. Can you please explain?

[Sam Weinig]

(In reply to comment #17)
> Created an attachment (id=28118) [review]
> Example (testcase) showing failure in Webkit
> 
> When the window is scrolled, the value returned is incorrect.
> 
> getBoundingClientRect method is designed to return the distance from viewport's
> top/left [1].  It works this way in IE, Gecko, Opera. 
> 
> However in Webkit, getBoundingClientRect returns the distance from the top/left
> of the documentElement. 
> 
> [1]http://msdn.microsoft.com/en-us/library/ms536433(VS.85).aspx
> 
> This means that if the viewport is scrolled, the returned position of box.top
> is incorrect. This is because the position is taken from documentElement, not
> viewport.  The example result shows that to be true.
> 
> Test Results:
> Gecko, Opera:
>   top: -100
>   left: -99
> 
> Webkit:
>   top: 0
>   left: 1

This bug was fixed in http://trac.webkit.org/changeset/41207 .

> 
> Comment #10, Sam, can you please specify which known cases do not work
> correctly? 
> 
> Comment #4, it seems strange that work on this bug began without tests. Even
> more strange that the work got checked in. However, since I see no tests, it
> seems to be true. Can you please explain?
> 

This patch was checked in with two tests.
- http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/getBoundingClientRect.html
- http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/getClientRects.html

They are even in the attached patch so I am a little confused.

A subsequent test was added when fixing the scrolling issue.
- http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/getBoundingClientRect-getClientRects-relative-to-viewport.html

Regarding what is known not to work, the provided tests include known failures including an inline in a column, and a float in an inline for getBoundingClientRect and a table with a caption for getClientRects.  If you find other bugs, please file them in a new report.