Bug 85709 – Web Inspector: [JSC] support JS execution in the context of an isolated world

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector (Deprecated)

[Yury Semikhatsky]

Web Inspector should allow console evals in isolated worlds.

[Oliver Hunt]

Can you explain what this actually means?

[Yury Semikhatsky]

After https://bugs.webkit.org/show_bug.cgi?id=85612 is landed it should be possible to select exact JS context in which snippets entered in Web Inspector console should be executed. At the moment it is only possible to select a frame and evaluation will be performed in the main world context of that. This bug is about adding an option to specify exact isolated world in which to perform the evaluation.  Most of the stuff will be added once fix for 85612 is landed and the only remaining part will be to provide information about non-main-world contexts from JS bindings to the inspector code. I was going to take a look at this when https://bugs.webkit.org/show_bug.cgi?id=85612 is fixed.

[Yury Semikhatsky]

I'm trying to figure out what can be used to discriminate between different DOMWrapperWorlds on a given Frame. In V8 bindings each isolated context has its own security origin which is used in the inspector front-end as the context name. I don't see similar API in the JS bindings and it looks to me that in case of JSC all isolated contexts will have same security origin as the DOMWindow. Can someone familiar with the JS bindings enlighten me on this?

[Geoffrey Garen]

(In reply to comment #3)
> I'm trying to figure out what can be used to discriminate between different DOMWrapperWorlds on a given Frame.

Inside WebCore, we use a DOMWrapperWorld pointer. See WebCore::ScriptController::evaluateInWorld().

To map the current execution context to the current DOMWrapperWorld, we use WebCore::currentWorld():

inline DOMWrapperWorld* currentWorld(JSC::ExecState* exec)
{
    return JSC::jsCast<JSDOMGlobalObject*>(exec->lexicalGlobalObject())->world();
}

[Yury Semikhatsky]

(In reply to comment #4)
> (In reply to comment #3)
> > I'm trying to figure out what can be used to discriminate between different DOMWrapperWorlds on a given Frame.
> 
> Inside WebCore, we use a DOMWrapperWorld pointer.
It is still not clear to me how we can represent the world to the user in the inspector UI. In V8 bindings each V8IsolatedContext (a counterpart of JSDOMWindowShell in case of non-main world as I understand) will have its own security origin which is basically a URL of the extension which created that context. In the inspector UI we have a combobox with URLs of all the extensions that have content scripts in the selected Frame. The URLs are quite convenient for specifying a context where the console evaluation should happen. The problem is that DOMWrapperWorld doesn't provide access to such URL. I didn't find a good identifier(which could be used in the inspector UI) on JSDOMWindowShell either.

[Geoffrey Garen]

(In reply to comment #5)
> In the inspector UI we have a combobox with URLs of all the extensions that have content scripts in the selected Frame.

Which URL do you use? The content script URL? Global page URL? Something else?

In WebKit, DOMWrapperWorld doesn't require an associated URL or domain, so it doesn't have one to display. Perhaps you could infer a URL for display simply by recording the first URL passed to ScriptController::evaluateInWorld() for any give DOMWrapperWorld.

[Yury Semikhatsky]

(In reply to comment #6)
> (In reply to comment #5)
> > In the inspector UI we have a combobox with URLs of all the extensions that have content scripts in the selected Frame.
> 
> Which URL do you use? The content script URL? Global page URL? Something else?
> 
The URL of an extension that created the context and will evaluate all content scripts in it. As I understand this URL is used for security checks when the content script sends XHR for example(a counterpart of DOMWindow::securityOrigin for isolated world).

> In WebKit, DOMWrapperWorld doesn't require an associated URL or domain, so it doesn't have one to display. Perhaps you could infer a URL for display simply by recording the first URL passed to ScriptController::evaluateInWorld() for any give DOMWrapperWorld.
This sounds reasonable, given that DOMWrapperWorld doesn't require an associated URL or domain I don't think we can come up with a better solution in this case.

[Peter Wang]

Is someone working on it now? If not, I'd like to have a try.

[Timothy Hatcher]

I don't think anyone is.

[Peter Wang]

Created attachment 150707 [details]
Patch

[Gavin Barraclough]

Comment on attachment 150707 [details]
Patch

Looks good to me.

[Leo Yang]

Comment on attachment 150707 [details]
Patch

Sending to cq.

[WebKit Review Bot]

Comment on attachment 150707 [details]
Patch

Clearing flags on attachment: 150707

Committed r121891: <http://trac.webkit.org/changeset/121891>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.