cloudtrends / chromiumembedded

Automatically exported from code.google.com/p/chromiumembedded
1 stars 1 forks source link

Can't create V8 Objects, Arrays, and Functions outside a V8 context #203

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
It turns out that those kinds of objects depend on the existence of a V8 
context while simple types like string, int, double, boolean, etc. do not.

Attached is a patch that addresses this by letting clients call 
CefV8Context::Enter() and CefV8Context::Exit() so that a context can be 
established from the client side. Once in a context, you are free to create 
objects, functions and arrays. Enter/Exit need to be called in pairs; nesting 
is OK. Debug checks will warn you if you release a CefV8Context that did not 
get as many Exit() calls as Enter(). These methods return false if called 
outside the UI thread.

Original issue reported on code.google.com by gusver...@gmail.com on 11 Mar 2011 at 8:08

Attachments:

GoogleCodeExporter commented 9 years ago
Is the context only required to create these types, or to access/modify them as 
well?

Original comment by magreenb...@gmail.com on 11 Mar 2011 at 8:12

GoogleCodeExporter commented 9 years ago
Attempting to create one of these when there is no context will result in a 
crash.

Access and modify should probably be done from within a context. I have gotten 
away with reading simple properties. Modification implies create so you will 
need a context there if you attempt to add a non-simple type.

It is not clear to me what would happen if you try to modify an object created 
in one context from another context. It is possible that this would work.

For now, this solves the enter/exit a context from the client part of the 
problem.

Original comment by gusver...@gmail.com on 11 Mar 2011 at 8:51

GoogleCodeExporter commented 9 years ago
1. What happens if someone forgets to call Exit() after calling Enter()?
2. Is there a valid use case for accessing the same V8 object from multiple 
contexts?

Original comment by magreenb...@gmail.com on 11 Mar 2011 at 10:00

GoogleCodeExporter commented 9 years ago
1. Since this being done from the client side, at worst case, it will leave the 
 context active. As mentioned, in debug builds, this code will warn you if you 
release the context object while there were more Enter calls than Exit. Clients 
can wrap the Enter/Exit call in a class that calls Enter in the constructor and 
Exit in the destructor to help make this safer.

2. The best example I can think of is when you do cross-frame calls. e.g. when 
a parent window calls window.open to open a child window and then invokes a 
method in the child window's context via the resulting window object while 
passing in an object created in the parent's context.

Original comment by gusver...@gmail.com on 11 Mar 2011 at 11:45

GoogleCodeExporter commented 9 years ago
Any update on the state of this patch?

I have a new patch I want to submit that adds support for 
v8::Object::SetAccessor(...) that lets you create getter/setter style 
properties in CefV8Value objects.

Should I create a new issue or would you be willing to accept a combined patch?

Original comment by gusver...@gmail.com on 21 Mar 2011 at 8:31

GoogleCodeExporter commented 9 years ago
Go ahead and create a single patch. Also, please include unit tests.

Original comment by magreenb...@gmail.com on 21 Mar 2011 at 10:39

GoogleCodeExporter commented 9 years ago
Attached is a patch that includes the previous patch plus support for property 
accessors.

* Adds a new client implemented class, CefV8Accessor, with two methods, 
Get(...) and Set(...).
* Overloads CefV8Value::CreateObject() to accept a user_data and a 
CefV8Accessor handler. (one handler per object.)
* Overloads CefV8Value::SetValue("name", cef_v8_accesscontrol_t ac, 
cef_v8_propertyattribute_t pa) to let you define properties that are accessed 
via the object's CefV8Accessor and their access rules.
* Unit tests for both features are in the v8_unittest.cc file.

Original comment by gusver...@gmail.com on 22 Mar 2011 at 12:13

Attachments:

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
One more for the V8 bus...

I need to be able to tell if two CefV8Values point to the same function, 
object, or array, etc. This is useful when registering a callback and then 
using the same function as the object to be removed in a client API.

Attached is a patch that includes the previous patches and adds:

bool CefV8Value::IsSame(CefRefPtr<CefV8Value> that);

Thank you for taking a look at these patches.

Original comment by gusver...@gmail.com on 22 Mar 2011 at 3:33

GoogleCodeExporter commented 9 years ago
This time with the patch ;)

Original comment by gusver...@gmail.com on 22 Mar 2011 at 3:34

Attachments:

GoogleCodeExporter commented 9 years ago
I haven't tested it yet but on inspection the patch looks good.

Original comment by magreenb...@gmail.com on 22 Mar 2011 at 11:34

GoogleCodeExporter commented 9 years ago
Committed as revision 215 with minor style changes.

Original comment by magreenb...@gmail.com on 7 Apr 2011 at 1:59

GoogleCodeExporter commented 9 years ago
Issue 224 has been merged into this issue.

Original comment by magreenb...@gmail.com on 29 Apr 2011 at 7:01