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

Issue 663029 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

WebContents::Send should not use RenderViewHost

Project Member Reported by nasko@chromium.org, Nov 7 2016

Issue description

Currently the implementation of WebContents::Send() uses the RenderViewHost object's version of IPC::Send() to route IPC messages. With the progress of out-of-process iframes implementation, more and more functionality has been moving to be either frame scoped or widget scoped and no more RenderView(Host) scoped.

The usage of WebContents::Send is high (more than 400 calls) to be removed, however that would be the most correct course of action and each caller should use the specific RenderFrameHost to send its IPC messages. It is possible to just rewrite all of those calls into WebContents::GetMainFrame()::Send(), which will be closest to the equivalent of the old functionality and allow us to remove the Send method.
 

Comment 1 by nick@chromium.org, Nov 7 2016

With mojo, WebContents::Send() won't be implementable anyway (WebContents won't implement any mojo interfaces) so there's no reason to keep it around. It's better to tell folks to pick the frame they mean.

Is it safe to globally replace web_contents()->Send() with web_contents()->GetMainFrame()->Send(), even it's a ViewMsg? They all just forward to the channel, right?

Comment 2 by nasko@chromium.org, Nov 7 2016

Yes, I think it is all just forwarding to the channel and yes, it will be awkward to send the ViewMsgs through the frame, but I think it might be more correct than what we have now. 

I don't know whether we will have no Mojo interface that isn't page-global, but our goal has been to move ViewMsg types into widget or frame ones, so it seems like a good first step to try and do the replacing with using the main frame IPC channel.

Comment 3 by lfg@chromium.org, Nov 7 2016

The 400 calls listed in code search isn't right, it's listing all the overrides of IPC::Sender.

There's probably only a handful of places where that's actually called.

And I don't think globally replacing web_contents()->Send() with web_contents()->GetMainFrame()->Send will work, as RenderFrameImpl doesn't properly handle ViewMsgs (unless we add forwarding code to the renderer).

Comment 4 by lfg@chromium.org, Nov 7 2016

Actually, I take that back, GetMainFrame()->Send() should work, but I think it's ugly and we should properly fix the call site manually to convert them to FrameMsg or PageMsg.

I just wanted to note that going through GetMainFrame()->Send(...) [or even via GetRenderViewHost()->Send(...)] will not replicate the extra null checks done by both

1) WebContentsImpl::Send (checks first if GetRenderViewHost() is non-null)
and
2) WebContentsObserver::Send (checks first is web_contents() is non-null)
Owner: lukasza@chromium.org
Status: Started (was: Untriaged)
Maybe #c5 is okay and the callers should check for non-null-ness of WCO::web_contents() and/or WC::GetRenderViewHost() [not sure if the latter would be covered by issue 757730].

WIP CL @ https://chromium-review.googlesource.com/c/chromium/src/+/630416
Project Member

Comment 7 by bugdroid1@chromium.org, Aug 25 2017

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

commit 5ba7d8b1fabedb57824b0f5594004d2e83ea4643
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Fri Aug 25 16:37:49 2017

Remove uncalled/unreferenced FileSystemAccessedSync* methods

Before this CL
$ git grep '\bFileSystemAccessedSync'
showed that there are no "real" callers of FileSystemAccessedSync and
FileSystemAccessedSyncResponse methods.

There was a single caller of
WebViewPermissionHelperDelegate::FileSystemAccessedSync method in
WebViewPermissionHelper::FileSystemAccessedSync, but since nobody calls
the latter, this callsite didn't "really" count.

Similarily there was a single place taking an address of
ChromeWebViewPermissionHelperDelegate::FileSystemAccessedSyncResponse
done in ChromeWebViewPermissionHelperDelegate::FileSystemAccessedSync,
but this didn't really count, because there were no "real" callers
of the latter.

Bug:  663029 
Change-Id: I1f3770b79a70952ba45aeef6bfa2236c9c88836e
Reviewed-on: https://chromium-review.googlesource.com/630516
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497439}
[modify] https://crrev.com/5ba7d8b1fabedb57824b0f5594004d2e83ea4643/chrome/browser/guest_view/web_view/chrome_web_view_permission_helper_delegate.cc
[modify] https://crrev.com/5ba7d8b1fabedb57824b0f5594004d2e83ea4643/chrome/browser/guest_view/web_view/chrome_web_view_permission_helper_delegate.h
[modify] https://crrev.com/5ba7d8b1fabedb57824b0f5594004d2e83ea4643/chrome/browser/renderer_host/chrome_render_message_filter.cc
[modify] https://crrev.com/5ba7d8b1fabedb57824b0f5594004d2e83ea4643/chrome/browser/renderer_host/chrome_render_message_filter.h
[modify] https://crrev.com/5ba7d8b1fabedb57824b0f5594004d2e83ea4643/extensions/browser/guest_view/web_view/web_view_permission_helper.cc
[modify] https://crrev.com/5ba7d8b1fabedb57824b0f5594004d2e83ea4643/extensions/browser/guest_view/web_view/web_view_permission_helper.h
[modify] https://crrev.com/5ba7d8b1fabedb57824b0f5594004d2e83ea4643/extensions/browser/guest_view/web_view/web_view_permission_helper_delegate.h

Project Member

Comment 8 by bugdroid1@chromium.org, Sep 7 2017

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

commit f4357cacb5dc82d7016c2952d5075396b19eb4ef
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Thu Sep 07 01:43:32 2017

WebContents and WebContentsObserver should not provide IPC::Sender API.

With the introduction of OOPIFs, WebContents can span multiple processes
- there is no default process to send IPC messages to.  Removing the
WebContents::Send and WebContentsObserver::Send methods forces the
callers to explicitly specify the target of the message.  This helps
avoid situations where an IPC message is sent via RenderViewHost (i.e.
to the process hosting the main frame) when it should have been send to
a process hosting a specific frame (this CL fixes a few such cases).

Bug:  663029 
Change-Id: I16980f5ef05a8ac7da365edf7a92ce46677a8c0c
Reviewed-on: https://chromium-review.googlesource.com/630416
Reviewed-by: Gene Gutnik <gene@chromium.org>
Reviewed-by: Selim Gurun <sgurun@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Reviewed-by: Alex Clarke <alexclarke@chromium.org>
Reviewed-by: Nick Carter <nick@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500170}
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/android_webview/browser/aw_print_manager.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/android_webview/browser/aw_print_manager.h
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/android_webview/browser/renderer_host/aw_render_view_host_ext.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/chrome/browser/android/tab_android.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/chrome/browser/guest_view/web_view/chrome_web_view_permission_helper_delegate.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/chrome/browser/plugins/plugin_observer.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/chrome/browser/plugins/plugin_observer.h
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/chrome/browser/printing/print_view_manager.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/chrome/browser/printing/print_view_manager.h
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/components/guest_view/browser/guest_view_base.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/browser/browser_plugin/browser_plugin_guest.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/browser/media/media_web_contents_observer.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/browser/media/session/media_session_controller.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/browser/plugin_content_origin_whitelist.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/browser/web_contents/web_contents_impl.h
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/public/browser/web_contents.h
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/public/browser/web_contents_observer.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/public/browser/web_contents_observer.h
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/content/shell/browser/layout_test/blink_test_controller.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/extensions/browser/guest_view/extensions_guest_view_manager_delegate.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/headless/lib/browser/headless_print_manager.cc
[modify] https://crrev.com/f4357cacb5dc82d7016c2952d5075396b19eb4ef/headless/lib/browser/headless_print_manager.h

Status: Fixed (was: Started)
Fixed, right?

Sign in to add a comment