Add infrastructure to instantiate a helper plugin.

Add infrastructure to instantiate a helper plugin.

This is the Chromium side of http://webk.it/87399.

BUG=130425
TEST=None yet. Confirmed plugin is instantiated when GetClient()->createHelperPlugin(frame_); is added to WebMediaPlayerImpl::play().


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=145924

[ddorwin, 2012-06-18 05:58:47]

This is a simple patch to use the WebKit code and override a new method.

[ddorwin, 2012-06-18 06:00:24]

jamesr, please review (I'll need your OWNERS approval).
abarth, FYI.

[ddorwin, 2012-06-22 18:31:59]

jamesr, please review. It's short.

[jamesr, 2012-06-22 18:46:41]

The naming here is so vague that I can't tell what it is trying to do. I suspect
you are being deliberately vague here, but it makes the code impossible to read
or understand.

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_vie...
File content/renderer/render_view_impl.h (right):

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_vie...
content/renderer/render_view_impl.h:438: WebKit::WebHelperPlugin*) OVERRIDE;
if this is implementing WebKit API, then no OVERRIDE. Having the OVERRIDE makes
it too hard to do rolls

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_wid...
File content/renderer/render_widget.cc (right):

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_wid...
content/renderer/render_widget.cc:154: case WebKit::WebPopupTypeHelperPlugin:
how is this case different from a full-page plugin? why does it need a separate
popup_type_ ?

[ddorwin, 2012-06-22 19:39:19]

> The naming here is so vague that I can't tell what it is trying to do. I
suspect
> you are being deliberately vague here, but it makes the code impossible to
read
> or understand.

This code along with the WebKit patches provides the ability for Chrome to
instantiate plugins to provide functionality for the renderer. While we have a
specific use case in mind (bug 130425), the functionality is generic. I chose
"helper plugin" in the WebKit code because the plugin helps or does work for
caller. I'm open to better names, but that's what it is currently called in
WebKit.


The only change in the new patch is the removal of OVERRIDE.   The rebase makes
a diff against the previous patch noisy.

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_vie...
File content/renderer/render_view_impl.h (right):

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_vie...
content/renderer/render_view_impl.h:438: WebKit::WebHelperPlugin*) OVERRIDE;
On 2012/06/22 18:46:42, jamesr wrote:
> if this is implementing WebKit API, then no OVERRIDE. Having the OVERRIDE
makes
> it too hard to do rolls

Done.

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_wid...
File content/renderer/render_widget.cc (right):

http://codereview.chromium.org/10442102/diff/2001/content/renderer/render_wid...
content/renderer/render_widget.cc:154: case WebKit::WebPopupTypeHelperPlugin:
This is an off-screen page that instantiates a specified plugin. The intent is
that Chrome can instantiate this plugin to provide capabilities (transparent to
the web application). Thus, the term "helper plugin". Thus, it's not a full-page
plugin or a traditional pop-up.

On 2012/06/22 18:46:42, jamesr wrote:
> how is this case different from a full-page plugin?
The plugin is not visible or part of the page. It is a separate widget.

> why does it need a separate popup_type_ ?
The implementation requires a separate WebWidget class (WebHelperPlugin).
WebWidgets can currently only be created by Chrome in this function using the
popup_type_ enum. As mentioned in http://webk.it/87399#c6, it might make senee
to refactor this code since popup_type_ is only used in this initialization
function.

[ddorwin, 2012-06-22 22:06:04]

I should also mention that the purpose of initializeHelperPluginWebFrame() is to
get a WebKit::WebFrameClient* from a WebKit::WebViewClient. The former is needed
so there is a valid implementation of createPlugin(), which is used during the
layout of the offscreen page. RenderViewImpl implements both interfaces but the
a pointer to former is not available to WebHelperPluginImpl.

Providing the interface via initializeFrame() is similar to how RenderViewImpl
calls WebKit::WebViewinitializeMainFrame(WebKit::WebFrameClient*) in its
constructor. The difference is that in this case, we need to ask RenderViewImpl
to do this.

[ddorwin, 2012-06-27 02:28:20]

jamesr - ping. Did the information I provided help?

[ddorwin, 2012-07-09 21:37:27]

piman, please review this small change. (jamesr is OOO.) See my earlier replies
for more context.
Thanks.

[piman, 2012-07-09 22:06:17]

lgtm

[commit-bot: I haz the power, 2012-07-10 16:49:27]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ddorwin@chromium.org/10442102/32001

[commit-bot: I haz the power, 2012-07-10 18:46:04]

Change committed as 145924