frontend-patterns/research/experiments/boundary-recovery/routing-design.md
tegwick 29ccad7002 Test lifecycle-aware Escape ownership routing without settling delays
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-26 22:58:07 +02:00

1.8 KiB

Experimental Escape routing

This is a synthetic alternative for one pinned Radix module, implemented through an in-memory bundle transform. It is not an upstream patch, supported API or deployment. The existing isolation experiment remains unchanged.

Proposed contract:

  1. Register a connected dialog owner during layout, before ordinary user interaction.
  2. Keep one capture listener per document. On Escape, snapshot one current owner.
  3. Invoke that owner's callback once; honor cancellation without falling through to its parent. Invoke dismissal only if the callback has not prevented it.
  4. Remove ownership during layout cleanup; disconnecting the final owner removes the document listener. Ignore detached nodes when selecting an owner.
  5. Keep focus restoration separate: a removed invoker still needs an application target, and asynchronous focus restoration has its own lifecycle.

The registry currently uses mount insertion order, which is a limited proxy for ownership in the tested two-level nesting. It does not model arbitrary z-order, multiple library copies, nested documents, shadow DOM or animation-preserved exiting layers. A controlled dialog can reject a dismissal; this router does not mark it closed merely because a callback ran. Rapid repeats, same-turn bursts and competing non-dialog Escape handlers require separate contracts and testing.

The six scenarios are ordinary close, immediate nested close, cancelled inner close, removed invoker with an application target, programmatic inner removal then reopen, and ancestor teardown followed by Escape. Each runs once per browser/build/variant: Chromium/Firefox, development/production, original behavior/experimental router. There are no sleeps, private-readiness waits or automatic retries. This is a mechanism comparison, not an estimate of occurrence rates or proof of a general repair.