Issue metadata
Sign in to add a comment
|
RenderWidgetHostViewAura::SubmitCompositorFrame not call for --mus, resulting in test failures |
||||||||||||||||||||||
Issue descriptionThis function, among other things, updates the scrolloffset. As SubmitCompositorFrame() is not called with --mus it means the scrolloffset is not updated, leading to some test failures. Specifically I think the following browser_tests are effected:
,
Oct 11 2017
jonross@ and others are looking into updating these tests.
,
Oct 12 2017
Wait, is this failing in chrome's browser_tests for --mus ? That would pre-date the planned viz separation and be a live bug. sky@ do you have the lists of tests this causes failures in?
,
Oct 12 2017
Yes, this is failing in browser_tests with --mus. The specific set of tests is: -WebViewScrollBubbling/WebViewGuestScrollTouchTest.TestGuestGestureScrollsBubble/0 -WebViewScrollBubbling/WebViewGuestScrollTouchTest.TestGuestGestureScrollsBubble/1 -WebViewScrollBubbling/WebViewGuestScrollTouchTest.TestGuestGestureScrollsBubble/2 -WebViewScrollBubbling/WebViewGuestScrollTouchTest.TestGuestGestureScrollsBubble/3
,
Oct 12 2017
The browser process is no longer involved in the submission of compositor frames. So everything in content/browser/renderer_host/* SubmitCompositorFrame() path is skipped. As a result the browser process has no scroll info at all. I will sync with samans@ to figure out a way to provide the information.
,
Dec 6 2017
,
Mar 16 2018
All the Viz applications are tracked in different issues. The tests in #4 are covered by issue 796336 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by sky@chromium.org
, Oct 11 2017Labels: OS-Chrome
Status: Available (was: Untriaged)