[Web Animations] Animated transform styles are ignored when calling getComputedStyle()
Created attachment 336316 [details] Patch
Comment on attachment 336316 [details] Patch Attachment 336316 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/7067888 New failing tests: imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/interpolation-per-property.html imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/accumulation-per-property.html fast/css/getComputedStyle/getComputedStyle-transform.html
Created attachment 336320 [details] Archive of layout-test-results from ews101 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-sierra Platform: Mac OS X 10.12.6
Comment on attachment 336316 [details] Patch Attachment 336316 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/7067897 New failing tests: imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/interpolation-per-property.html imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/accumulation-per-property.html fast/css/getComputedStyle/getComputedStyle-transform.html
Created attachment 336322 [details] Archive of layout-test-results from ews106 for mac-sierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-sierra-wk2 Platform: Mac OS X 10.12.6
Comment on attachment 336316 [details] Patch Attachment 336316 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/7067930 New failing tests: fast/css/getComputedStyle/getComputedStyle-transform.html
Created attachment 336327 [details] Archive of layout-test-results from ews123 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews123 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.6
Comment on attachment 336316 [details] Patch Attachment 336316 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/7067926 New failing tests: imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/interpolation-per-property.html imported/w3c/web-platform-tests/web-animations/animation-model/animation-types/accumulation-per-property.html fast/css/getComputedStyle/getComputedStyle-transform.html
Created attachment 336334 [details] Archive of layout-test-results from ews115 for mac-sierra The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews115 Port: mac-sierra Platform: Mac OS X 10.12.6
Comment on attachment 336316 [details] Patch Attachment 336316 [details] did not pass win-ews (win): Output: http://webkit-queues.webkit.org/results/7070589 New failing tests: fast/css/getComputedStyle/getComputedStyle-transform.html
Created attachment 336354 [details] Archive of layout-test-results from ews202 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews202 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Created attachment 336362 [details] Patch
Comment on attachment 336362 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=336362&action=review > Source/WebCore/ChangeLog:16 > + Strictly looking at whether the renderer has a transform is a bad idea when determining whether a > + transform is applied for an element. Looking at the RenderStyle is preferable because in the case > + of animations running on the compositor, such as a transform-only animation or transition, the > + renderer doesn't necessarily have a transform style on it, since we don't blend properties in > + software as the animation progresses. Instead, all of the blending is performed by the compositor, > + and only the computed style object has the software-blended transform style on it. > + > + * css/CSSComputedStyleDeclaration.cpp: > + (WebCore::computedTransform): None of this explains why there is also a change that RenderInline objects can't have a computed transform.
(In reply to Dean Jackson from comment #13) > Comment on attachment 336362 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=336362&action=review > > > Source/WebCore/ChangeLog:16 > > + Strictly looking at whether the renderer has a transform is a bad idea when determining whether a > > + transform is applied for an element. Looking at the RenderStyle is preferable because in the case > > + of animations running on the compositor, such as a transform-only animation or transition, the > > + renderer doesn't necessarily have a transform style on it, since we don't blend properties in > > + software as the animation progresses. Instead, all of the blending is performed by the compositor, > > + and only the computed style object has the software-blended transform style on it. > > + > > + * css/CSSComputedStyleDeclaration.cpp: > > + (WebCore::computedTransform): > > None of this explains why there is also a change that RenderInline objects > can't have a computed transform. Will explain in commit. Inlines don't respect transforms.
Committed r229889: <https://trac.webkit.org/changeset/229889>
<rdar://problem/38789926>