It's important that tools are document-scoped. Most of the time Window/Navigator and Document are 1:1, however navigations away from the initial about:blank Document share a Window object, which complicates things.
The case where this is observable is when you register tools with the initial about:blank Document, and then navigate away from it. Per the current spec, after the navigation, calls to navigator.modelContext return the same object that holds the same map of tools, which means tools are effectively shared across this navigation.
I recently caught this bug in Chromium when working on the iframe + permission policy implementation, and ended up changing Blink's implementation such that:
- The backing
ModelContext interface object is stored on Document instead of Navigator
- The
navigator.modelContext IDL getter doesn't just return the same object; instead it consults its Window's active Document, and returns its ModelContext object. It returns null if the Window isn't available (detached document) or if the document isn't fully active (bf-cache).
I'll update the spec to agree with this.
Follow-up: API placement
An oddity of the above is that the API is effectively scoped to the Document, yet it lives off of navigator. I personally never liked putting things on navigator, and would recommend that we do one of two things:
It's important that tools are document-scoped. Most of the time Window/Navigator and Document are 1:1, however navigations away from the initial about:blank Document share a Window object, which complicates things.
The case where this is observable is when you register tools with the initial about:blank Document, and then navigate away from it. Per the current spec, after the navigation, calls to
navigator.modelContextreturn the same object that holds the same map of tools, which means tools are effectively shared across this navigation.I recently caught this bug in Chromium when working on the iframe + permission policy implementation, and ended up changing Blink's implementation such that:
ModelContextinterface object is stored on Document instead of Navigatornavigator.modelContextIDL getter doesn't just return the same object; instead it consults its Window's active Document, and returns itsModelContextobject. It returns null if the Window isn't available (detached document) or if the document isn't fully active (bf-cache).I'll update the spec to agree with this.
Follow-up: API placement
An oddity of the above is that the API is effectively scoped to the Document, yet it lives off of
navigator. I personally never liked putting things onnavigator, and would recommend that we do one of two things:Document, giving usdocument.modelContext. This seems more intuitiveWindow. This has the same scoping oddity asNavigatorsince both are 1:1, but it follows the guidance in New principle: Avoid adding (non-constructor) functions to the global scope w3ctag/design-principles#426 that most editors seem to have expressed, which is hanging things off of the global instead of a weird namespace likenavigator