New issue
Advanced search Search tips

Issue 615167 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: May 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Extension API in Extension SW assumes isolated worlds exist only on main thread

Project Member Reported by lazyboy@chromium.org, May 26 2016

Issue description

Kentaro pointed this during CL review:

https://codereview.chromium.org/1880933002/#msg44
I noticed that this CL would not be enough to enable extensions on SW, because
some methods (e.g., DOMWrapperWorld.cpp) are assuming that isolated worlds exist
only on the main thread (e.g., we have isMainThread() checks).

haraken@, can you explain this a bit?
 
Look at https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/core/v8/DOMWrapperWorld.cpp&q=domwrapperworld.cpp&sq=package:chromium&type=cs&l=123

There is only one isolated world map for the main thread, meaning that you cannot have isolated worlds in a non-main thread. You need to add another isolated world map for a service-worker thread.

BTW, do you have any test for SW extensions? I don't think it works for the reason above.

Thanks.

If I understand correctly, we wouldn't need to create isolated worlds in the extension renderer itself, which implies that we wouldn't need them in the extension's SW. content_scripts and chrome.tabs.executeScript are the two APIs where isolated worlds are used, but they operate in the tab's renderer process.

re: test: yes, I have a basic end to end test in that CL that verifies extension SW calling extension API and getting response back via callback.
On which thread, is the chrome.tabs.executeScript called?

That would be the main renderer thread of the extension, e.g. a background page can call chrome.tabs.executeScript(tab_id, {code: 'alert("hi");})
(The test I mentioned calls chrome.tabs.create())

The alert would run in an isolated world in the tab_id tab's renderer process.
The background page is running on the SW thread, right?

When the background page calls chrome.tabs.executeScript, is it redirected to the main thread and then the main thread runs the content script?

I'd like to understand how the extensions are working in SW.

I think I tried to describe what happens in non-sw case in comment #4

Let me explain what happens in the SW case (though the executeScript example is hypothetical since I haven't tried this yet, I've only tried tabs.create)

My CL allows extension API definition/bindings to be available in extension-created service workers. This bindings are available on worker thread.

So let's say we have an extension E, that has a service worker S. Separate from all of these, we have a tab T where we want E to execute script to.

1. S calls chrome.tabs.executeScript(tab_id, {code: '...'}), we are in worker thread, this will end up in RequestSender::StartRequest.
2. From the worker thread, we send an IPC to browser/ process to run the executeScript function (ExtensionHostMsg_RequestWorker).
3. browser/ process finds the tab with tab_id, T. browser/ process asks T's renderer to execute the script, through IPC ExtensionMsg_ExecuteCode.
4. That would end up running '...' code above in T renderer's isolated world.

Does that answer your q? In this scenario, we are not using isolated worlds at all in E or S, only in T.

It seems like you are thinking that something in #1 might use isolated worlds?
Status: WontFix (was: Assigned)
Ah, thanks. That totally makes sense :)

Then the existing system should just work -- you won't need any change in DOMWrapperWorld. Sorry about the noise!



Sign in to add a comment