The IDX_BrowserId synced field is stored as a 64-bit value, but the BrowsingContext::CanSet(FieldIndex<IDX_BrowserId>, ...) validation overload declared its aValue parameter as const uint32_t& instead of const uint64_t&. Because the parameter type did not match the field’s real width, the value flowing through the field-sync machinery was reinterpreted or truncated to 32 bits at the validation boundary, so CanSet did not reason about the same value the field actually carried. This breaks the invariant that a field’s validator inspects the exact value being committed, allowing a mismatch between what the parent validates and what is stored/propagated for the BrowserId. Given the metadata (a use-after-free in DOM navigation leading to sandbox escape), a BrowserId that is validated inconsistently or collides after truncation can misassociate a BrowsingContext, leaving navigation code holding a reference tied to a stale or wrong browser.

The fix changes both the declaration in BrowsingContext.h and the definition in BrowsingContext.cpp to take const uint64_t& aValue, so validation operates on the full-width identifier. With matched types there is no truncation and the parent enforces its “only settable on a top-level context that has no ID yet” check against the true value.

An attacker who already controls a content process can, per the metadata, drive a use-after-free in the DOM navigation component and escalate to a sandbox escape. The corrupted validation occurs at the parent-process boundary for the BrowserId synced field, so the consequence crosses the content/parent trust boundary. The precondition is code execution or scripting control within a content process capable of proposing BrowsingContext field changes over IPC.