js.Origin was added to allow frames on the same origin to share our zig<->js
maps / identity. It assumes that scripts on different origins will never be
allowed (by v8) to access the same zig instances.
If two different origins DID access the same zig instance, we'd have a few
different problems. First, while the mapping would exist in Origin1's
identity_map, when the zig instance was returned to a script in Origin2, it
would not be found in Origin2's identity_map, and thus create a new v8::Object.
Thus we'd end up with 2 v8::Objects for the same Zig instance. This is
potentially not the end of the world, but not great either as any zig-native
data _would_ be shared (it's the same instance after all), but js-native data
wouldn't.
The real problem this introduces though is with Finalizers. A weak reference
that falls out of scope in Origin1 will get cleaned up, even though it's still
referenced from Origin2.
Now, under normal circumstances, this isn't an issue; v8 _does_ ensure that
cross-origin access isn't allowed (because we set a SecurityToken on the
v8::Context). But it seems like the v8::Inspector isn't bound by these
restrictions and can happily access and share objects across origin.
The simplest solution I can come up with is to move the mapping from the Origin
to the Session. This does mean that objects might live longer than they have to.
When all references to an origin go out of scope, we can do some cleanup. Not
so when the Session owns this data. But really, how often are iframes on
different origins being created and deleted within the lifetime of a page?
When Origins were first introduces, the Session got burdened with having to
manage multiple lifecycles:
1 - The page-surviving data (e.g. history)
2 - The root page lifecycle (e.g. page_arena, queuedNavigation)
3 - The origin lookup
This commit doesn't change that, but it makes the session responsible for
_a lot_ more of the root page lifecycle (#2 above).
I lied. js.Origin still exists, but it's a shell of its former self. It only
exists to store the SecurityToken name that is re-used for every context with
the same origin.
The v8 namespace leaks into Session.
MutationObserver and IntersectionObserver are now back to using weak/strong refs
which was one of the failing cases before this change.
https://github.com/lightpanda-io/browser/pull/1870 doesn't work. I think there
are ways for the inspector to move objects into a context that skips our
reference count (those remote objects?). This disables weak references for
MutationObserver and IntersectionObserver. The issue is probably more widespread
but these are two types CDP drivers us _a lot_ via inspector, so this should
fix a number of immediate crashes.
I believe the correct fix is to remove Origin and store things at the Session-
level.
This specifically fixes a WPT crash running:
/html/browsers/browsing-the-web/history-traversal/001.html
(And probably a few others).
Isolate::GetCurrentContext can return a 'detached' context. And, for us, that's
a problem, because 'detached' v8::Context references a js.Context that we've
deinit'd. This seems to only happen when frames pass values around to other
frames and then those frames are removed. It might also require some async'ing,
I'm not sure.
To solve this, when we destroy a js.Context, we store null in the v8::Context's
embedder data, removing the link to our (dead) js.Context. When we load a
js.Context from a v8.Context, we check for null. If it is null, we return the
Incumbent context instead. This should never be null, as it's always the context
currently executing code.
I'm not sure if falling back to the Incumbent context is always correct, but
it does solve the crash.
