BrowserPlugin/WebView - Move plugin lifetime to DOM - The Prequel

This cl is required by https://codereview.chromium.org/23618022/ to provide
changes to TestPlugin to supporting testing the new plugin lifetime
capabilities (originally this cl was part of that issue, but TestPlugin moved
between repos).

BUG=156219
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=248197

[wjmaclean, 2013-12-23 23:51:37]

Please take a look.

[eseidel, 2013-12-23 23:55:27]

Can you fill in the BUG= line for both this and the other CL?

[wjmaclean, 2013-12-24 00:00:12]

On 2013/12/23 23:55:27, eseidel wrote:
> Can you fill in the BUG= line for both this and the other CL?

Sure ... I had forgotten all about the original bug :-)

[eseidel, 2014-01-07 22:55:45]

I'm not a good reviewer for content code yet.

https://codereview.chromium.org/105633011/diff/1/content/shell/renderer/test_...
File content/shell/renderer/test_runner/TestPlugin.h (right):

https://codereview.chromium.org/105633011/diff/1/content/shell/renderer/test_...
content/shell/renderer/test_runner/TestPlugin.h:54: virtual struct _NPP*
pluginNPP() { return m_NPP.get(); }
I remember WebKit having typedefs to handle these _ types.  Not sure if Chromium
does or not?

[wjmaclean, 2014-01-08 14:12:53]

PTAL

https://codereview.chromium.org/105633011/diff/1/content/shell/renderer/test_...
File content/shell/renderer/test_runner/TestPlugin.h (right):

https://codereview.chromium.org/105633011/diff/1/content/shell/renderer/test_...
content/shell/renderer/test_runner/TestPlugin.h:54: virtual struct _NPP*
pluginNPP() { return m_NPP.get(); }
On 2014/01/07 22:55:46, eseidel wrote:
> I remember WebKit having typedefs to handle these _ types.  Not sure if
Chromium
> does or not?

It's in npapi.h, from third_party. I've revised to add it, though won't be
offended if people feel it's not worth having another include file for this.

[jochen (gone - plz use gerrit), 2014-01-08 15:06:01]

I wonder whether NetscapeTestPlugin was a better fit for this? It feels wrong to
add NPAPI stuff to TestPlugin

[wjmaclean, 2014-01-08 16:18:12]

On 2014/01/08 15:06:01, jochen wrote:
> I wonder whether NetscapeTestPlugin was a better fit for this? It feels wrong
to
> add NPAPI stuff to TestPlugin

I'm a bitof a wbie w.r.t plugins ... is there a way to add JS bindings to
TestPlugin that doesn't involve NPAPI?

[wjmaclean, 2014-01-08 16:18:57]

On 2014/01/08 16:18:12, wjmaclean wrote:
> On 2014/01/08 15:06:01, jochen wrote:
> > I wonder whether NetscapeTestPlugin was a better fit for this? It feels
wrong
> to
> > add NPAPI stuff to TestPlugin
> 
> I'm a bitof a wbie w.r.t plugins ... is there a way to add JS bindings to
> TestPlugin that doesn't involve NPAPI?

*newbie* - sorry, content_browsertests is running and grabbing keystrokes!

[jochen (gone - plz use gerrit), 2014-01-08 18:11:49]

hum, what about just dispatching an event to the testplugin?

it will print something if it exists and received the event

[wjmaclean, 2014-01-10 21:52:46]

So fsamuel@ points out that the all the NPObject stuff is also used in Pepper,
and so is not NPAPI specific (see below)

https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/p...

Is that what you were concerned about jochen@? If it's just the inclusion of
npapi.h, I can easily remove that.

[abarth-chromium, 2014-01-10 23:12:56]

On 2014/01/10 21:52:46, wjmaclean wrote:
> So fsamuel@ points out that the all the NPObject stuff is also used in Pepper,
> and so is not NPAPI specific (see below)

It's only used in a deprecated Pepper API.  We will eventually delete NPObject.

[Fady Samuel, 2014-01-10 23:15:43]

On 2014/01/10 23:12:56, abarth wrote:
> On 2014/01/10 21:52:46, wjmaclean wrote:
> > So fsamuel@ points out that the all the NPObject stuff is also used in
Pepper,
> > and so is not NPAPI specific (see below)
> 
> It's only used in a deprecated Pepper API.  We will eventually delete
NPObject.

Adam, is there a new way to bind methods and properties to <object>?

[abarth-chromium, 2014-01-10 23:20:41]

On 2014/01/10 23:15:43, Fady Samuel wrote:
> Adam, is there a new way to bind methods and properties to <object>?

I'm not sure what question you're asking.  In the future there won't be any
synchronous communication between JavaScript and any supported plugin API.

If your plugin doesn't use an API and can see private interfaces (i.e., it's the
browser plugin), then you can use the V8 API directly or build bindings using
Gin.

[eseidel, 2014-01-10 23:23:09]

He's looking for ways to expose properties to javascript
(document.getElementById('myplugin').myCustomProperty) from his plugin c++ code.
 This is for testing that his plugin is still alive even after he's caused its
RenderObject to be destroyed (display: none, etc.)

[jochen (gone - plz use gerrit), 2014-01-13 14:58:08]

since the sync scripting ability is about to be removed, this is not possible.

However, you can use existing methods to communicate with the plugin, e.g.
dispatchEvent(). The test plugin will print whatever event it receives which
should be visible in the layout test output, no?

[wjmaclean, 2014-01-31 03:46:07]

PTAL

jochen@ - I've revised this to use existing input events annotated with output
about which mime type was used to create the plugin ... this is sufficient for
my purposes and shouldn't alter any existing test output.

[jochen (gone - plz use gerrit), 2014-01-31 08:07:18]

lgtm

[wjmaclean, 2014-01-31 13:24:33]

The CQ bit was checked by wjmaclean@chromium.org

[commit-bot: I haz the power, 2014-01-31 13:24:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wjmaclean@chromium.org/105633011/340001

[commit-bot: I haz the power, 2014-01-31 16:14:53]

Change committed as 248197

[commit-bot: I haz the power, 2014-01-31 16:14:54]

CQ bit was unchecked on CL. Ignoring.

[commit-bot: I haz the power, 2014-01-31 16:14:56]

CQ bit was unchecked on CL. Ignoring.