New issue
Advanced search Search tips

Issue 718213 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Swapped-out RenderViewHosts don't track changes in visibility

Project Member Reported by lfg@chromium.org, May 3 2017

Issue description

This breaks the process priority in RenderProcessHostImpl, as it relies on widget visibility when deciding whether to background processes.

I believe there are two ways this can end up wrong:

- The initial visibility of swapped-out RenderViewHosts is set in RenderFrameHostManager::CreateRenderFrameProxy based on the WebContents' visibility.

- The RenderWidgetHost can be reused in a navigation where the main frame becomes a proxy. This can happen when there's an opener that keeps the RenderViewHost alive.

 
Project Member

Comment 1 by bugdroid1@chromium.org, May 8 2017

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

commit b592bfa82d1cad4997766f751002f44ef37bd8a5
Author: lfg <lfg@chromium.org>
Date: Mon May 08 20:47:00 2017

Use the WebContents visibility as the initial visibility when
creating a swapped-out RenderView.

This CL changes the RenderView creation to use the WebContents
visibility when creating a swapped-out RenderView. This is
important because the browser doesn't track changes to the
visibility state of swapped-out RenderViewHosts, so the renderer
can end up having the wrong visibility when recovering from a
crash.

BUG= 717597 , 718213 

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2863003002
Cr-Commit-Position: refs/heads/master@{#470116}

[modify] https://crrev.com/b592bfa82d1cad4997766f751002f44ef37bd8a5/content/browser/frame_host/render_frame_host_manager.cc
[modify] https://crrev.com/b592bfa82d1cad4997766f751002f44ef37bd8a5/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/b592bfa82d1cad4997766f751002f44ef37bd8a5/content/browser/site_per_process_browsertest.cc

Project Member

Comment 2 by sheriffbot@chromium.org, May 9 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 3 by lfg@chromium.org, May 9 2018

Labels: -Hotlist-Recharge-Cold
Owner: boliu@chromium.org
I think this is being worked on by boliu@ on  issue 813232 . Bo, can we mark this as a duplicate?

Comment 4 by boliu@chromium.org, May 9 2018

not really

but I thought swapped out rvh is always invisible? Are there corner cases where that doesn't hold?

Comment 5 by lfg@chromium.org, May 9 2018

Cc: alex...@chromium.org
Re#4: Yes, when a RVH starts as visible, then swaps out, its (RWH) visibility won't be updated. For example, navigate to a.com, then window.open a new tab to a a.com. Finally, go back and navigate the original tab to b.com. This will swap-out the original a.com's RVH, but I think its visibility won't change to invisible.

+alexmos who looked at similar issues recently.

Comment 6 by boliu@chromium.org, May 9 2018

Oh, maybe this is already covered, modulo difference between swapped out and inactive:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_impl.cc?rcl=e746658481a024a427a92d79e4fb09385d6a6971&l=1674

Comment 7 by lfg@chromium.org, May 9 2018

Status: Fixed (was: Untriaged)
Yes, I think this is enough to mark this bug as fixed, since even if we don't track visibility changes in the RenderWidgetHost associated with the swapped-out 
 RVH, we always mark the RVH as inactive. Active is also the right thing to check here.

Sign in to add a comment