Bug 212640

Summary: getBoundingClientRect() values in requestAnimationFrame callback different from those in Chrome and FF when using a "transform" transition
Product: WebKit Reporter: ian
Component: AnimationsAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: dino, graouts, graouts, sabouhallawa, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Safari 13   
Hardware: Mac   
OS: macOS 10.15   
See Also: https://bugs.webkit.org/show_bug.cgi?id=212637
Attachments:
Description Flags
Repro / example
none
Expected behavior (Chrome)
none
Actual behavior (Safari)
none
Test using "left" and "top" properties
none
Test using "transform" property none

ian
Reported 2020-06-02 09:24:42 PDT
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.
Attachments
Repro / example (2.19 KB, text/html)
2020-06-02 09:24 PDT, ian 		no flags
Details
Expected behavior (Chrome) (98.21 KB, video/quicktime)
2020-06-02 10:16 PDT, ian 		no flags
Details
Actual behavior (Safari) (104.75 KB, video/quicktime)
2020-06-02 10:16 PDT, ian 		no flags
Details
Test using "left" and "top" properties (2.28 KB, text/html)
2020-07-31 06:51 PDT, Antoine Quint 		no flags
Details
Test using "transform" property (2.19 KB, text/html)
2020-07-31 06:52 PDT, Antoine Quint 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
ian
Comment 1 2020-06-02 09:33:01 PDT
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.
ian
Comment 2 2020-06-02 10:16:04 PDT
Created attachment 400834 [details] Expected behavior (Chrome)
ian
Comment 3 2020-06-02 10:16:39 PDT
Created attachment 400835 [details] Actual behavior (Safari)
Radar WebKit Bug Importer
Comment 4 2020-06-02 18:34:57 PDT
<rdar://problem/63902988>
Simon Fraser (smfr)
Comment 5 2020-06-02 21:10:11 PDT
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?
Antoine Quint
Comment 6 2020-07-31 06:51:23 PDT
This does not reproduce if using the "left" and "top" properties, so this appears to be specific to accelerated transitions when using "transform".
Antoine Quint
Comment 7 2020-07-31 06:51:49 PDT
Created attachment 405687 [details] Test using "left" and "top" properties
Antoine Quint
Comment 8 2020-07-31 06:52:09 PDT
Created attachment 405688 [details] Test using "transform" property
Antoine Quint
Comment 9 2020-07-31 06:53:25 PDT
The "transform" test also shows the occasional flashing back to the original position after a transition completes :(
Antoine Quint
Comment 10 2020-07-31 06:57:44 PDT
The flashing could be a manifestation of bug 212637.
ian
Comment 11 2020-07-31 07:05:33 PDT
( FWIW, the same behavior occurs with getScreenCTM(). )
Note You need to log in before you can comment on or make changes to this bug.