Question about move from RenderView to RenderFrame

269 views
Skip to first unread message

Au, Leon

unread,
Feb 25, 2014, 11:31:11 PM2/25/14
to chromi...@chromium.org

(Sorry if this is going to the wrong email list, I tried to post on the WebUI but was told that I needed to send posts through email)


Hi,


My project builds on top of Chromium and recently ran into an interesting case while rebasing due to some changes for the move from RenderView to RenderFrame.  We have an issue that is similar to the case for CEF described in https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/PSA$20RenderFrame/chromium-dev/9qTMXFyPN_g/njovVqIKvw0J where we have an object that uses a process id + view route id pair to store information to be used by network related callbacks such as NetworkDelegate::OnBeforeURLRequest.


Chormium version: 34.0.1840.0

Browser tested: On Android, tested against Android WebView and Content Shell


As part of the changes to move functionality from RenderView to RenderFrame, https://code.google.com/p/chromium/issues/detail?id=304341, content::WebContentsImpl now invokes WebContentsObserver with a call to RenderFrameCreated at the end of WebContentsImpl::RenderViewCreated.


https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/web_contents/web_contents_impl.cc&q=web_contents_impl&sq=package:chromium&l=2765


I found that the instance of RenderFrameHost that is being passed into the RenderFrameCreate call actually references the RenderFrameHost object from the previous request.  For example, if I were to request the value renderFrameHost->GetProcess()->GetID(), that gives me the ID for the previous render process even if a new render process should be used.  In contrast, the notification to the observer for RenderViewCreated has a handle to the new render process.


From a bit of debugging, I can see that the reference inside RenderFrameHost isn’t updated until RenderFrameHostManager::CommitPending is invoked.  However, I have an observer that is very similar to android_webview::AwContentsIoThreadClient that does work before WebContentsImpl::NotifySwapped is called.


https://code.google.com/p/chromium/codesearch#chromium/src/android_webview/native/aw_contents_io_thread_client_impl.cc&q=aw_contents_io_&sq=package:chromium&l=132


Since I’m not running in single process mode, having the wrong process id causes problems for me.  I checked Content Shell and it shows the same behavior where the main frame object passed into RenderFrameCreated references the previous render process id.


Is it expected behavior for the notifications inside WebContentsImpl::RenderViewCreated to reference different processes in their respective calls in this case since a swap hasn't actually happened yet?  If so, would you have any advice for how to do this?  I considered something like the changes for OnSubFrameCreated call but that doesn't feel right. https://codereview.chromium.org/135443002


Thanks in advance,


Leon

Nasko Oskov

unread,
Feb 26, 2014, 6:19:23 PM2/26/14
to leo...@amazon.com, chromi...@chromium.org
On Tue, Feb 25, 2014 at 8:31 PM, Au, Leon <leo...@amazon.com> wrote:

(Sorry if this is going to the wrong email list, I tried to post on the WebUI but was told that I needed to send posts through email)


Hi,


My project builds on top of Chromium and recently ran into an interesting case while rebasing due to some changes for the move from RenderView to RenderFrame.  We have an issue that is similar to the case for CEF described in https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/PSA$20RenderFrame/chromium-dev/9qTMXFyPN_g/njovVqIKvw0J where we have an object that uses a process id + view route id pair to store information to be used by network related callbacks such as NetworkDelegate::OnBeforeURLRequest.


Chormium version: 34.0.1840.0

Browser tested: On Android, tested against Android WebView and Content Shell


As part of the changes to move functionality from RenderView to RenderFrame, https://code.google.com/p/chromium/issues/detail?id=304341, content::WebContentsImpl now invokes WebContentsObserver with a call to RenderFrameCreated at the end of WebContentsImpl::RenderViewCreated.


https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/web_contents/web_contents_impl.cc&q=web_contents_impl&sq=package:chromium&l=2765


I found that the instance of RenderFrameHost that is being passed into the RenderFrameCreate call actually references the RenderFrameHost object from the previous request.  For example, if I were to request the value renderFrameHost->GetProcess()->GetID(), that gives me the ID for the previous render process even if a new render process should be used.  In contrast, the notification to the observer for RenderViewCreated has a handle to the new render process.


Ah, cool find!
 

From a bit of debugging, I can see that the reference inside RenderFrameHost isn’t updated until RenderFrameHostManager::CommitPending is invoked.  However, I have an observer that is very similar to android_webview::AwContentsIoThreadClient that does work before WebContentsImpl::NotifySwapped is called.


https://code.google.com/p/chromium/codesearch#chromium/src/android_webview/native/aw_contents_io_thread_client_impl.cc&q=aw_contents_io_&sq=package:chromium&l=132


Since I’m not running in single process mode, having the wrong process id causes problems for me.  I checked Content Shell and it shows the same behavior where the main frame object passed into RenderFrameCreated references the previous render process id.


Is it expected behavior for the notifications inside WebContentsImpl::RenderViewCreated to reference different processes in their respective calls in this case since a swap hasn't actually happened yet?  If so, would you have any advice for how to do this?  I considered something like the changes for OnSubFrameCreated call but that doesn't feel right. https://codereview.chromium.org/135443002


No, it isn't supposed to give you different processes. We have a bug in WebContentsImpl::RenderViewCreated. The RenderFrameHost object we use to send notifications is the one for the current document, where we should be using the one associated with the RenderViewHost. Please file a bug and assign it to me.

Thanks in advance,


Leon

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

Au, Leon

unread,
Feb 26, 2014, 6:48:48 PM2/26/14
to Nasko Oskov, chromi...@chromium.org

This is my first time creating a bug, so I don’t think that I have the ability to assign it to an owner yet.

Thanks again,

Leon

Nasko Oskov

unread,
Feb 28, 2014, 1:24:36 PM2/28/14
to Au, Leon, chromi...@chromium.org
Hi Leon,
A fix for this went in last night. Can you grab the latest code and confirm everything works as you expect?
Thanks!
Nasko

Au, Leon

unread,
Feb 28, 2014, 3:11:28 PM2/28/14
to Nasko Oskov, chromi...@chromium.org
Nasko,

Thanks!  We are a little behind the tip, but from a cherry-pick it looks like it’s working as expected.

Nasko Oskov

unread,
Feb 28, 2014, 3:26:40 PM2/28/14
to Au, Leon, chromi...@chromium.org
Awesome! If you hit any other issues in the transition from RenderView to RenderFrame, feel free to ping me or site-isol...@chromium.org.
Reply all
Reply to author
Forward
0 new messages