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

Issue 881849 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Task



Sign in to add a comment

[Task] current_frame_host() null for observer of RenderFrameHostImpl destructor.

Project Member Reported by arthurso...@chromium.org, Sep 7

Issue description

RenderFrameHostManager::current_frame_host() is expected not to be null.

This is a bit hard to guarantee, a lot of code can run inside its destructor:
#1 RenderFrameHostManager::~RenderFrameHostManager()
#2 RenderFrameHostImpl::~RenderFrameHostImpl()
#3 WebContentsImpl::RenderFrameDeleted()
#4 WebContentsObserver::RenderFrameDeleted()  (38 override excluding tests)

This is a bit unsafe. A lot of helper function assumes they can always dereference current_frame_host().

We can have rfh->frame_tree_node()->current_frame_host() == nullptr, even when rfh is the current render frame host.

============

Note: I tried several things:

1) in std::unique_ptr, exchanging ~RenderFrameHostImpl and releasing the ptr, so that current_frame_host() is still available while destructing it...
 .------------------------------------------------------
 | RenderFrameHostManager::~RenderFrameHostManager() {
 |   [...]
 |   delete render_frame_.get()
 |   render_frame_.release()
 | }
 `------------------------------------------------------
...but I think there is risk of the destructor being called inside itself.

2) Calling the observer earlier, before releasing current_frame_host().
https://chromium-review.googlesource.com/c/chromium/src/+/1206812
but it breaks a lot of tests.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Sep 17

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

commit 929d29fa8985277d1846d9a96807ec1e1b862edd
Author: Arthur Sonzogni <arthursonzogni@chromium.org>
Date: Mon Sep 17 14:19:44 2018

Refactor the set of frames in fullscreen.

Instead of tracking FrameTreeNode, tracks RenderFrameImpl.
There are several reasons:

1) WebContentsImpl::FullscreenStateChanged()
   takes RenderFrameHostImpl* in input and notifies its observers
   using a RenderFrameHostImpl*. There is no real need to convert
   from/to a FrameTreeNode.

2) This function traverses the tree of FrameTreeNode, but is called in
   RenderFrameHostImpl* destructor. It means the tree is in the middle
   of modifying itself. This is hard to reason about. For instance:
   rfh->frame_tree_node()->current_frame_host() may be null here, even
   when rfh is the current frame host.
   Traversing the tree using only rfh->GetParent() is easier.

Bug: 609963, 881849
Change-Id: I2e74324f83ddb2800b4dd177b561ff987c2c0a5f
Reviewed-on: https://chromium-review.googlesource.com/1207753
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Becca Hughes <beccahughes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591667}
[modify] https://crrev.com/929d29fa8985277d1846d9a96807ec1e1b862edd/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/929d29fa8985277d1846d9a96807ec1e1b862edd/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/929d29fa8985277d1846d9a96807ec1e1b862edd/content/browser/web_contents/web_contents_impl_browsertest.cc

Sign in to add a comment