Created attachment 285316 [details] Demo of the bug getBoundingClientRect reports incorrect 'top' and 'left' values when the page is pinch-zoomed. I've narrowed down the problem to Document::adjustFloatRectForScrollAndAbsoluteZoomAndFrameScale, which subtracts the Frame's scroll position (which is already in CSS pixels, i.e. is divided by the frameScaleFactor) from the rect and then scales the rect by 1/frameScaleFactor. This means the frame's scroll position, as applied to the rect, is scaled by frameScaleFactor twice. It also seems to me that the bounding box returned in Element::getBoundingClientRect has the position in CSS pixels by the size in DIPs. That is, printf'ing the FloatRect returned by quads[0].boundingBox() shows that pinch-zooming in causes the size to increase but not the position. If I want to get the correct getBoundingClientRect as a page author today, I have to perform this calculation: var rect = element.getBoundingClientRect(); var pageScaleFactor = window.outerWidth / window.innerWidth; var correctedTop = rect.top*pageScaleFactor + window.scrollY*pageScaleFactor - window.scrollY; I've attached a demo page showing the bug. It *should* keep the red box fixed to the top of the viewport but you can see that scrolling causes the box to move down faster than the page. You can uncomment the "corrected" calculation to see how it should look. I've also hosted this at http://bokan.ca/getBoundingClientRectBug.html for convenience.
The behavior in Safari Tech Preview 33 matches Chrome Canary -- the box's bounding client rect remains (0, 0) 100x100 under pinch zoom + scroll, so the box stays fixed to the top of the layout viewport. David, can you double-check that this is no longer a bug?
Yes, it looks like this works correctly as of Safari 10.1.1