The card recorded a hypothesis and said not to assume it: that Firefox's deepFind resolved
only the outermost shadow root. Measured and disproved — both engines find exactly one
shadow host at depth 0, so shadow traversal is identical. The real difference is WebGL.
Chromium reports webglSupported true with 157 elements in the shadow root and the toolbar
present; Firefox reports false with 31 elements, no toolbar, and "[doxa-simple-map] Map
failed to initialize".
Confirmed as an environment property, not a page one: Firefox returns null from getContext
on a blank page here, and firefoxUserPrefs for software WebGL do not change it. Chromium
only works because launch() passes SwiftShader args. So the Share button is never rendered
because the map never initialises, and the suite was blaming the product for that.
Rather than quietly defaulting away from the Driver's house rule, the suite now aborts with
the measurement and the exact working command, and exits 2 so a caller can tell "could not
test" from "test failed". Restating the rule stays the Driver's call.
It also had no token wiring, the third gate found missing it. My first attempt set only
window.MAP_TOKEN, assuming a page global would survive into the reopened page. Measured:
?tk= only mounts, global only does NOT mount, both mount. The global is read by nested
children of a composite, not by a top-level element. So the host URL carries ?tk= and the
share URL is navigated verbatim, because appending a token there would fake the very thing
under test.
The remaining failure is now honest and in the right place: the host page renders, and the
share URL cannot, because a pasteable link deliberately strips query params. Only the token
endpoint fixes that.
d58643f1df