Removed sending of the content IPC messages from chrome and replaced them with corresponding APIs

Removed sending of the content IPC messages from chrome and replaced them with corresponding APIs
on the RenderWidgetHost/RenderViewHost objects. Moved the Edit operation APIs out of RenderViewHost to
RenderWidgetHost.

1.  ViewMsg_UpdateWebPreferences
2.  ViewMsg_SetBackground
3.  ViewMsg_AccessibilityDoDefaultAction
4.  ViewMsg_SetAccessibilityFocus
5. ViewMsg_ScrollFocusedEditableNodeIntoRect
6. ViewMsg_SelectRange
7. ViewMsg_Cut
8. ViewMsg_Copy
9. ViewMsg_Paste
10. ViewMsg_Delete
11. ViewMsg_SelectAll
12. ViewMsg_ClearFocusedNode
13. ViewMsg_SetAltErrorPageURL
14. ViewMsg_ExitFullscreen

Continuing fixes to ensure that IPC messages don't span across content and
chrome.

BUG=87335
.
TEST=no change in functionality.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=102142

[jam, 2011-09-20 23:06:40]

Many of these functions that you added to RenderWidgetHost don't seem like they
belong there. see "What's the difference between RenderWidget and RenderView?"
in
http://www.chromium.org/developers/design-documents/displaying-a-web-page-in-...
. For example, I wouldn't expect things like fullscreen/alt error
page/PluginImeComposition and a bunch of others to be in RenderWidget, since
those only apply for frames and not a widget, which is used to render a select
box. 

I think a good signal is to see who calls these methods. if they have access to
RVH, it should be there. if any of the callers only have RWH, it belongs on RW

[ananta, 2011-09-20 23:41:32]

On 2011/09/20 23:06:40, John Abd-El-Malek wrote:
> Many of these functions that you added to RenderWidgetHost don't seem like
they
> belong there. see "What's the difference between RenderWidget and RenderView?"
> in
>
http://www.chromium.org/developers/design-documents/displaying-a-web-page-in-...
> . For example, I wouldn't expect things like fullscreen/alt error
> page/PluginImeComposition and a bunch of others to be in RenderWidget, since
> those only apply for frames and not a widget, which is used to render a select
> box. 
> 
> I think a good signal is to see who calls these methods. if they have access
to
> RVH, it should be there. if any of the callers only have RWH, it belongs on RW

Done. 

I moved the following functions to RVH
1. SetAltErrorPageURL
2. ExitFullscreen()
3. UpdateWebkitPreferences
4. ClearFocusedNode

Left the PluginImeComposition function in RWH as the Mac class
RenderWidgetHostViewMac which uses it gets instantiated with the RWH pointer. I
moved the Cut/Edit and other operations out of RVH as there is code in
render_widget_host_view_views.cc which uses these functions on a RWH pointer.

[jam, 2011-09-21 00:10:53]

http://codereview.chromium.org/7972006/diff/14005/content/browser/renderer_ho...
File content/browser/renderer_host/render_widget_host.h (right):

http://codereview.chromium.org/7972006/diff/14005/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host.h:443: void SetZoomLevel(double
level);
looks like this can be on RVH?

http://codereview.chromium.org/7972006/diff/14005/content/browser/renderer_ho...
content/browser/renderer_host/render_widget_host.h:447: void
NotifyPluginImeCompletion(int plugin_id, const string16& status);
sorry, I just realized that these methods were added because of
render_widget_host_view_mac.mm. Avi is working on moving it to content, so we
wouldn't need these functions. Elliot is also working on moving the GTK impl to
content. wdyt about leaving their current usage in chrome since that code is
moving?

[jam, 2011-09-21 00:17:32]

CCing Avi and Elliot

[ananta, 2011-09-21 00:29:09]

On 2011/09/21 00:17:32, John Abd-El-Malek wrote:
> CCing Avi and Elliot

I moved a bunch of RWH functions added previously to RVH based on the the usage
along with the SetZoomLevel function you mentioned.

Regarding the changes to render_widget_host_view_mac.mm and the gtk equivalent,
I feel it would be good to leave these changes in. We would want their
implementations in content to send out these IPCs via these functions to make
the code easier to maintain. Upto you.

[Avi (use Gerrit), 2011-09-21 00:34:23]

Yes, please change RWHVM to follow the same scheme as the gtk/win versions. I'm
moving it to content soon.

[jam, 2011-09-21 00:44:59]

On Tue, Sep 20, 2011 at 5:29 PM, <ananta@chromium.org> wrote:

> On 2011/09/21 00:17:32, John Abd-El-Malek wrote:
>
>> CCing Avi and Elliot
>>
>
> I moved a bunch of RWH functions added previously to RVH based on the the
> usage
> along with the SetZoomLevel function you mentioned.
>
> Regarding the changes to render_widget_host_view_mac.mm and the gtk
> equivalent,
> I feel it would be good to leave these changes in. We would want their
> implementations in content to send out these IPCs via these functions to
> make
> the code easier to maintain.


Why do you say that having having code in content call other code in content
to send IPCs is more maintainable?

A while ago, we used to have a lot of functions on RVH/TC that just sent an
IPC and were called by one place. I removed them because it felt
unnecessary, i.e. sending an IPC is really equivalent to a cross process
function call. Surrounding that with another function call seems redundant.


> Upto you.
>
>
>
>
>
>
>
http://codereview.chromium.**org/7972006/<http://codereview.chromium.org/7972...
>

[ananta, 2011-09-21 01:01:48]

As per discussion reverted the mac and gtk changes. The RVH mac implementation
is on its way to content soon anyway.

On 2011/09/21 00:44:59, John Abd-El-Malek wrote:
> On Tue, Sep 20, 2011 at 5:29 PM, <mailto:ananta@chromium.org> wrote:
> 
> > On 2011/09/21 00:17:32, John Abd-El-Malek wrote:
> >
> >> CCing Avi and Elliot
> >>
> >
> > I moved a bunch of RWH functions added previously to RVH based on the the
> > usage
> > along with the SetZoomLevel function you mentioned.
> >
> > Regarding the changes to render_widget_host_view_mac.mm and the gtk
> > equivalent,
> > I feel it would be good to leave these changes in. We would want their
> > implementations in content to send out these IPCs via these functions to
> > make
> > the code easier to maintain.
> 
> 
> Why do you say that having having code in content call other code in content
> to send IPCs is more maintainable?
> 
> A while ago, we used to have a lot of functions on RVH/TC that just sent an
> IPC and were called by one place. I removed them because it felt
> unnecessary, i.e. sending an IPC is really equivalent to a cross process
> function call. Surrounding that with another function call seems redundant.
> 
> 
> > Upto you.
> >
> >
> >
> >
> >
> >
> >
>
http://codereview.chromium.**org/7972006/%3Chttp://codereview.chromium.org/79...>
> >

[ananta, 2011-09-21 01:01:48]

As per discussion reverted the mac and gtk changes. The RVH mac implementation
is on its way to content soon anyway.

On 2011/09/21 00:44:59, John Abd-El-Malek wrote:
> On Tue, Sep 20, 2011 at 5:29 PM, <mailto:ananta@chromium.org> wrote:
> 
> > On 2011/09/21 00:17:32, John Abd-El-Malek wrote:
> >
> >> CCing Avi and Elliot
> >>
> >
> > I moved a bunch of RWH functions added previously to RVH based on the the
> > usage
> > along with the SetZoomLevel function you mentioned.
> >
> > Regarding the changes to render_widget_host_view_mac.mm and the gtk
> > equivalent,
> > I feel it would be good to leave these changes in. We would want their
> > implementations in content to send out these IPCs via these functions to
> > make
> > the code easier to maintain.
> 
> 
> Why do you say that having having code in content call other code in content
> to send IPCs is more maintainable?
> 
> A while ago, we used to have a lot of functions on RVH/TC that just sent an
> IPC and were called by one place. I removed them because it felt
> unnecessary, i.e. sending an IPC is really equivalent to a cross process
> function call. Surrounding that with another function call seems redundant.
> 
> 
> > Upto you.
> >
> >
> >
> >
> >
> >
> >
>
http://codereview.chromium.**org/7972006/%3Chttp://codereview.chromium.org/79...>
> >

[ananta, 2011-09-21 01:01:49]

As per discussion reverted the mac and gtk changes. The RVH mac implementation
is on its way to content soon anyway.

On 2011/09/21 00:44:59, John Abd-El-Malek wrote:
> On Tue, Sep 20, 2011 at 5:29 PM, <mailto:ananta@chromium.org> wrote:
> 
> > On 2011/09/21 00:17:32, John Abd-El-Malek wrote:
> >
> >> CCing Avi and Elliot
> >>
> >
> > I moved a bunch of RWH functions added previously to RVH based on the the
> > usage
> > along with the SetZoomLevel function you mentioned.
> >
> > Regarding the changes to render_widget_host_view_mac.mm and the gtk
> > equivalent,
> > I feel it would be good to leave these changes in. We would want their
> > implementations in content to send out these IPCs via these functions to
> > make
> > the code easier to maintain.
> 
> 
> Why do you say that having having code in content call other code in content
> to send IPCs is more maintainable?
> 
> A while ago, we used to have a lot of functions on RVH/TC that just sent an
> IPC and were called by one place. I removed them because it felt
> unnecessary, i.e. sending an IPC is really equivalent to a cross process
> function call. Surrounding that with another function call seems redundant.
> 
> 
> > Upto you.
> >
> >
> >
> >
> >
> >
> >
>
http://codereview.chromium.**org/7972006/%3Chttp://codereview.chromium.org/79...>
> >

[jam, 2011-09-21 06:58:35]

lgtm