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

Issue 763549 link

Starred by 1 user
Status: Untriaged
Owner: ----
Cc:
█ nick@chromium.org
creis@chromium.org
dcheng@chromium.org
alex...@chromium.org
sa...@chromium.org
█ nasko@chromium.org
wfh@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

RenderFrame should never live longer than the corresponding RenderFrameHost

Project Member Reported by lukasza@chromium.org, Sep 8 2017 
RenderFrame should never live longer than the corresponding RenderFrameHost.  Otherwise renderer->browser communication is broken (i.e. IPC messages are lost) or we have races (like the FrameHost-deletion-race-while-OpenLocalStorage-is-in-flight race described in https://chromium-review.googlesource.com/c/chromium/src/+/654017/2/content/renderer/dom_storage/local_storage_cached_area.cc#82).

One known case where RenderFrame lives longer than RenderFrameHost is when swapping-out a parent frame - in this case we immediately delete all its children without waiting for an ack that their unload handlers have finished and that RenderFrame is getting deleted.  See the |frame_tree_node_->ResetForNewProcess()| being made by RenderFrameHostManager::CommitPending.

Comment 1 by creis@chromium.org, Sep 12 2017

Cc: creis@chromium.org
Components: UI>Browser>Navigation
Another case where it might happen is closing a tab with a slow or unresponsive renderer.  The RFH will go away after the 1 second timeout, but the RenderFrame may live longer in its current task (before hearing the FrameDelete message).  Not sure if there's a way to solve that.

For reference, the pending delete FTN bug is issue 609963, but I think that would only apply to subframes and not a closing tab.

Comment 2 by lukasza@chromium.org, Sep 12 2017

Cc: dcheng@chromium.org nick@chromium.org
If we want to guarantee that closing a tab cleans-up all browser-side state associated with the tab, then we are forced to delete corresponding RenderFrameHosts (maybe after a timeout to give the frames a chance to clean-up and/or save their state).

If such a guarantee is needed, then:

1) this bug might is 100% fixable - RenderFrame might live longer than the corresponding RenderFrameHost after closing a tab

and consequently

2) this bug doesn't help with the FrameHost-deletion-race-while-OpenLocalStorage-is-in-flight race :-(

Comment 3 by lukasza@chromium.org, Sep 20 2017

Cc: sa...@chromium.org
+sammc@

s/this bug might is 100% fixable/this bug might not be 100% fixable/

sammc@ points out in https://goo.gl/3r7SYa and https://goo.gl/Tqdg4z that the clean-up mentioned in #c2 only applies to objects known to and kept alive by  WebContents.  For example - closing a tab will not clean-up localStorage-related objects in the browser process.  I am not sure if tab-closing-cleans-up-*some*-browser-side-objects is as desirable as tab-closing-cleans-up-*all*-browser-side-objects.
►

Sign in to add a comment