On 10/14/15 2:57 PM, Bill McCloskey wrote:
I'd like to understand in more detail how isolated worlds are implemented.
The basic idea is that any getter or setter (or method that might retrieve or store state) that operates on JS values as opposed to interface instances needs to take the current world as either a hidden (e.g. fetchable via some function) or explicit parameter and carefully make sure that all setting and getting is compartmentalized on a per-world basis.
That, plus some automated machinery for creating interface instance reflectors on a per-world basis.
We might be able to get some ideas about how to improve our model without totally changing it. Or we'll find out that they're bad or have serious security problems--that's fine too.
The big problem is that it's easy to screw up the manual per-world compartmentalization. You can manage if you have decent runtime asserts and good test coverage, but they've had a number of bugs where someone messed it up.
Isolated worlds seem a lot more appealing to add-on authors since they generally "just work."
Except when they don't. See the CustomEvent example, or the inability to see whether the page set window.onload and to what, or to examine the page's event listeners, etc, etc.
Basically, isolated worlds mean that more and more of the web, to the extent that it moves to ES objects as opposed to interface objects, can't be shared between the addon and the page, so when you operate on page objects you can't see a bunch of their state.
-Boris _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
