1601421 - The execution context created by Page.createIsolatedWorld should have its own window global (sandbox)

Status: RESOLVED WONTFIX

(Remote Protocol :: CDP, enhancement, P2)

Description

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

This is a follow-up from Bug 1597877. I'm not sure yet whether it affects gutenberg tests.

As I understand it, an isolated world is in fact like a frame script that is not affected by any downloaded js that is executed on a document. See this Blink reference regarding the concept of an "isolated world". https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/bindings/core/v8/V8BindingDesign.md

For example, in Puppeteer they use an isolated world (the "secondary" world) to make sure their injected scripts aren't broken by, say, the top-level Event class being overridden by the loaded document: see https://github.com/puppeteer/puppeteer/pull/3346/files

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We need bug 1605359 prioritized. As such we have to move this one into the backlog.

Comment 2

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

This might be similar concept to Marionette's execute_script in a sandbox.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Actually this is a good point! We would have to check if using sandboxes is still a valid thing to do for Fission. I would expect so given that I don't know about another technique yet in how to set globals only for specific contexts.

Bob, not sure if the info above is enough but maybe you know or can forward to someone who has the knowledge?

Comment 4

[Bob Owen (:bobowen)]

I think the Sandbox in question here is more of an XPConnect thing and given that this also mentions fission, I imagine Nika might be best placed to answer it.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Chrome's model for things like content scripts is quite different from our internal model in various ways. I think I would need to understand a bit more about what this API is trying to provide in order to point you in the right direction here.

My current guess is that you're wanting to effectively behave the same way as a webextension content script behaves, but do correct me if I'm wrong.

Comment 6

[Maja Frydrychowicz :impossibus (was :maja_zf) (needinfo me)]

(In reply to Nika Layzell [:nika] (ni? for response) from comment #5)

My current guess is that you're wanting to effectively behave the same way as a webextension content script behaves, but do correct me if I'm wrong.

Partly, yes? Definitely the Xray vision behaviour of webext content scripts matches what we need here.

One thing I'm not sure about is the independence of isolated worlds: "each world has its own context. This means that each world has its own global variable scope and prototype chains." whereas I don't think that's the case for content scripts.

From https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts:

There is only one global scope per frame, per extension. This means that variables from one content script can directly be accessed by another content script, regardless of how the content script was loaded.

Given all that, what can you recommend, Nika?

Comment 7

[Nika Layzell [:nika] (ni? for response)]

The reason behind the distinction is related to a difference in how chrome handles their JS runtimes. Chrome does not have xray vision behaviour, and instead creates a new "isolated world" for each content script, with a completely different JS wrapper object, reflecting the same DOM tree. In contrast, our code takes advantage of our xray vision behaviour to allow us to have moslty isolated worlds with their own global variable scope, but shared underlying objects.

It's not easy for us to 100% emulate chrome's behaviour here, as we do not support a single DOM object having multiple JS reflector objects for various reasons. The behaviour which you probably want to have here, is the behaviour we have for content scripts.

ni? to :kmag who has worked more closely on the isolation/xray/etc. behaviour of our content script JS runtime environments, and can probably give more useful advice.

Comment 8

[Kris Maglione [:kmag]]

Chrome's multiple world concept was created for extension content scripts, so I would imagine that the semantics are the same when it's used by the debugging protocol as it is when it's used for extensions.

(In reply to Maja Frydrychowicz :maja_zf (UTC-4) ([e-mail]) from comment #6)

One thing I'm not sure about is the independence of isolated worlds: "each world has its own context. This means that each world has its own global variable scope and prototype chains." whereas I don't think that's the case for content scripts.

It is. There are some "gotcha"s, though, in that the window object is not the same object as the global for content scripts in Firefox, so unqualified Object, e.g., points to a different constructor than window.Object. This mostly doesn't matter, except when scripts use unnecessary qualification for one reason or other.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We are not going to finish this API for CDP while WebDriver BiDi has full support via script.createRealm already.