Bug 187639

Created attachment 344938 [details]
Patch

Created attachment 344939 [details]
Patch

Created attachment 344940 [details]
Patch

Extended the api to allow passing a custom class to be used for the object.

Created attachment 345034 [details]
Patch

Updated the API again. I've realized that it doesn't make sense to limit the new object as property of the context global object, you might want to add the object to a namespace object, for example. Now that API returns the object as an out parameter so that you can add it to any other object.

Comment on attachment 345034 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=345034&action=review

> Source/JavaScriptCore/API/glib/JSCContext.cpp:775
> + * in @uri; the value is one-based so the first line is 1. @uri and @line_number will be shown in exceptions,
> + * they don't affect the behavior of the script.

This is a comma splice (in the last sentence). You know by now your options for how to fix it.

> Source/JavaScriptCore/API/glib/JSCContext.cpp:793
> + * jsc_context_evaluate_in_object:

It's confusing that this function always creates the object that evaluates the JS. Would it not be useful to be able to pass an existing object?

> Source/JavaScriptCore/ChangeLog:9
> +        evaluated script are added as propertuies to the new object instead of to the context global object. This is

properties

Comment on attachment 345034 [details]
Patch

Attachment 345034 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/8537661

New failing tests:
http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin.html
http/tests/security/canvas-remote-read-remote-video-localhost.html

Created attachment 345039 [details]
Archive of layout-test-results from ews205 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews205  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

(In reply to Michael Catanzaro from comment #5)
> Comment on attachment 345034 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=345034&action=review
> 
> > Source/JavaScriptCore/API/glib/JSCContext.cpp:775
> > + * in @uri; the value is one-based so the first line is 1. @uri and @line_number will be shown in exceptions,
> > + * they don't affect the behavior of the script.
> 
> This is a comma splice (in the last sentence). You know by now your options
> for how to fix it.

Sure!

> > Source/JavaScriptCore/API/glib/JSCContext.cpp:793
> > + * jsc_context_evaluate_in_object:
> 
> It's confusing that this function always creates the object that evaluates
> the JS. Would it not be useful to be able to pass an existing object?

Indeed, that would be ideal and we wouldn't need the JSCClass parameter, but it's not possible without making a lot more changes to JSC. With current JSC, we need to use a new context to get its global object, so we can't pass an existing object. To use an existing object we would need a special scope mode that also "redirects" the assignments. Yusuke can explain much better than me. The good thing about this approach is that we can change the impl if JSC ever had this new scope keeping the existing API, so it can be optimized internally. Note that even if the function received an existing object, it would be an empty object in most of (if not all) the cases.

> > Source/JavaScriptCore/ChangeLog:9
> > +        evaluated script are added as propertuies to the new object instead of to the context global object. This is
> 
> properties

Oops.

Committed r233844: <https://trac.webkit.org/changeset/233844>

<rdar://problem/42236712>