(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.
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.
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
(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.
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.
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
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev