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

Issue 809171 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug

Blocking:
issue 787097



Sign in to add a comment

Running with VizDisplayCompositor and site-per-process makes browser unresponsive

Project Member Reported by kylec...@chromium.org, Feb 5 2018

Issue description

If running with both VizDisplayCompositor and site-per-process enabled websites with many OOPIFs make the browser unresponsive.

$ ./chrome --enable-features=VizDisplayCompositor,site-per-process www.slashdot.org

Try scrolling the page and it quickly stops updating. The entire browser UI stops updating actually, as the tab strip stops mid animation, so it looks like ui::Compositor CompositorFrames aren't activating?

If you click on the new tab button then browser UI will update and show the new tab page. If you open two new websites without OOPIFs then you can switch between the non-OOPIF tabs as expected. When you try to switch back to slashdot the browser UI will become unresponsive again, until you click on one of the non-OOPIF tabs. 
 
Blocking: 787097
Owner: fsam...@chromium.org
Status: Assigned (was: Available)
Cc: kylec...@chromium.org
Owner: samans@chromium.org
Status: Started (was: Assigned)
This is very strange. If the browser's CompositorFrames weren't activating, then the browser would freeze forever, but as you said once you switch away from the tab everything is fine. I'll start investigating.
Owner: kylec...@chromium.org
Kyle is already working on a CL so I'm assigning this bug to him.
Project Member

Comment 5 by bugdroid1@chromium.org, Feb 14 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/20395909445c5d6439dde2324680fd96e33f0876

commit 20395909445c5d6439dde2324680fd96e33f0876
Author: kylechar <kylechar@chromium.org>
Date: Wed Feb 14 20:09:48 2018

viz: Store interface requests in RenderWidgetHostImpl.

When running with VizDisplayCompositor and site-per-process features
enabled websites with lots of OOPIFs made the browser become
unresponsive. RenderWidgetHostImpl was dropping mojom::CompositorFrameSink
requests if it didn't have a view. The renderer would quickly constantly
retry these requests and lock up the browser UI.

Store the interfaces in RenderWidgetHostImpl for when a view is added
later. This stops the renderer from retrying constantly.
RenderWidgetHostViewAura also stores the interfaces if it hasn't created
a DelegatedFrameHost yet.

Bug:  809171 
Change-Id: I691cb68bddbf1cd560bd02420034744d71bd7e01
Reviewed-on: https://chromium-review.googlesource.com/905045
Commit-Queue: kylechar <kylechar@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536792}
[modify] https://crrev.com/20395909445c5d6439dde2324680fd96e33f0876/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/20395909445c5d6439dde2324680fd96e33f0876/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/20395909445c5d6439dde2324680fd96e33f0876/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/20395909445c5d6439dde2324680fd96e33f0876/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/20395909445c5d6439dde2324680fd96e33f0876/content/browser/renderer_host/render_widget_host_view_base.cc
[modify] https://crrev.com/20395909445c5d6439dde2324680fd96e33f0876/content/browser/renderer_host/render_widget_host_view_base.h

Status: Fixed (was: Started)

Sign in to add a comment