fix(browser-session): close navigation authority on download start

[seonghobae]

Problem

The Browser Session navigation-authority contract models complete-positive (browsingContext.load / complete fragment) and typed negative (navigationAborted / navigationFailed) terminal paths, but a navigation that transitions into a download needs a distinct liveness closure. If presentation authority is invalidated at navigationStarted and download start cannot close that pending navigation, a legitimate navigation-to-download can strand authority even though no ordinary document load follows.

Standards provenance boundary

The protocol semantic under review is browsingContext.downloadWillBegin carrying navigation/context correlation and the navigation algorithm admitting a download-start outcome. Volatile WebDriver BiDi publication-currentness and the separately runtime-qualified OriginWeave revision are canonical #229 evidence in docs/traceability/webdriver-bidi-publication-current.md; this issue does not maintain a second dated latest/previous publication snapshot.

Before implementation or runtime acceptance, #316 must prove that the admitted #229 revision actually supplies the required downloadWillBegin correlation semantics. A newer publication does not silently repin the runtime. The Editor's Draft is research input only until admitted through the #229 capability/requalification path.

Ownership boundary

• feat: add privacy-preserving presentation identity kernel #229 owns WebDriver BiDi publication/runtime capability provenance.
• feat(bidi): bind current Browser Session authority to BiDi planning #316 owns protocol correlation of downloadWillBegin and other lifecycle delivery to the exact protocol navigation id and browsing context. Protocol ids remain non-authorizing evidence.
• fix(browser-session): require aggregate-issued lifecycle request authority #317 owns deterministic Browser Session authority invalidation, ownership-generation validation, navigation state, terminal/liveness transition, consumed-witness replay rejection, and explicit presentation-authority re-establishment.
• test(browser-session): invalidate stale authority on observed navigation #318 owns the navigation-acceptance successor tests/doctoring once fix(browser-session): require aggregate-issued lifecycle request authority #317 is on the admitted parent generation; test(browser-session): preserve navigation eligibility across sibling recreation #321 owns sibling-recreation/ABA acceptance.
• Download file handling, persistence, malware/static/dynamic analysis, egress, retention, or quarantine are not Browser Session responsibilities and stay with their canonical owners.

Current dependency authority — 23 September 2026 KST

#229 is exact 60318092c410111924415b3e20ee3f4186e6472a, open / Draft / mergeable. W3C's live WebDriver BiDi publication history lists 16 September 2026, 14 September 2026, 9 September 2026, then 3 September 2026 Working Drafts. Current #229 owns that volatile publication receipt and keeps the independently runtime-qualified adapter pin at 3 September 2026; publication freshness alone does not repin runtime compatibility. Exact CI 35713817985 is Draft-skipped; SAST 35713817883 and Security 35713817945 are terminal SUCCESS. CodeQL 35713817902 remains nonterminal: Detect 106700519278 is SUCCESS, Actions/Python/JavaScript compatibility jobs executed and failed closed only because the authenticated terminal current-head verdict was absent, and coordinator 106826100321 remains pre-step queued with runner_id=0 and steps=[]. Fresh review inspection has 0 unresolved threads and no qualifying current-head APPROVED review.

#317 is exact 70cc9d8ab9cbb79e3f7c8635ba5c4bec67d80b73, open / Draft / non-mergeable. Fresh GitHub compare from current #229 is ahead 634 / behind 31 / diverged at merge base 8dcacbaebf2a6f02c5bbda8e8d6cc8bce474b693. Reconciliation must preserve current parent truth and all 634 valid child deltas, including Browser Session's stronger single-writer publication-provenance contract, through ordinary/non-force history.

#318 remains exact 983fa652180e47e479c99b8903755f1fd60f0746 on predecessor #317 ancestry; #321 remains 9d3c51e7ff66c952dba203a04704e53df78d2b0e; #316 remains 8ca6c5a190d9ad2b4c7843d440e91f6070d681c2. Issue #212 owns the volatile central workflow/sandbox/admission prerequisites. Canonical .github#2278 owns the AnyIO 4.14.0 → 4.14.2 repair and is GREEN on SAST/Python Security/Security while CodeQL/current-head review acceptance remains open. Canonical .github#2291 is GREEN on Runtime Quality/SAST/Security, fails Python Security only at inherited AnyIO 4.14.0 pip-audit, and has nonterminal CodeQL. Those owner lanes must converge before full central acceptance; neither source may be copied here.

The former 21 September authority named #229 3ec6326b... and a 634-ahead/25-behind relationship. Earlier history named #229 ce5074f..., #317 54d7367..., and a 164-ahead/7-behind relationship. Those values are historical only and no longer define the implementation order.

Do not implement this issue by patching volatile standards dates, central workflow logic, or parent-owned Browser Session blobs into #318/#321/#316. Required order is #212 central dependency/trusted-runtime/admission prerequisite acceptance → #229 current executable native CI/CodeQL/current-review/ruleset acceptance, with exact SAST/Security already GREEN → #317 ordinary non-force parent adoption preserving all valid deltas and current standards authority → #318/#321 ordered restack → #316 protocol proof integration → this download-start acceptance on the current generation.

Acceptance

1. navigationStarted invalidates existing presentation mutation authority with zero adapter I/O and issues the aggregate-owned pending witness.
2. A matching, protocol-qualified downloadWillBegin for that same navigation closes the pending navigation in a typed, auditable way without treating command ACK as browser success and without spending a presentation epoch.
3. Retained pre-navigation authority remains fail closed.
4. Exactly one explicit reestablish_presentation_authority may follow the qualified download-start transition; duplicate re-establishment is rejected without adapter I/O or epoch consumption.
5. Stale, superseded, cross-context, cross-incarnation, post-destruction, or post-trust-loss download evidence is rejected before state mutation or adapter I/O. Reused raw session/context values are insufficient provenance.
6. Destroy/recreate ABA reuse of the same raw BrowsingContextId must produce a newer aggregate-issued BrowserContextEpoch; download evidence from the destroyed ownership generation cannot close the recreated generation's pending navigation, mutate recovery evidence, resurrect retained authority, or consume a presentation epoch.
7. A download transition in context A must not clear pending navigation state in sibling context B.
8. Once matching downloadWillBegin consumes a navigation witness for authority transitions, delayed/replayed navigationCommitted, complete-positive, navigationAborted, and navigationFailed evidence for that consumed witness must fail AuthorityMismatch before lifecycle/recovery/authority/epoch/I/O mutation. Before re-establishment the one download-derived opportunity remains usable; after re-establishment the fresh authority remains executable and no second opportunity is created.
9. Real runtime-qualified Chromium acceptance must exercise a response that becomes a download and prove the browser-observed post-condition, including delayed progress/terminal replay; command acknowledgement alone is insufficient.
10. Standards doctoring/TRACEABILITY must state why downloadWillBegin is a navigation-liveness boundary while later download lifecycle events do not themselves mint Browser Session authority.
11. Owned production rustdoc and function/line/region/branch coverage remain 100%; exact-head repository/security/browser gates must execute rather than being inferred from predecessor or skipped evidence.

Keep runtime qualification separate from standards publication freshness. This issue does not authorize a runtime repin, browser-policy widening, download persistence, central-owner source copy, or cross-owner SQL.

[seonghobae]

Test-first owner handoff is now staged in #318 without touching #317/#316 production source lanes. 2417b2ce06f21a31b2c9d95d4a1791f0f693039e adds the Rust RED for matching downloadWillBegin: old presentation authority stays revoked, the observation is zero-I/O and epoch-non-consuming, exactly one explicit re-establishment succeeds, duplicate re-establishment fails closed, and the minted authority remains usable. 93fcbfc0e9f633fe283e166db4f872c023b0871f adds the structural requirement that the production transition accept only the opaque aggregate-issued NavigationSettlementAuthority, not raw incarnation/context/epoch reconstruction. ca567457af446fbc9ee7bf532f071d4433d9909a updates standards doctoring and keeps downloadEnd/file handling outside Browser Session ownership. Current exact-head CI has Python repository contracts and canonical rustfmt GREEN, then locked Rust tests RED at the expected #317 missing production navigation API boundary; #320 is therefore not complete and remains open.

[seonghobae]

CodeRabbit review of the initial download RED found a valid hostile-witness coverage gap. 0ef110e4bc70b1c760e104e9256d515d8edf612c now adds explicit rejection/preservation cases beyond the happy path: superseded same-context witness (AuthorityMismatch), already-settled sibling witness (AuthorityMismatch while the other context remains pending and the settled context retains its own re-establishment eligibility), and proven-destroyed generation witness (ContextNotOwned while the surviving sibling remains pending). All rejection paths require zero adapter I/O, unchanged recovery evidence, retained pre-navigation authority still revoked, and no presentation-epoch consumption; only the current witness may close the download-start liveness boundary. Exact-head hosted verification is running on this SHA; production remains intentionally absent in #317.

[seonghobae]

추가 hostile download-witness 경계를 #318에 반영했습니다. ab19fad897cab876c7076040c53d32ded1d2afff는 (1) 동일 raw session/context 값이 재사용되어도 prior Browser Session incarnation에서 발급된 pending witness의 downloadWillBegin이 current incarnation의 pending navigation을 닫지 못하도록 하고, (2) proven destroy 뒤 동일 raw BrowsingContextId가 새 BrowserContextEpoch으로 재생성되는 ABA 상황에서 destroyed ownership generation의 download witness가 새 navigation을 닫지 못하도록 RED를 추가합니다. 두 경우 모두 AuthorityMismatch, zero adapter I/O, recovery evidence 불변, epoch 미소비를 요구하고 current witness만 download-start liveness boundary를 닫을 수 있습니다. 첫 hosted run에서 repository contracts는 통과했지만 새 파일의 canonical rustfmt delta가 검출되어 CI artifact를 그대로 적용한 ordinary child 5e639171565b0715d928c7b8799b783c21280972로 수리했습니다. 이 exact head의 hosted verification은 새로 실행 중이며 #317 production state machine은 여전히 prerequisite입니다.

[seonghobae]

#318 exact 9808f99ae25939bbd8d27900e02f6864a1428554 repairs CodeRabbit’s remaining Medium hostile-witness gap. Rejected prior-incarnation downloadWillBegin evidence is now followed by an authorized-operation attempt using the current retained second_authority; rejected destroy→recreate ABA evidence is likewise followed by an attempt using the recreated generation’s current retained new_authority. Both must remain AuthorityMismatch/zero-I/O while the current navigation stays pending. The ordinary child delta is test-only (+20 lines, one file); no #317/#316 production source was touched. Exact-head hosted CI was triggered separately and remains required before this slice can claim even contract/format evidence.

[seonghobae]

Acceptance tightened in #318 exact a7f914aaccb89c1a915b0b1b83597d8de8a82189: matching downloadWillBegin consumes the exact Browser Session navigation witness for authority purposes. Delayed complete-positive/navigationAborted/navigationFailed replay of that witness must be non-mutating and fail before adapter I/O. Before explicit re-establishment it must preserve the one download-derived opportunity; after re-establishment it must not revoke the new authority or create another opportunity. This is intentionally narrower than claiming the protocol cannot emit later events: W3C 2026-09-09 await a navigation treats "download started" as one of the events that resumes the navigation waiter, while downloadEnd remains the separate file-download lifecycle. The new RED is navigation_download_start_consumes_witness.rs; pinned-Chromium acceptance should exercise the same late-event condition.

[seonghobae]

새 hostile acceptance를 #318 07c4650bf03952aad509ce6b3b6503d98e73f302에 추가했습니다. downloadWillBegin(A)로 A navigation liveness가 닫혀 explicit re-establishment eligibility가 생겼더라도, 그 authority를 사용하기 전에 같은 live context에서 navigationStarted(B)가 관찰되면 A eligibility는 superseded되어야 합니다. B가 pending인 동안 raw context 기반 re-establishment가 A의 과거 download outcome을 근거로 authority를 발급하면 navigation B를 우회하는 mutation window가 생깁니다. 요구 결과는 AuthorityMismatch/zero-I/O, recovery evidence 불변, old authority 계속 revoked, A witness replay stale, B 자신의 closing outcome 뒤에만 exactly-one re-establishment입니다. 실제 Chromium lane에서도 A navigation → downloadWillBegin(A) → immediate B navigation before re-establishment 순서를 재현해 확인해야 합니다.

[seonghobae]

Acceptance를 한 단계 더 좁혔습니다. Real pinned-Chromium lane에서 navigationStarted(A) → downloadWillBegin(A) → explicit re-establishment 전에 navigationStarted(B) → delayed A load/complete-positive → delayed A navigationAborted → delayed A navigationFailed를 각각 검증해야 합니다. 세 delayed A terminal form은 B pending 동안 authority transition을 만들지 않고, B pending/recovery evidence/revoked retained authority/aggregate epoch sequence를 보존해야 합니다. 이후 B의 own matching liveness/terminal outcome만 exactly-one re-establishment를 허용해야 합니다. Contract repair는 #318 abad63f4f381d4eb1bed9ff59d970caf309664a1, doctoring은 7df2c7c250b17177f523582c8a762a90779a148e입니다.

[seonghobae]

Added a missing cross-context acceptance in #318 exact 548a9b4665f5ef2a905b72170edcde3755475871: downloadWillBegin(A) may leave one unused re-establishment opportunity while sibling context B starts a separate navigation. B's start must not erase A's opportunity or spend an epoch; A may re-establish while B remains pending, B's retained authority stays revoked until B's own closing evidence, and the consumed A download witness remains stale/non-authorizing. This is intentionally the opposite of same-context supersession, where a later navigation on A discards A's unused prior opportunity. Real Chrome acceptance should exercise both cases independently.

[seonghobae]

#318 exact ded30c92fc8987adbc064ebd2fe299a2ae542de9 refines acceptance 7: after downloadWillBegin(A) and sibling navigationStarted(B), each possible late consumed-A replay must be independently non-mutating. Duplicate download-start, complete-positive, Aborted, and Failed now each run from a fresh A-closed/B-pending setup and immediately prove state/recovery/B authority/adapter-I/O/epoch invariance while preserving A's unused re-establishment opportunity. Real Chromium acceptance should likewise observe each delayed event form independently rather than only checking the final state after a sequence.

[seonghobae]

#318 exact a6c26460b89201c8418abafbad510065bfb90ea0에서 download-start replay acceptance를 한 단계 강화했습니다. same-context navigation B가 A의 미사용 download-derived opportunity를 supersede한 뒤, consumed A witness의 duplicate downloadWillBegin 한 건만 들어와도 즉시 non-mutating이어야 합니다. AuthorityMismatch뿐 아니라 B pending 유지, recovery evidence 불변, retained authority 계속 revoked, re-establishment 계속 거절, epoch 미소비, zero-I/O를 그 event 직후 독립적으로 검증합니다. pinned-Chromium acceptance에서도 duplicate download-start를 다른 late terminal event와 묶어 검증하지 말고 별도 fresh setup으로 관찰하는 것이 맞습니다.

[seonghobae]

#318 exact 45200c83a398400001c7c63783448c9ccc326001에 duplicate stale download-start의 epoch non-mutation acceptance를 별도 fresh setup으로 추가했습니다. pinned-Chromium에서도 superseded A의 duplicate downloadWillBegin 한 건만 재생한 뒤 다른 stale terminal event 없이 B/current navigation을 정상 close하고, fresh authority generation이 정확히 다음 epoch 하나만 소비하는지 확인해야 합니다. rejected remote evidence가 내부 epoch allocator를 건드리는 구현도 fail 대상입니다.

[seonghobae]

Acceptance refinement from #318: treat duplicate browsingContext.downloadWillBegin delivery for an already-consumed navigation witness as its own replay case, not only late load/abort/failure. Pinned-Chromium evidence should independently cover (a) duplicate download-start before re-establishment: zero Browser Session I/O, no state/recovery/epoch mutation, retained pre-navigation authority still revoked, original single re-establishment opportunity preserved; and (b) duplicate download-start after re-establishment: rejection remains non-mutating and the freshly minted authority stays usable. #318 commit 1f43bf66543f75bfb367e6faed86407490d6fb87 adds the core RED contract; this does not transfer download persistence/scanning/egress/quarantine ownership into Browser Session.

[seonghobae]

Current #318 exact RED is now aba083723a7a2f048aa2e702736773821c71fc33. The pre-re-establishment duplicate downloadWillBegin replay is isolated in a fresh Browser Session and followed immediately by re-establishment, so no later stale terminal event can compensate for an accidental eligibility/epoch mutation. Focused CodeRabbit review found no additional contract gap in this slice. Real pinned-Chromium acceptance should mirror that isolated ordering before separately exercising the post-re-establishment duplicate-delivery case.