Allow binding a getter+setter for window object property.

The WebFrame class of Chromium API in Blink has bindToWindowObject() method which allows binding the specified NPObject* as a property of global DOM window object.

This has two limitations:
1) Only objects can be bound (no way to bind primitive values)
2) No possibility to further track value of this property / setters cannot be set.

This patch adds another alternative version of this functions which :
1) operates on NPVariant instead of NPObject*, thus allowing a binding of any value
2) accepts a pair of accessors instead of value.

BUG=

[Krzysztof Olczyk, 2013-07-24 07:50:50]

Hi reviewers,

could you please review this bit of extension to WebFrame API?

[abarth-chromium, 2013-07-24 18:26:04]

I don't understand the motivation for this change.  Why would we want embedders
to be able to inject arbitrary NPAPI-based bindings?  That would encourage
embedders to implement web-facing APIs using NPObject, which leads to poor
implementation quality.

Can you explain a bit more about what you're trying to accomplish?

https://codereview.chromium.org/19861006/diff/3007/Source/bindings/v8/ScriptC...
File Source/bindings/v8/ScriptController.h (right):

https://codereview.chromium.org/19861006/diff/3007/Source/bindings/v8/ScriptC...
Source/bindings/v8/ScriptController.h:113: 
"const String &" -> "const String& "

[Krzysztof Olczyk, 2013-07-25 15:11:47]

Thank you for your feedback!

Could you please explain why NPObject implies poor implementation quality?
What is the preferred machinery for such APIs?

NPObjects seem to be behind quite a lot of DOM extension frameworks in Chromium.
Apart from their natural use in nsplugins where they come from, they are also
the underlying technology for CppBoundClass(1) and are used in pepperplugins(2).
They also have proxy-stub mechanisms for passing them around different
processes(3).

WebFrame class already has a bindToWindowObject() method which allows binding
an NPObject* to DOMWindow that is used e.g. in (1).
This patch just adds a variant of this function which serves the same purpose
in more complete manner (as described in patch description).

At Opera, we are not going to utilize it for web-facing APIs. We have several
legacy scenarios in closed web-technologies-based ecosystems of our customers
where we need to exposed extra APIs according to their design.
Additionally, we are using it in our internal testing scenarios.

1)
https://code.google.com/p/chromium/codesearch#search/&q=NPObject%5C*%20packag...
2)
https://code.google.com/p/chromium/codesearch#chromium/src/webkit/renderer/cp...
3) NPObjectStub, NPObjectProxy, etc.

On 2013/07/24 18:26:04, abarth wrote:
> I don't understand the motivation for this change.  Why would we want
embedders
> to be able to inject arbitrary NPAPI-based bindings?  That would encourage
> embedders to implement web-facing APIs using NPObject, which leads to poor
> implementation quality.
> 
> Can you explain a bit more about what you're trying to accomplish?
> 
>
https://codereview.chromium.org/19861006/diff/3007/Source/bindings/v8/ScriptC...
> File Source/bindings/v8/ScriptController.h (right):
> 
>
https://codereview.chromium.org/19861006/diff/3007/Source/bindings/v8/ScriptC...
> Source/bindings/v8/ScriptController.h:113: 
> "const String &" -> "const String& "

[abarth-chromium, 2013-07-25 17:17:57]

On 2013/07/25 15:11:47, Krzysztof Olczyk wrote:
> Could you please explain why NPObject implies poor implementation quality?

NPObject is slow and doesn't support modern JavaScript.  It's frozen in the
distant past.  If we ever get to the point of dropping support for NPAPI, we'll
likely remove it and replace it with something more modern for PPAPI.

> What is the preferred machinery for such APIs?

The best way to define JavaScript APIs is WebIDL.  That's what we use internally
in Blink, and we're experimenting with a mechanism for letting code outside of
Blink define interfaces in WebIDL and re-use Blink's code generator.  Once the
Python re-write of the code generator is completed, we're likely to invest more
in that direction.

Another approach (which is significantly less good but not as bad as NPObject)
is to use a v8::Extension.  That's the approach that Chromium's extension system
uses and lets you talk directly to V8.  The downside is that you need to
re-build a bunch of the machinery that Blink's bindings give you for free, which
makes it hard to create idiomatic web APIs (e.g., EventTarget).

If you have time and are willing to help out, I would aim for using external
WebIDL.  That's the best long-term approach.  If you're looking for something
now, I'd probably use a v8::Extension.

> NPObjects seem to be behind quite a lot of DOM extension frameworks in
Chromium.
> Apart from their natural use in nsplugins where they come from, they are also
> the underlying technology for CppBoundClass(1) and are used in
pepperplugins(2).
> They also have proxy-stub mechanisms for passing them around different
> processes(3).

CppBoundClass is only used in test code.  If we're able to drop support for
NPAPI, we'll likely move pepperplugins to another mechanism that understands
modern JavaScript and is better suited for PPAPI's use cases.

> WebFrame class already has a bindToWindowObject() method which allows binding
> an NPObject* to DOMWindow that is used e.g. in (1).
> This patch just adds a variant of this function which serves the same purpose
> in more complete manner (as described in patch description).

Yes.  The issue is that we don't want to elaborate our support for NPObject
because it's a trailing-edge technology that we would eventually like to remove.
 Instead, I'd rather invest in leading-edge technologies.

> At Opera, we are not going to utilize it for web-facing APIs. We have several
> legacy scenarios in closed web-technologies-based ecosystems of our customers
> where we need to exposed extra APIs according to their design.
> Additionally, we are using it in our internal testing scenarios.

Hopefully external WebIDL or v8::Extension will be work for these use cases as
well.

IF you want to experiment with external WebIDL today, take a look at the
extra_blink_module_idl_files and extra_blink_module_files variables in this GYPI
file:

https://chromium.googlesource.com/chromium/blink/+/master/Source/modules/modu...

That's just the seed of the external WebIDL system.  As the comment indicates, I
would be careful about building on that system right now because there's no API
boundary in place yet.  You'll get direct access to internal types, which are
subject to change.  To complete that project, we'll need to wire the external
WebIDL files up to API types that are more stable.  We would eventually like to
move the extension system and all the clients of CppBoundClass over to that
mechanism.

[Krzysztof Olczyk, 2013-07-29 15:54:58]

Thank your for your detailed explanation.

WebIDL mechanism and making it available externally sounds definitely exciting.
I would love to base all the extension mechanisms on it.

I also agree v8 extensions are good temporary solution
while external WebIDL is not mature.
Actually, we do use v8 extensions in several of our internal scenarios.

However, we need to port several components, in quite short time-frame,
which fit pretty well into the architecture of NPObject and related frameworks
already in Chromium and we cannot invest time at the moment to re-base them
to more modern technologies.

This includes the following:
- v8::extensions are run inside renderer process. The same would apply,
  I believe, to external WebIDLs. At the same time, NPObjects already
  have an infrastructure of "automatically" mirroring objects between
  renderer process and their true implementation inside separate process
  (plugin process). 
- Correct me if I'm wrong, but according to my knowledge,
  both WebIDL and v8::extensions require known interfaces. 
  Objects need to "introduce" themselves and provide the list of known
  methods and properties. It is not possible to mimic HasMethod/GetMethod
  behavior. I know, it may be argued that it is a bad practice to define
  extensions in this way, but as I mentioned this is for legacy components.

On 2013/07/25 17:17:57, abarth wrote:
> On 2013/07/25 15:11:47, Krzysztof Olczyk wrote:
> > Could you please explain why NPObject implies poor implementation quality?
> 
> NPObject is slow and doesn't support modern JavaScript.  It's frozen in the
> distant past.  If we ever get to the point of dropping support for NPAPI,
we'll
> likely remove it and replace it with something more modern for PPAPI.
> 
> > What is the preferred machinery for such APIs?
> 
> The best way to define JavaScript APIs is WebIDL.  That's what we use
internally
> in Blink, and we're experimenting with a mechanism for letting code outside of
> Blink define interfaces in WebIDL and re-use Blink's code generator.  Once the
> Python re-write of the code generator is completed, we're likely to invest
more
> in that direction.
> 
> Another approach (which is significantly less good but not as bad as NPObject)
> is to use a v8::Extension.  That's the approach that Chromium's extension
system
> uses and lets you talk directly to V8.  The downside is that you need to
> re-build a bunch of the machinery that Blink's bindings give you for free,
which
> makes it hard to create idiomatic web APIs (e.g., EventTarget).
> 
> If you have time and are willing to help out, I would aim for using external
> WebIDL.  That's the best long-term approach.  If you're looking for something
> now, I'd probably use a v8::Extension.
> 
> > NPObjects seem to be behind quite a lot of DOM extension frameworks in
> Chromium.
> > Apart from their natural use in nsplugins where they come from, they are
also
> > the underlying technology for CppBoundClass(1) and are used in
> pepperplugins(2).
> > They also have proxy-stub mechanisms for passing them around different
> > processes(3).
> 
> CppBoundClass is only used in test code.  If we're able to drop support for
> NPAPI, we'll likely move pepperplugins to another mechanism that understands
> modern JavaScript and is better suited for PPAPI's use cases.
> 
> > WebFrame class already has a bindToWindowObject() method which allows
binding
> > an NPObject* to DOMWindow that is used e.g. in (1).
> > This patch just adds a variant of this function which serves the same
purpose
> > in more complete manner (as described in patch description).
> 
> Yes.  The issue is that we don't want to elaborate our support for NPObject
> because it's a trailing-edge technology that we would eventually like to
remove.
>  Instead, I'd rather invest in leading-edge technologies.
> 
> > At Opera, we are not going to utilize it for web-facing APIs. We have
several
> > legacy scenarios in closed web-technologies-based ecosystems of our
customers
> > where we need to exposed extra APIs according to their design.
> > Additionally, we are using it in our internal testing scenarios.
> 
> Hopefully external WebIDL or v8::Extension will be work for these use cases as
> well.
> 
> IF you want to experiment with external WebIDL today, take a look at the
> extra_blink_module_idl_files and extra_blink_module_files variables in this
GYPI
> file:
> 
>
https://chromium.googlesource.com/chromium/blink/+/master/Source/modules/modu...
> 
> That's just the seed of the external WebIDL system.  As the comment indicates,
I
> would be careful about building on that system right now because there's no
API
> boundary in place yet.  You'll get direct access to internal types, which are
> subject to change.  To complete that project, we'll need to wire the external
> WebIDL files up to API types that are more stable.  We would eventually like
to
> move the extension system and all the clients of CppBoundClass over to that
> mechanism.

[abarth-chromium, 2013-07-29 18:14:31]

On 2013/07/29 15:54:58, Krzysztof Olczyk wrote:
> However, we need to port several components, in quite short time-frame,

I'm sorry, but schedule pressure isn't a good reason to add technical debt to
the project.  I've suggested two possible paths forward, but both require
investment on your end.  If you're not willing pay off your technical debt, then
I don't think Blink should absorb it either.  not lgtm.

[Krzysztof Olczyk, 2013-08-02 10:40:57]

On 2013/07/29 18:14:31, abarth wrote:
> On 2013/07/29 15:54:58, Krzysztof Olczyk wrote:
> > However, we need to port several components, in quite short time-frame,
> 
> I'm sorry, but schedule pressure isn't a good reason to add technical debt to
> the project.  I've suggested two possible paths forward, but both require
> investment on your end.  If you're not willing pay off your technical debt,
then
> I don't think Blink should absorb it either.  not lgtm.

OK, I can understand that you do not want to incorporate the improvements to the
technology
you are phasing out. 
Though, I have never stated that we are going to stick to this np-based
solution. 
I was just wondering if you would have been willing to take this patch in the
meantime,
while the related technology is still present and the replacements are still not
in place.

Anyway, thank you very much for the discussion and shedding light on 
what is the road map in Blink/Chromium regarding the DOM extension mechanisms. 
I hope to be able to move the discussed elements of ours to v8ext or WebIDL
and possibly helping out with the latter.