WebViewHelper claims that it isn't by watching the WebWidgetClient::ScheduleAnimation, but ChromeClientImpl actually just calls to the compositor not to the WebWidgetClient. WebWidgetClient's ScheduleAnimation is only used to reach out to the test harness for web tests.

(I'm changing us to use ScheduleAnimation more straightforwardly, which is how I found this out.)

from chrishtr:
So it's a perf bug that an additional frame is scheduled during resize. The main goal of the CL you linked to was to avoid having layout be dirty.
The performance bug can be fixed by suppressing scheduling animations during the resize method without too much effort...

This is the stack for reference
#2 0x557968639a36 blink::frame_test_helpers::TestWebViewClient::ScheduleAnimation()
#3 0x7fe535ae29a7 blink::ChromeClientImpl::ScheduleAnimation()
#4 0x7fe535b089f1 blink::PageAnimator::ScheduleVisualUpdate()
#5 0x7fe53548edda blink::LocalFrameView::ScheduleRelayout()
#6 0x7fe5358e59d4 blink::LayoutObject::ScheduleRelayout()
#7 0x7fe5358e553d blink::LayoutObject::MarkContainerChainForLayout()
#8 0x7fe5350d7b6a blink::LayoutObject::SetNeedsLayout()
#9 0x7fe53548a4b5 blink::LocalFrameView::SetNeedsLayout()
#10 0x7fe5353bec7f blink::WebViewImpl::UpdatePageDefinedViewportConstraints()
#11 0x7fe5353be252 blink::WebViewImpl::UpdateICBAndResizeViewport()
#12 0x7fe5353bf387 blink::WebViewImpl::ResizeViewWhileAnchored()
#13 0x7fe5353bf758 blink::WebViewImpl::ResizeWithBrowserControls()
#14 0x5579689fe5cc blink::frame_test_helpers::WebViewHelper::Resize()
#15 0x55796878be35 blink::WebFrameTest_setLoadWithOverviewModeToFalse_Test::TestBody()