The date popover's reopen: a frame no screenshot can hold

Both builds settle on page one. Only one of them paints page two first — measured in a real browser, three runs each.

3 Sept 2026 · branch gera/datepicker-reset-on-close · captured against propflow-stage · at 621a7290c8

Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.

1 · Before — reopened, after a page-two dismissal

Open the date filter, go to Specific months, dismiss, reopen. This is the settled state on origin/main: page one, the quick ranges. Which is the right destination — the reset works. The defect is how it gets there.

Asserted in the captured DOM — Specific months. Asserted in the state the screenshot shows: after the reopen, page one is what is mounted.

Before — reopened, after a page-two dismissal

origin/main — settled on page one Provenance. Captured from commit c65ff89a94, read from the worktree the server was started from (/Users/miniclaw/code/PropFlow/wt-strip-descriptor) — the server could not report its own commit, so this is the weaker of the two sources. That commit is already merged into origin/main.

2 · After — the same gesture, the same destination

Identical. That is the point of putting the two side by side — the change is not visible in a still, because the difference is one frame wide. A screenshot is the wrong instrument for this claim, so the claim is settled below with the right one.

Asserted in the captured DOM — Specific months

After — the same gesture, the same destination

gera/datepicker-reset-on-close — settled on page one

The measurement — two instruments, three runs each

A MutationObserver armed across the reopen counts how many times the month-range group is added to the DOM (a commit). A requestAnimationFrame sampler records whether any frame observed it present (a paint opportunity). Chromium, 1440×1000, /leasing/prospects.

  build                     MOUNTS   frames-with-page-two   settled
  ----------------------------------------------------------------
  origin/main   run 1          1              1              page 1
  origin/main   run 2          1              1              page 1
  origin/main   run 3          1              1              page 1
  branch        run 1          0              0              page 1
  branch        run 2          0              0              page 1
  branch        run 3          0              0              page 1

  main   frame samples:  0001000000000000000000000000000000000000
  branch frame samples:  0000000000000000000000000000000000000000

On main the reopen mounts page two, one sampled frame sees it, and the passive effect then replaces it. On the branch it is never mounted at all. Both settle on page one, which is why the screenshots above are identical.

Why jsdom could not do this, and why that is not an excuse. Under act, React flushes the render and its passive effect into a single DOM commit — the intermediate state has no representation, so the same MutationObserver case written as a unit test passes on the broken implementation (verified by mutation). A real browser can paint before the Scheduler macrotask that runs a passive effect, which is exactly the gap the fix closes and exactly why the measurement had to move to a browser. The test file says so rather than implying coverage it does not have.