Bug 85709

Can you explain what this actually means?

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.

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?

(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(); }

(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.

(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.

(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.

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

I don't think anyone is.

Created attachment 150707 [details] Patch

Comment on attachment 150707 [details] Patch Looks good to me.

Comment on attachment 150707 [details] Patch Sending to cq.

Comment on attachment 150707 [details] Patch Clearing flags on attachment: 150707 Committed r121891: <http://trac.webkit.org/changeset/121891>

All reviewed patches have been landed. Closing bug.