Created attachment 400831 [details] Repro / example The values returned by getClientBoundingRect (gCBR) of an element with a transform transition, when used in requestAnimationFrame (rAF), appear to describe what is presented rather than what will be painted post rAF. But in Chrome and FF, gCBR values consistently match what _will be_ painted, such that gCBR can be used to perfectly align elements to other transitioning elements (see attached example in Safari and Chrome). Reading the specs for getClientBoundingRect and requestAnimationFrame, I can't yet tell whether the data in this situation is _supposed_ to agree with what is on screen or what _will_ be on screen. The inconsistency is a paint point though.
Correction: In FF, if a transform transition is interrupted by writing new transform values, there appears to be one frame where the gCBR values don't align with what will be drawn.
Created attachment 400834 [details] Expected behavior (Chrome)
Created attachment 400835 [details] Actual behavior (Safari)
<rdar://problem/63902988>
Interesting. We do update animations before firing rAF callbacks, but maybe we haven't competed new transforms in RenderLayer::updateTransform(). Having said that, any getBoundingClientRect should trigger a layout if necessary. But maybe the animation hasn't marked the renderer as needing layout?
This does not reproduce if using the "left" and "top" properties, so this appears to be specific to accelerated transitions when using "transform".
Created attachment 405687 [details] Test using "left" and "top" properties
Created attachment 405688 [details] Test using "transform" property
The "transform" test also shows the occasional flashing back to the original position after a transition completes :(
The flashing could be a manifestation of bug 212637.
( FWIW, the same behavior occurs with getScreenCTM(). )