@jsenv/navi 0.29.397 → 0.29.399

package/docs/AI_INSTRUCTIONS.md

@@ -210,8 +210,13 @@ to start when unsure which export solves a problem.
   moving anything with the pointer.
 - `pan_zoom.md` — a surface under the hand: `pan`, `zoom`, and what a touch or
   a wheel over it may do to the page around it.
-- `mobile_tap_suppression_after_drag.md` — Chrome Android drops the click that
-  follows a JS-driven touch drag; refuse `touchmove` while dragging.
+- `mobile_touch.md` — what Chrome and Safari do with a finger a gesture also
+  reads, measured: they commit it to their own pan ~8px in (read a finger's
+  intent before that), `touch-action` restarts at every scroller, when the
+  click survives, the tap Chrome drops after a touch drag, and how to reproduce
+  all of it without a device (Chrome's mobile touch emulator, Safari in the iOS
+  simulator). Read before reading a finger yourself, and before concluding a
+  gesture works because it works with a mouse.
 
 ### Layout, CSS and text
 

package/docs/drag_to_travel.md

@@ -35,9 +35,10 @@ and are referenced from here rather than restated.
 
 ## What the rules are
 
-- A press is not a gesture until it has wandered ~10px, and the axis it leans on
-  then is the axis it walks, for good — how that axis is read, and why the
-  reading is biased, has [a section of its own
+- A press is not a gesture until it has wandered 10px with a mouse, 6px with a
+  finger or a pen, and the axis it leans on then is the axis it walks, for good
+  — how that axis is read, why the reading is biased, and why a finger's number
+  is a deadline rather than a feel, has [a section of its own
   below](#the-axis-is-read-once-and-read-with-a-bias). **Except on something
   already moving**: there the hand said what it wanted by reaching for it, so
   the gesture answers from its first pixel and owes it every one of them —
@@ -89,7 +90,7 @@ and are referenced from here rather than restated.
 ## The axis is read once, and read with a bias
 
 The axis is decided on the first movement report after the threshold and never
-revisited. That report is ~10-25px of movement, and for a thumb those pixels
+revisited. For a thumb that report is a few pixels of movement, and those pixels
 misstate the gesture: a thumb swiping sideways moves along an ARC, and the
 start of the arc leans off-axis far more than the swipe does. Read even
 (whichever axis covered more), the lean hands the whole press to an axis
@@ -109,19 +110,35 @@ Why the decision cannot simply wait for more evidence — this boundary is
 physics, not caution:
 
 - the browser is racing for the same press, on the axis `touch-action` leaves
-  it, and it holds off only while the touchmoves are being refused;
-- refusing a touchmove is **irreversible for that touch**: whether the stream
-  can scroll is decided at its first refusable move, and un-refusing later
-  resurrects nothing;
-- so every frame spent gathering evidence is a frame of the page's scroll
-  spent, for good. A decision deferred until the arc has proven itself would
-  make every genuinely vertical swipe over the box a dead gesture — the exact
-  bug, mirrored onto the page.
+  it — and on every axis over a scroller inside the box, since a scroller
+  resets `touch-action` for what it holds;
+- and it does not wait for us: **about 8px in, it commits the touch to its own
+  pan**, reading the direction evenly (Chrome at the first `touchmove` it
+  sends, Safari at the one near 9px). From then on refusing a `touchmove`
+  changes nothing: the pointer is cancelled, and the swipe does nothing — or
+  the travel that had started goes back;
+- refusing a touchmove is **irreversible for that touch** too, the other way
+  round: one refused before that moment keeps the whole touch from scrolling,
+  and un-refusing later resurrects nothing;
+- so the reading has to be done before the browser's, and every frame spent
+  gathering evidence past it is not evidence, it is a lost gesture. A decision
+  deferred until the arc has proven itself would make every genuinely vertical
+  swipe over the box a dead gesture — the exact bug, mirrored onto the page.
+
+Hence the finger's threshold, 6px of distance (`DRAG_START_THRESHOLD_TOUCH`):
+under the browser's 8px with a margin, because Safari does not wait for the
+answer to a report that jumps over its decision. A distance and not a per-axis
+reach, because the browser measures its own slop as one. Its price is the
+click of a tap that shook more than 6px. The engines' side of all this —
+measured, per engine, with how to reproduce it — is
+[mobile_touch.md](./mobile_touch.md).
 
 The bias moves the frame-one boundary to where the two hands actually
-separate; nothing can remove the boundary. A first report steeper than the
-bias (a start more than twice off-axis) is genuinely ambiguous with a scroll
-and goes to the page — which at least answers it visibly.
+separate; nothing can remove the boundary. It only works because it is read
+first: read after the browser's own reading, it is never consulted, the
+pointer already being cancelled. A first report steeper than the bias (a start
+more than twice off-axis) is genuinely ambiguous with a scroll and goes to the
+page — which at least answers it visibly.
 
 ## Two inputs, one travel
 
@@ -553,8 +570,15 @@ travel had started finishes without anyone. It is invisible with a mouse, which
 is why it survives a whole session of desktop testing.
 
 So a travel that has become ours refuses the `touchmove` (`preventDefault`), and
-only then — a finger that means to scroll must still scroll. Three details make
-it hold:
+only then — a finger that means to scroll must still scroll. "Only then" has a
+deadline: the browser takes the touch about 8px in if nothing has refused it by
+then, which is why a finger becomes a travel at 6px (see [the axis
+section](#the-axis-is-read-once-and-read-with-a-bias)). `touch-action` on the
+box does not cover for a late answer over content that scrolls: a scroller
+inside the box resets it for what it holds, and Chrome then pans even the axis
+the box travels on, with nothing to scroll that way (see
+[mobile_touch.md](./mobile_touch.md#touch-action-stops-at-the-first-scroller)).
+Three details make the refusal hold:
 
 - the listener sits on the element the touch LANDED on as well as on the window: a
   touch keeps being dispatched at the node it started on, and a travel may
@@ -728,9 +752,16 @@ The reading side has traps of its own:
   measured velocities come out below the numbers written in the script — read
   the measured ones, not the intended ones;
 - what the real browser does with an unclaimed touch — take it for a pan and
-  cancel the stream, kill a momentum tail the moment a finger lands — does not
-  exist in emulation at all. Claims about it are only ever settled on a
-  device (and the Firefox wheel limitation above is the same kind of fact).
+  cancel the stream, withhold the click — is reproducible without a device, but
+  only through two paths: Chrome's mobile touch emulator (headed, driven with
+  mouse events) and Safari in the iOS simulator driven by `safaridriver`. The
+  obvious one, Playwright's `touchscreen` / CDP `Input.dispatchTouchEvent`,
+  runs Chrome's desktop slop (15px), where a travel deciding at 10px always
+  wins and the race that loses swipes on a phone never shows. The recipe is in
+  [mobile_touch.md](./mobile_touch.md#verifying-without-a-device). What stays a
+  device question: a real finger's lift, a real device's event timing, a
+  momentum tail killed by a landing finger (and the Firefox wheel limitation
+  above is the same kind of fact).
 
 What to read while it runs: the `navi_drag_*` events (grab, start, release)
 say which stage a press reached and with what velocity; the box's state

package/docs/dynamic_import.md

@@ -146,8 +146,9 @@ by the code arriving.
 `prefetch={false}` opts one out. The url is matched against the routes on
 screen, a section and the page inside it alike, and what is prerun is **every
 route action that asks nothing of the address** — a page's code, a read
-without params. An action whose params come from the address is never
-prefetched: a prefetch has no address, the id may still be chosen.
+without params. An action whose params come from the address is not
+prefetched by a link: a link's prefetch has no address, the id may still be
+chosen.
 `routeAction(route, action, undefined, { prefetch: false })` keeps a
 param-less read that is not worth a hover out of it.
 

package/docs/mobile_touch.md

@@ -0,0 +1,224 @@
+# What a mobile browser does with a touch
+
+A finger on a touchscreen is read twice. The page reads it through pointer and
+touch events. The browser reads it too, because it wants it for its own
+answers: a pan (scrolling, the back swipe), a zoom, and a tap (the click). Any
+gesture navi reads from a finger — a travel, a swipe, something carried, a
+wheel spun — is a negotiation with those answers. The browser's terms are
+fixed, they differ between engines, and **none of them shows with a mouse**. A
+gesture can pass a whole session of desktop testing and still fail one swipe
+in three on a phone.
+
+What follows is measured, not remembered: Chromium 153 through its mobile touch
+emulator, and Safari on the iOS 26.5 simulator driven with real touches (see
+[Verifying without a device](#verifying-without-a-device)). When an engine
+changes, measure again before trusting a number here.
+
+- [The browser decides about 8px in, and does not wait](#the-browser-decides-about-8px-in-and-does-not-wait)
+- [touch-action stops at the first scroller](#touch-action-stops-at-the-first-scroller)
+- [Only the start is contested](#only-the-start-is-contested)
+- [The click is the browser's call as much as ours](#the-click-is-the-browsers-call-as-much-as-ours)
+- [A tap dropped after a touch drag](#a-tap-dropped-after-a-touch-drag)
+- [A finger never makes a wheel event](#a-finger-never-makes-a-wheel-event)
+- [Verifying without a device](#verifying-without-a-device)
+
+## The browser decides about 8px in, and does not wait
+
+Where the browser may pan — the direction is allowed by `touch-action` — it
+**commits the touch to its own pan after about 8px of movement**. From then on,
+refusing a `touchmove` changes nothing. The pointer stream gets a
+`pointercancel`, and the gesture the page was reading is dead: the swipe does
+nothing, or a travel that had already started goes back.
+
+The two engines reach that moment differently:
+
+- **Chrome** does not send a `touchmove` inside its slop: 8px with the mobile
+  configuration, 15px on a desktop touchscreen. It still sends the
+  `pointermove`s. The first `touchmove` it sends IS its decision. Refuse that
+  one, and the page keeps the whole touch: no scroll for its whole length, and
+  every later `touchmove` stays cancelable. Leave it alone, and Chrome pans if
+  `touch-action` allows the direction. Chrome reads that direction evenly: a
+  start with `|dy| ≥ |dx|` is vertical. From then on every `touchmove` arrives
+  `cancelable: false`.
+- **Safari** sends `touchmove`s from the first pixel, all cancelable. Refusing
+  them from any point before about 9px keeps the whole touch for the page, and
+  so does refusing the first one alone: native scrolling never starts, even
+  when the later ones are left alone. If the one at about 9px goes unrefused,
+  Safari pans. It does not wait for the page's
+  answer to a report that jumps over that distance in one go: after a small
+  unrefused report, a report that jumps past 9px is already too late.
+
+So **a gesture that shares a surface with the page's pan has to read its
+intent before about 8px**, and measure it as a distance (`Math.hypot`), not per
+axis: the browser measures its slop as a distance, and a per-axis threshold is
+up to 1.4 times later on a diagonal. Waiting for more evidence is not
+available, because whatever is read after the browser's moment is read about
+a pointer that has already been cancelled. The travel reads a finger's intent
+at 6px for exactly this reason (`DRAG_START_THRESHOLD_TOUCH` in
+`@jsenv/dom`'s `drag_to_travel.js`). Its bias toward the box's own axis only
+means something because it is read before the browser reads the same pixels
+evenly.
+
+Whether a `touchmove` can be refused at all is settled even earlier, when the
+finger lands: a non-passive listener must already be on the touch's path (see
+`keepTouchRefusable`, and
+[drag_to_travel.md](./drag_to_travel.md#on-a-touchscreen-the-browser-takes-the-gesture-unless-it-is-refused)).
+Being refusable is decided at the touchstart; being refused, before 8px.
+
+## touch-action stops at the first scroller
+
+The `touch-action` in effect under a finger is the intersection of the values
+from the touched element up to its **nearest scroll container** (an element
+with `overflow: auto | scroll`). At that container it starts again from `auto`.
+That is the Pointer Events spec, and Blink and WebKit both do it. So
+`touch-action: pan-y` on a box that travels sideways says nothing about a slide
+inside it with `overflow="auto"`, nor about a `List` or a scrolling body: under
+the finger there, every direction is open again.
+
+The engines do not use that opening the same way:
+
+- **Chrome** pans in any direction there, **even one in which nothing can
+  scroll**, and cancels the pointer. A sideways swipe over a slide that only
+  scrolls vertically is taken by Chrome for a sideways pan of nothing.
+- **Safari** does not pan a scroller sideways when it cannot scroll sideways:
+  the same swipe stays the page's.
+
+So `touch-action` on a box is not what protects a gesture over content that
+scrolls; reading the intent before the browser does is. It covers this case
+with no rule on the scrollers — which matters, because restating the box's
+`touch-action` on them would take the finger scroll away from a row that
+scrolls sideways inside a slide.
+
+## Only the start is contested
+
+Once the browser has let a touch go, a later change of direction does not bring
+it back:
+
+- On Chrome, a start that its even reading calls horizontal, over `pan-y`,
+  drops Chrome's scroll for the whole touch. The thumb can bend vertical halfway
+  through and nothing scrolls, whether or not the later `touchmove`s are
+  refused.
+- On Safari, once a `touchmove` has been refused, a later vertical bend starts
+  no native scroll either.
+
+A gesture that has won the start keeps the touch. What loses gestures is the
+first ~8px.
+
+## The click is the browser's call as much as ours
+
+- **Chrome** clicks after a touch that moved up to 8px and never beyond, whether
+  or not its `touchmove`s were refused.
+- **Safari** does not click at all once a `touchmove` has been refused, even
+  after 6px. A touch that was never refused still clicks: an unrefused sideways
+  movement over `pan-y` clicks even after 20px.
+
+A gesture that reads its intent early therefore costs the click of a tap that
+shook more than its threshold. Safari drops that click on its own, and on
+Chrome the gesture's click suppression swallows it up to 8px. That is the price
+of the deadline above, paid by the sloppiest taps only. Beyond the browser's
+own slop there was never a click to lose.
+
+## A tap dropped after a touch drag
+
+On Chrome for Android, the tap that follows a finger-driven drag does not fire
+its `click` when it comes quickly: `pointerdown` and `pointerup` arrive, the
+synthesized `click` (and the `mousedown`/`mouseup` compat events) does not. Wait
+about half a second and the same tap works. It is what makes a wheel feel
+broken — spin it, tap "Définir" at once, and the command never runs.
+
+It is the browser's, not ours: a bare `div` moved by hand under `pointermove`,
+with no framework, reproduces it. An un-prevented touch drag feeds Chromium's
+gesture recognizer, which then treats the next tap as not clean enough to be a
+click. `touch-action` changes nothing (`none`, `manipulation`, `pan-y` all drop
+it), `preventDefault()` on the pointer events changes nothing either — only
+`preventDefault()` on the **touch** events, `touchstart` or `touchmove`, keeps
+the following click alive. A native scroll owned by the browser leaves it alive
+too, which is no help to a surface moved by JS.
+
+So a surface that moves under a finger by JS refuses `touchmove` while a drag is
+active, from a non-passive listener. `touchmove` rather than `touchstart`: the
+move is the event whose default the drag actually owns, and preventing
+`touchstart` also suppresses the surface's own focus and synthesized events.
+
+```js
+const onTouchMove = (e) => {
+  if (drag) {
+    e.preventDefault();
+  }
+};
+viewport.addEventListener("touchmove", onTouchMove, { passive: false });
+```
+
+Two theories were tried first and disproven on the device, so they are not
+worth trying again: pointer capture on touch, and a momentum re-render moving
+the element under the tap.
+
+Reference: `onTouchMove` in `src/control/wheel/wheel.jsx`; the reductions, one
+variable per row, in `src/control/demos/lab/` (`tap_after_drag_experiment.html`,
+`surface_css_matrix_experiment.html`, `preventdefault_matrix_experiment.html`);
+Chromium's `gesture_provider.cc` (`ignore_single_tap_`, reset on the next down)
+and `tap_suppression_controller.cc` (the tap that stops a fling, 180ms) for the
+two mechanisms that do NOT explain it.
+
+## A finger never makes a wheel event
+
+No mobile browser turns a touch into `wheel` events: those come from a mouse
+wheel or a trackpad, including a trackpad on an iPad. When a gesture works with
+the wheel and fails under a finger, the wheel path is not the suspect. The two
+paths differ in timing: a wheel gesture is claimed and refused on its very first
+event, so the browser never gets a moment to decide, while a finger has to
+travel a few pixels before anything can be read.
+
+## Verifying without a device
+
+Both engines can show the browser's own answers — the pan, the
+`pointercancel`, the click withheld — without a phone. Only through the paths
+below, though: the obvious ones hide the race.
+
+**Chrome**: drive DevTools' touch emulator, which goes through Chrome's
+gesture detector with the **mobile** configuration (8px slop):
+
+- a headed Chromium (`chromium.launch({ headless: false })`) — headless
+  delivers nothing through this path;
+- on a CDP session, `Emulation.setEmitTouchEventsForMouse({ enabled: true,
+configuration: "mobile" })`, then `Input.dispatchMouseEvent` with
+  `mousePressed` / `mouseMoved` / `mouseReleased` (`buttons: 1` while down). The
+  page receives real touches and pointer events of type `touch`;
+- those calls are **never acknowledged**: send them without awaiting, with a
+  sleep between moves (~16ms is a frame).
+
+`Input.dispatchTouchEvent` — what Playwright's `touchscreen` uses — goes
+through the desktop configuration instead: a 15px slop. Anything deciding at
+10px wins there, and the race that loses swipes on a phone is invisible.
+
+**Safari**: the iOS simulator, driven by `safaridriver`, which turns W3C touch
+actions into real UIKit touches — Safari's own pan recognizers compete for
+them exactly as on a phone:
+
+- boot a simulator (`xcrun simctl boot <udid>`), start `safaridriver -p 4444`,
+  and create a session with
+  `{ platformName: "iOS", "safari:useSimulator": true, "safari:deviceUDID": "<udid>" }`;
+- a pointer action source with `parameters: { pointerType: "touch" }`: a
+  `pointerMove` with `origin: "viewport"`, a `pointerDown`, one `pointerMove`
+  per frame (`duration: 16`), a `pointerUp` — then `DELETE /session/<id>/actions`,
+  without which the `pointerup`, `touchend` and click are never delivered;
+- **a native scroll hangs the actions call**, and every call after it. Treat the
+  hang as the observation — "Safari took the touch" — put a timeout on every
+  call, then recover with `xcrun simctl terminate <udid> com.apple.mobilesafari`
+  and a restarted `safaridriver`. The page's `localStorage` does not survive
+  that, so whatever must be read is read before the swipe.
+
+What to synthesize is the hand's imperfection, as
+[drag_to_travel.md](./drag_to_travel.md#verifying-a-gesture) says: a slow start
+landing a report between 6 and 9px, steep first pixels, a report that jumps. What
+to read: the `touchmove`s with `cancelable` and `defaultPrevented`, the
+`pointercancel`, `scrollY`, and what the gesture itself says (for a travel,
+`data-drag-travel-walking` on `:root` and the slide that ends up current).
+
+What neither path shows: the lift of a real finger (the last reports before
+`pointerup`), a real device's event timing (the order in which the browser's
+cancel and the next report reach the page), a momentum tail killed by a landing
+finger. Those remain device questions.
+
+Reference: `src/layout/demos/lab/slide_container_touch_race.html` — a row of
+slides that do not scroll and a row that do, for the two cases above.

package/docs/pan_zoom.md

@@ -44,7 +44,7 @@ for); the pinch not beginning as a pan under its first finger; the wheel and the
 pinch writing one `zoom`; the capture, the pointer the browser drops, the click
 the release leaves behind, and the next tap's click, which Chrome on Android
 drops after a touch drag whose `touchmove`s nobody refused (see
-[mobile_tap_suppression_after_drag.md](./mobile_tap_suppression_after_drag.md)).
+[mobile_touch.md](./mobile_touch.md#a-tap-dropped-after-a-touch-drag)).
 A pointer pans only once it has travelled a few px (`data-drag-threshold`), so a
 tap stays a tap: a `longpress` declared beside `pan` still gets its hold, and a
 `double_click` still gets its two presses. A press that does pan is the

package/docs/popup_open.md

@@ -320,6 +320,12 @@ So a dialog whose content is seeded once — an uncontrolled field on a
 first render. Learning it afterwards would mean mounting on the previous subject
 and correcting it, which is a flicker at best and stale fields at worst.
 
+One opening does not follow that order: a `mount="while-opened"` popup pressed on
+its own `anchor` (a picker's trigger, an expandable's UI part) has its content
+built by the press, ahead of the click (see
+[what the popup holds while it is closed](#what-the-popup-holds-while-it-is-closed)). A popup opened ON something is
+opened by a command pressed elsewhere, and keeps the order above.
+
 The two other places one could listen are not that moment, and it is worth
 knowing why:
 
@@ -1008,7 +1014,8 @@ slots".
 Being open is where the user is, and what a popup draws belongs to the screen
 exactly the way a page's own data does. So a popup that loads something binds
 its open state (above) and asks for its data with a `routeAction` whose params
-are `false` while it is closed:
+are `false` while it is closed — and its content reads the question itself,
+without the part that says whether it is open:
 
 ```js
 const groupSheetOpenSignal = stateSignal(false, {
@@ -1016,12 +1023,17 @@ const groupSheetOpenSignal = stateSignal(false, {
   type: "boolean",
 });
 
+// asked while the sheet is open
 export const GROUP_MEMBERS = routeAction(GAME_ROUTE, USER.GET_MANY, () => {
   if (!groupSheetOpenSignal.value) {
     return false;
   }
   return { group: groupSignal.value };
 });
+// read by the sheet, open or closed
+export const GROUP_MEMBERS_SHOWN = USER.GET_MANY.bindParams({
+  group: groupSignal,
+});
 ```
 
 ```jsx
@@ -1030,15 +1042,16 @@ export const GROUP_MEMBERS = routeAction(GAME_ROUTE, USER.GET_MANY, () => {
 </Dialog>;
 
 const GroupMembers = () => {
-  const [members] = useAsyncData(GROUP_MEMBERS); // reads, never runs
+  const [members] = useAsyncData(GROUP_MEMBERS_SHOWN); // reads, never runs
   …
 };
 ```
 
 The same shape when the popup is one of many — a sheet on every card, opened
 from wherever the card is read. Its open state then says which one, and the
-route action reads the id straight from it. Declared on the root route, since a
-card is not a page:
+route action reads the id straight from it, while each card's content reads the
+question of its own card. Declared on the root route, since a card is not a
+page:
 
 ```js
 const seatSheetSignal = stateSignal(undefined, {
@@ -1048,18 +1061,39 @@ const seatSheetSignal = stateSignal(undefined, {
 });
 const ANY_PAGE = route("/", { searchParams: { seat: seatSheetSignal } });
 
+export const seatableUsersOf = (gameId) => ({ game: gameId });
 export const SEATABLE_USERS = routeAction(ANY_PAGE, USER.GET_MANY, () => {
   const gameId = seatSheetSignal.value;
-  return gameId ? { game: gameId } : false;
+  return gameId ? seatableUsersOf(gameId) : false;
 });
 ```
 
 ```jsx
 <Dialog signal={seatSheetSignal} value={game.id}>
-  <SeatableUsers />
-</Dialog>
+  <SeatableUsers gameId={game.id} />
+</Dialog>;
+
+const SeatableUsers = ({ gameId }) => {
+  const [users] = useAsyncData(
+    USER.GET_MANY.bindParams(seatableUsersOf(gameId)),
+  );
+  …
+};
 ```
 
+**The content reads its question, never the route action.** The route action's
+params are `false` while the popup is closed, and for the route action that is
+right: it says _when_ to ask. Read by the content, the same `false` says there
+is nothing to show — `useAsyncData` hands back `undefined` the moment the popup
+closes, the list empties while hidden, and the next opening builds it again from
+the top: the scroll position is lost, and every row is rendered once more for an
+answer that never left the store. When the popup is one of many, it is worse: the
+route action follows whichever popup is open, so a card's sheet kept mounted
+since an earlier opening redraws with another card's rows each time that one
+opens. Closing a popup does not change what it is about, so what it reads leaves
+the open state out. Equal params share one instance — the content reads the very
+one the route action runs, so nothing is asked twice and nothing is copied.
+
 **A popup that waits holds its own `<Loading>`**, like every other part of a
 screen that can wait — it is not built into `Dialog`/`Popover`, because only the
 code inside knows whether anything in there loads at all:
@@ -1116,7 +1150,8 @@ become a popup's private request — asked for late, and asked for alone.
 
 A closed popup builds nothing: `children` are mounted on the first open, and
 stay mounted afterwards — a reopened popup finds its scroll position and its
-half-typed form where it left them.
+half-typed form where it left them, as long as the data it draws does not leave
+with the close (see [A popup that loads data](#a-popup-that-loads-data)).
 
 "Closed" is two states, not one — never opened yet, and closed again after an
 opening — so the `mount` prop answers both at once:
@@ -1134,7 +1169,9 @@ off it, fields a surrounding form submits, a size measured from outside.
 
 Whatever the value but `"while-opened"`, intent on the anchor — a pointer
 entering it, focus landing in it — builds the content ahead of the click that
-will open it.
+will open it. A `"while-opened"` popup is warmed by a press on its anchor only,
+and a press that ends without opening it — a scroll, a drag, a release
+elsewhere — throws the content away: there is still one content at a time.
 
 `"while-opened"` is what an uncontrolled field seeded from a `defaultValue`
 needs: without it, a popup reopened after the underlying value changed still

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.397",
+  "version": "0.29.399",
   "type": "module",
   "description": "Library of components including navigation to create frontend applications",
   "repository": {
@@ -34,7 +34,7 @@
     "preact": "^11.0.0-rc.2"
   },
   "dependencies": {
-    "@jsenv/dom": "0.17.74",
+    "@jsenv/dom": "0.17.75",
     "@jsenv/humanize": "1.8.5",
     "@jsenv/validity": "0.4.5"
   },

package/docs/mobile_tap_suppression_after_drag.md

@@ -1,41 +0,0 @@
-# A tap dropped after a touch drag
-
-On Chrome for Android, the tap that follows a finger-driven drag does not fire
-its `click` when it comes quickly: `pointerdown` and `pointerup` arrive, the
-synthesized `click` (and the `mousedown`/`mouseup` compat events) does not. Wait
-about half a second and the same tap works. It is what makes a wheel feel
-broken — spin it, tap "Définir" at once, and the command never runs.
-
-It is the browser's, not ours: a bare `div` moved by hand under `pointermove`,
-with no framework, reproduces it. An un-prevented touch drag feeds Chromium's
-gesture recognizer, which then treats the next tap as not clean enough to be a
-click. `touch-action` changes nothing (`none`, `manipulation`, `pan-y` all drop
-it), `preventDefault()` on the pointer events changes nothing either — only
-`preventDefault()` on the **touch** events, `touchstart` or `touchmove`, keeps
-the following click alive. A native scroll owned by the browser leaves it alive
-too, which is no help to a surface moved by JS.
-
-So a surface that moves under a finger by JS refuses `touchmove` while a drag is
-active, from a non-passive listener. `touchmove` rather than `touchstart`: the
-move is the event whose default the drag actually owns, and preventing
-`touchstart` also suppresses the surface's own focus and synthesized events.
-
-```js
-const onTouchMove = (e) => {
-  if (drag) {
-    e.preventDefault();
-  }
-};
-viewport.addEventListener("touchmove", onTouchMove, { passive: false });
-```
-
-Two theories were tried first and disproven on the device, so they are not
-worth trying again: pointer capture on touch, and a momentum re-render moving
-the element under the tap.
-
-Reference: `onTouchMove` in `src/control/wheel/wheel.jsx`; the reductions, one
-variable per row, in `src/control/demos/lab/` (`tap_after_drag_experiment.html`,
-`surface_css_matrix_experiment.html`, `preventdefault_matrix_experiment.html`);
-Chromium's `gesture_provider.cc` (`ignore_single_tap_`, reset on the next down)
-and `tap_suppression_controller.cc` (the tap that stops a fling, 180ms) for the
-two mechanisms that do NOT explain it.