New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 755318 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 796336
Owner:
Closed: Mar 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

RenderWidgetHostViewAura::SubmitCompositorFrame not call for --mus, resulting in test failures

Project Member Reported by sky@chromium.org, Aug 14 2017

Issue description

This 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:

 

Comment 1 by sky@chromium.org, Oct 11 2017

Cc: fsam...@chromium.org sadrul@chromium.org
Labels: OS-Chrome
Status: Available (was: Untriaged)
Fady/Sadrul, would either of you happen to have ideas as to what needs to happen here?

Comment 2 by fsamuel@google.com, Oct 11 2017

Cc: yiyix@chromium.org thanhph@chromium.org jonr...@chromium.org samans@chromium.org
jonross@ and others are looking into updating these tests.
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?

Comment 4 by sky@chromium.org, Oct 12 2017

Owner: jonr...@chromium.org
Status: Assigned (was: Available)
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

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.

Comment 6 by sky@chromium.org, Nov 6 2017

Blocking: -740655 731255
Blocking: -731255
I don't think this blocks mus anymore.
Mergedinto: 796336
Status: Duplicate (was: Assigned)
All the Viz applications are tracked in different issues.

The tests in #4 are covered by  issue 796336 

Sign in to add a comment