WIP: Implement binding layer for Blink-in-JavaScript

WIP: Implement binding layer for Blink-in-JavaScript

This CL moves window.atob and window.btoa to JavaScript.

This is not yet for review.

[haraken, 2014-01-14 14:16:43]

This is not yet for review. I'll write a design document in days.

[arv (Not doing code reviews), 2014-01-14 14:50:17]

Very interesting. Really looking forward to hear more what you have in mind.

My main concern is that we are still going through the slow binding layer. I was
hoping that with DOM in JS there would be no binding layer.

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/Blink...
File Source/bindings/v8/BlinkInJavaScriptController.js (right):

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/Blink...
Source/bindings/v8/BlinkInJavaScriptController.js:43: (function () {
Why the IIFE? I assume you want the completion value? It can be done as:

({getClass: getClass});

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/V8Bli...
File Source/bindings/v8/V8BlinkInJavaScript.cpp (right):

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/V8Bli...
Source/bindings/v8/V8BlinkInJavaScript.cpp:64: // We don't need to convert
primitive values.
We should expose an IsValue or you should be able to use !IsObject.

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/V8Bli...
Source/bindings/v8/V8BlinkInJavaScript.cpp:144: result =
V8ScriptRunner::callFunction(v8::Handle<v8::Function>::Cast(function), document,
receiver, argc, argv, isolate);
Are we going trough C++ binding layer when we call these? That will defeat a lot
of the perf gain possibilities.

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
File Source/core/frame/WindowBase64.js (right):

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
Source/core/frame/WindowBase64.js:35: var windowBase64 =
installClass("WindowBase64");
installClass('WindowBase64', {
  btoaMethod: function (str) {
  },
  atobMethod: ...
}

but why are they named *Method?

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
Source/core/frame/WindowBase64.js:35: var windowBase64 =
installClass("WindowBase64");
We should put all of these in IIFEs to prevent naming conflicts between files
and to reduce leakage of global symbols.

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
Source/core/frame/WindowBase64.js:37: windowBase64.btoaMethod = function (str) {
We should make sure that all of these files are using strict mode so that people
cannot walk the call chain and get access to the internal functions.

[haraken, 2014-01-15 05:46:44]

> My main concern is that we are still going through the slow binding layer. I
was
hoping that with DOM in JS there would be no binding layer.

Blink-in-JS is not for performance but for programmability (in that sense it's
different from DOM-in-JS). Blink-in-JS is intending to allow developers to
implement DOM features in JavaScript where performance doesn't matter.
Blink-in-JS can be used for DOM features that are going to be deprecated and
should be removed from C++, and polyfills for DOM features that are going to be
implemented in C++ in the future etc. Our first target is execCommand in
editing.

I'll send a design document in days :)

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/Blink...
File Source/bindings/v8/BlinkInJavaScriptController.js (right):

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/Blink...
Source/bindings/v8/BlinkInJavaScriptController.js:43: (function () {
On 2014/01/14 14:50:18, arv wrote:
> Why the IIFE? I assume you want the completion value? It can be done as:
> 
> ({getClass: getClass});

Done.

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/V8Bli...
File Source/bindings/v8/V8BlinkInJavaScript.cpp (right):

https://codereview.chromium.org/138223002/diff/30001/Source/bindings/v8/V8Bli...
Source/bindings/v8/V8BlinkInJavaScript.cpp:64: // We don't need to convert
primitive values.
On 2014/01/14 14:50:18, arv wrote:
> We should expose an IsValue or you should be able to use !IsObject.

Done.

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
File Source/core/frame/WindowBase64.js (right):

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
Source/core/frame/WindowBase64.js:35: var windowBase64 =
installClass("WindowBase64");
On 2014/01/14 14:50:18, arv wrote:
> installClass('WindowBase64', {
>   btoaMethod: function (str) {
>   },
>   atobMethod: ...
> }
> 
> but why are they named *Method?

Done.

I was using *Method, since I'm planning to introduce *Getter and *Setter in the
future. However, "Method" is unnecessary, so dropped.

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
Source/core/frame/WindowBase64.js:35: var windowBase64 =
installClass("WindowBase64");
On 2014/01/14 14:50:18, arv wrote:
> We should put all of these in IIFEs to prevent naming conflicts between files
> and to reduce leakage of global symbols.

Done.

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
Source/core/frame/WindowBase64.js:37: windowBase64.btoaMethod = function (str) {
On 2014/01/14 14:50:18, arv wrote:
> We should make sure that all of these files are using strict mode so that
people
> cannot walk the call chain and get access to the internal functions.

Done.

[abarth-chromium, 2014-01-15 07:03:58]

The hardest part seems to be marshalling arguments in and out of the isolated
world.  If your first target is execCommand, maybe that will help scope that
problem.

It would be better if we used Chromium's resource system instead of hard-coding
the JavaScript into the binary.  I'm trying to convince the inspector folks to
move to Chromium's resource system as well.

https://codereview.chromium.org/138223002/diff/130001/Source/core/frame/Windo...
File Source/core/frame/WindowBase64.idl (left):

https://codereview.chromium.org/138223002/diff/130001/Source/core/frame/Windo...
Source/core/frame/WindowBase64.idl:33: [RaisesException] DOMString
btoa(DOMString string);
You'll need to deal with exceptions too...

[haraken, 2014-01-15 07:12:36]

Thanks abarth!

> The hardest part seems to be marshalling arguments in and out of the isolated
> world.  If your first target is execCommand, maybe that will help scope that
> problem.

My current plan is:

- Pass primitive values as is between isolated worlds.
- Convert DOM wrappers between isolated worlds. (Specifically, we can call
toV8(toNative(wrapper)) in the target isolated world.)
- Don't support JS objects, functions, arrays etc.

I'm guessing that primitive values and DOM wrappers would be enough for most of
DOM attributes/methods.

https://codereview.chromium.org/138223002/diff/130001/Source/core/frame/Windo...
File Source/core/frame/WindowBase64.idl (left):

https://codereview.chromium.org/138223002/diff/130001/Source/core/frame/Windo...
Source/core/frame/WindowBase64.idl:33: [RaisesException] DOMString
btoa(DOMString string);
On 2014/01/15 07:03:59, abarth wrote:
> You'll need to deal with exceptions too...

Good point. We need to insert v8::TryCatch and convert the exception object
thrown in Blink-in-JS's isolated world to an exception object of the outer
world.

[haraken, 2014-01-15 12:04:35]

https://codereview.chromium.org/138223002/diff/130001/Source/core/frame/Windo...
File Source/core/frame/WindowBase64.idl (left):

https://codereview.chromium.org/138223002/diff/130001/Source/core/frame/Windo...
Source/core/frame/WindowBase64.idl:33: [RaisesException] DOMString
btoa(DOMString string);
On 2014/01/15 07:12:36, haraken wrote:
> On 2014/01/15 07:03:59, abarth wrote:
> > You'll need to deal with exceptions too...
> 
> Good point. We need to insert v8::TryCatch and convert the exception object
> thrown in Blink-in-JS's isolated world to an exception object of the outer
> world.

Done. I took care of Exceptions thrown in Blink-in-JS's world. However, as
commented in V8BlinkInJavaScript.cpp, in order to implement the Exception
conversion correctly, we'll need V8 APIs that tell us Exception types. (It's
easy to implement the APIs.)

[arv (Not doing code reviews), 2014-01-15 16:04:34]

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
File Source/core/frame/WindowBase64.js (right):

https://codereview.chromium.org/138223002/diff/30001/Source/core/frame/Window...
Source/core/frame/WindowBase64.js:35: var windowBase64 =
installClass("WindowBase64");
On 2014/01/15 05:46:45, haraken wrote:
> On 2014/01/14 14:50:18, arv wrote:
> > installClass('WindowBase64', {
> >   btoaMethod: function (str) {
> >   },
> >   atobMethod: ...
> > }
> > 
> > but why are they named *Method?
> 
> Done.
> 
> I was using *Method, since I'm planning to introduce *Getter and *Setter in
the
> future. However, "Method" is unnecessary, so dropped.

getters and setters are probably best done using getters and setters?