Bug 85709

Summary: Web Inspector: [JSC] support JS execution in the context of an isolated world
Product: WebKit Reporter: Yury Semikhatsky <yurys>
Component: Web Inspector (Deprecated)Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: apavlov, barraclough, bweinstein, charles.wei, ggaren, joepeck, keishi, loislo, mark.lam, oliver, PeterHWang, pfeldman, pmuellr, rik, timothy, webkit.review.bot, yurys
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 85612, 90594    
Bug Blocks:    
Attachments:
Description Flags
Patch none

Description Yury Semikhatsky 2012-05-05 07:22:47 PDT
Web Inspector should allow console evals in isolated worlds.
Comment 1 Oliver Hunt 2012-05-05 10:19:27 PDT
Can you explain what this actually means?
Comment 2 Yury Semikhatsky 2012-05-05 23:37:49 PDT
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.
Comment 3 Yury Semikhatsky 2012-05-22 02:30:29 PDT
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?
Comment 4 Geoffrey Garen 2012-05-22 11:58:02 PDT
(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();
}
Comment 5 Yury Semikhatsky 2012-05-22 22:53:59 PDT
(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.
Comment 6 Geoffrey Garen 2012-05-22 23:17:21 PDT
(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.
Comment 7 Yury Semikhatsky 2012-05-22 23:39:32 PDT
(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.
Comment 8 Peter Wang 2012-06-26 03:48:10 PDT
Is someone working on it now? If not, I'd like to have a try.
Comment 9 Timothy Hatcher 2012-06-28 10:20:49 PDT
I don't think anyone is.
Comment 10 Peter Wang 2012-07-03 19:04:23 PDT
Created attachment 150707 [details]
Patch
Comment 11 Gavin Barraclough 2012-07-04 23:52:39 PDT
Comment on attachment 150707 [details]
Patch

Looks good to me.
Comment 12 Leo Yang 2012-07-05 00:21:50 PDT
Comment on attachment 150707 [details]
Patch

Sending to cq.
Comment 13 WebKit Review Bot 2012-07-05 01:20:05 PDT
Comment on attachment 150707 [details]
Patch

Clearing flags on attachment: 150707

Committed r121891: <http://trac.webkit.org/changeset/121891>
Comment 14 WebKit Review Bot 2012-07-05 01:20:12 PDT
All reviewed patches have been landed.  Closing bug.