Index: third_party/WebKit/Source/bindings/core/v8/V8BindingDesign.md |
diff --git a/third_party/WebKit/Source/bindings/core/v8/V8BindingDesign.md b/third_party/WebKit/Source/bindings/core/v8/V8BindingDesign.md |
new file mode 100644 |
index 0000000000000000000000000000000000000000..e02e97c4aca8514e8e819092258940db56f2fa28 |
--- /dev/null |
+++ b/third_party/WebKit/Source/bindings/core/v8/V8BindingDesign.md |
@@ -0,0 +1,259 @@ |
+# Design of V8 bindings |
+ |
+This document explains key concepts in the V8 binding architecture |
+except the lifetime management of DOM wrappers. |
+See [V8GCController.md](V8GCController.md) to learn the lifetime management. |
+ |
+[TOC] |
+ |
+## Isolate |
+ |
+An isolate is a concept of a thread in V8. |
jochen (gone - plz use gerrit)
2016/01/07 10:18:44
that's not really true, it's just the way Blink us
haraken
2016/01/08 05:22:34
Reworded.
|
+Isolates and threads are in 1:1 relationship. |
+One isolate is associated with the main thread. |
+One isolate is associated with one worker thread. |
+ |
+## Context |
+ |
+A context is a concept of a global variable scope in V8. |
+Roughly speaking, one window object corresponds to one context. |
+For example, `<iframe>` has a window object different from a window object |
+of its parent frame. So the context of the `<iframe>` is different from |
+the context of the parent frame. Since these contexts create their own |
+global variable scopes, global variables and prototype chains of the `<iframe>` |
+are isolated from the ones of the parent frame. |
+ |
+Here is an example: |
+ |
+```html |
+// main.html |
+<html><body> |
+<iframe src="iframe.html"></iframe> |
+<script> |
+var foo = 1234; |
+String.prototype.substr = |
+ function (position, length) { // Hijacks String.prototype.substr |
+ console.log(length); |
+ return "hijacked"; |
+ }; |
+</script> |
+</body></html> |
+ |
+// iframe.html |
+<script> |
+console.log(foo); // undefined |
+var bar = "aaaa".substr(0, 2); // Nothing is logged. |
+console.log(bar); // "aa" |
+</script> |
+``` |
+ |
+In summary, each frame has a window object. |
+Each window object has a context. |
+Each context has its own global variable scope and prototype chains. |
+ |
+## Entered context and current context |
+ |
+A relationship between isolates and contexts is interesting. |
+One isolate has to execute JavaScripts in multiple frames, |
+each of which has its own context. This means that the context associated |
+with the isolate changes over time. In other words, the relationship between |
+isolates and contexts is 1:N over the lifetime of the isolate. |
+ |
+Here we have a concept of an entered context and a current context. |
+To understand the difference, you need to understand two kinds of |
+runtime stacks. |
+ |
+The first stack is a stack of JavaScript functions. |
+This stack is managed by V8. When one function calls another function, |
+the callee function is pushed onto the stack. When that function returns, |
jochen (gone - plz use gerrit)
2016/01/07 10:18:45
that's not true in general (e.g. tail calls don't
haraken
2016/01/08 05:22:34
I don't want to run into that kind of details sinc
|
+the function is popped from the stack and the control returns to the caller |
+function that is now on the top of the stack. Each function has |
+an associated context. We call the context of the function |
+that is currently running (i.e., the context of the function that is on the top |
+of the stack) a current context. |
jochen (gone - plz use gerrit)
2016/01/07 10:18:44
unless the debugger is active, then the top contex
haraken
2016/01/08 05:22:34
Added the explanation for a debugger context.
|
+ |
+Here is an example: |
+ |
+```html |
+// main.html |
+<html><body> |
+<iframe src="iframe.html"></iframe> |
+<script> |
+var iframe = document.querySelector("iframe"); |
+iframe.onload = function () { |
+ iframe.contentWindow.func(); |
+} |
+</script> |
+</body></html> |
+ |
+// iframe.html |
+<script> |
+function func() { |
+ ...; |
+} |
+</script> |
+``` |
+ |
+In the above example, at the point when func() is running, |
+the current context is the context of the `<iframe>`. |
+ |
+There is a second stack that operates on a much coarser granularity. |
+This stack is managed by V8 binding (not by V8). |
+When V8 binding invokes JavaScript, V8 binding enters a context |
+and pushes the context onto the stack. |
+The JavaScript starts running on the context. When the JavaScript finishes |
+and the control returns back to V8 binding, V8 binding pops the context |
+from the stack. Given that the control between V8 binding and V8 can be nested |
+(i.e., V8 binding invokes JavaScript, which calls into V8 binding, |
+which invokes another JavaScript etc), these contexts form a stack. |
+The pushing and popping are done by calling v8::Context::Enter() and |
+v8::Context::Exit() (or v8::Context::Scope). We call the most recently entered |
+context an entered context. |
jochen (gone - plz use gerrit)
2016/01/07 10:18:45
any V8 C++ API that takes a context argument enter
haraken
2016/01/08 05:22:34
Added.
|
+ |
+In the above example, at the point when func() is running, |
+the entered context is the context of the main frame |
+(not the context of `<iframe>`). |
+ |
+The entered context is a concept to implement the |
+[entry settings object](https://html.spec.whatwg.org/multipage/webappapis.html#entry-settings-object) |
+of the HTML spec. The current context is a concept to implement the |
+[incumbent settings object](https://html.spec.whatwg.org/multipage/webappapis.html#incumbent-settings-object) |
+of the HTML spec. |
+ |
+In summary, the entered context is a context from which the current JavaScript |
+execution was started. The current context is a context of |
+the JavaScript function that is currently running. |
+ |
+## World |
+ |
+A world is a concept to sandbox DOM wrappers among content scripts of |
+Chrome extensions. There are three kinds of worlds: a main world, |
+an isolated world and a worker world. |
+A main world is a world where a normal JavaScript downloaded from the web |
+is executed. |
+An isolated world is a world where a content script of a Chrome extension. |
+An isolate of the main thread has 1 main world and N isolated worlds. |
+An isolate of a worker thread has 1 worker world and 0 isolated world. |
jochen (gone - plz use gerrit)
2016/01/07 10:18:44
is that also true for compositor workers?
haraken
2016/01/08 05:22:34
This description is true, but it is not true that
|
+[This diagram](https://drive.google.com/file/d/0B1obCOyvTnPKQmJEWkVtOEN2TmM/view?usp=sharing) |
+will be helpful to understand the relationship. |
+ |
+All worlds in one isolate share underlying C++ DOM objects, |
jochen (gone - plz use gerrit)
2016/01/07 10:18:45
for one specific iframe that is
haraken
2016/01/08 05:22:34
What do you mean?
|
+but each world has its own DOM wrappers. That way the worlds in one isolate |
+can operate on the same C++ DOM object without sharing any DOM wrapper |
+among the worlds. |
+ |
+Also each world has its own context. |
+This means that each world has its own global variable scope and |
+prototype chains. |
+ |
+As a result of the sandboxing, the worlds in one isolate cannot share |
+any DOM wrappers or contexts but can share underlying C++ DOM objects. |
+The fact that no DOM wrappers or contexts are shared means that no JavaScript |
+objects are shared among the worlds. That way we guarantee the security model |
+that Chrome extensions doesn't share any JavaScript objects while sharing |
+the underlying C++ DOM objects. This sandbox allows the Chrome extensions to run |
+untrusted JavaScripts on a shared DOM structure. |
+ |
+(Note: An isolated world is a concept of V8 binding, |
+whereas an isolate and a context are a concept of V8. |
+V8 does not know what isolated worlds are in an isolate.) |
+ |
+In summary, an isolate of the main thread consists of 1 main world |
+and N isolated worlds. An isolate of a worker thread consists of |
+1 worker world and 0 isolated world. All worlds in one isolate share the |
+underlying C++ DOM objects, but each world has its own DOM wrappers. |
+Each world has its own context and thus has its own global variable scope |
+and prototype chains. |
+ |
+## A relationship between isolates, contexts, worlds and frames |
+ |
+Let's wrap up the relationship between isolates, contexts, worlds and frames. |
+ |
+* As a requirement of the DOM side, one HTML page has N frames. |
+Each frame has its own context. |
+ |
+* As a requirement of the JavaScript side, one isolate has M worlds. |
+Each world has its own context. |
+ |
+As a result, when we execute the main thread where N frames and M worlds |
+are involved, there exists N * M contexts. In other words, one context is |
+created for each pair of (frame, world). |
+[This diagram](https://drive.google.com/file/d/0B1obCOyvTnPKSERSMmpRVjVKQWc/view?usp=sharing) |
+will be helpful to understand the relationship. |
+ |
+The main thread can have only one current context at one time, |
+but the main thread can have the N * M contexts over its lifetime. |
+For example, when the main thread is operating on a frame X using a JavaScript |
+in a world Y, the current context is set to a context for the pair of (X, Y). |
+The current context of the main thread changes over its lifetime. |
+ |
+On the other hand, a worker thread has 0 frame and 1 world. |
+Thus a worker thread has only 1 context. |
+The current context of the worker thread never changes. |
+ |
+## DOM wrappers and worlds |
+ |
+For compatibility reasons (although this is not speced), |
jochen (gone - plz use gerrit)
2016/01/07 10:18:45
At least some specs explicitly state this
haraken
2016/01/08 05:22:34
Removed the words in the parentheses.
|
+we need to make sure that the same DOM wrapper is returned to JavaScript |
+as long as the underlying C++ DOM object is alive. |
+We should not return different DOM wrappers for the same C++ DOM object. |
+ |
+Here is an example: |
+ |
+```html |
+var div = document.createElement("div"); |
+div.foo = 1234; // expando |
+var p = document.createElement("p"); |
+p.appendChild(div); |
+div = null; |
+gc(); |
+console.log(p.firstChild.foo); // This should be 1234, not undefined |
+``` |
+ |
+To accomplish the semantics that the same DOM wrapper is returned to JavaScript |
+as long as the underlying C++ DOM object is alive, we need a mapping |
+from the C++ DOM objects to the DOM wrappers. |
+In addition, we need to sandbox DOM wrappers in each world. |
+To meet the requirements, we make each world hold a DOM wrapper storage |
+that stores a mapping from the C++ DOM objects to the DOM wrappers in that world. |
+ |
+As a result, we have multiple DOM wrapper storages in one isolate. |
+The mapping of the main world is written in ScriptWrappable. |
+If ScriptWrappable::m_wrapper has a non-empty value, it is a DOM wrapper of |
+the C++ DOM object of the main world. |
+The mapping of other worlds are written in DOMWrapperMap. |
+ |
+## DOM wrappers and contexts |
+ |
+When you create a new DOM wrapper, you need to choose a correct context |
+on which the DOM wrapper is created. If you create a new DOM wrapper in a |
+wrong context, you will end up with leaking JavaScript objects to other |
+contexts, which is very likely to cause security issues. |
+ |
+Here is an example: |
+ |
+```html |
+// main.html |
+<html><body> |
+<iframe src="iframe.html"></iframe> |
+<script> |
+var iframe = document.querySelector("iframe"); |
+iframe; // The wrapper of the iframe should be created in the context of the main frame. |
+iframe.contentDocument; // The wrapper of the document should be created in the context of the iframe. |
+iframe.contentDocument.addEventListener("click", |
+ function (event) { // The wrapper of the event should be created in the context of the iframe. |
+ event.target; |
+ }); |
+</script> |
+</body></html> |
+ |
+// iframe.html |
+<script> |
+</script> |
+``` |
+ |
+To make sure that a DOM wrapper is created in a correct context, you need to |
+make sure that the current context must be set to the correct context |
+whenever you call toV8(). If you're not sure what context to use, |
+ask haraken@chromium.org. |
+ |