@cplieger/web-terminal-ui 5.4.1 → 5.4.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cplieger/web-terminal-ui",
-  "version": "5.4.1",
+  "version": "5.4.3",
   "type": "module",
   "description": "Reference touch-first browser UI for @cplieger/web-terminal-engine: a composable kernel + feature modules (tabs, activity monitor, mobile toolbar, context menu, IME, predictive echo, viewport handling) and CSS. One createTerminal() call.",
   "license": "MPL-2.0",

package/src/features/tabs/index.ts

@@ -43,9 +43,9 @@ import {
 } from "./model.js";
 import { browserNotifierEnv, createNotifier } from "./notify.js";
 import {
-  REORDER_LEAN_PX,
   REORDER_MOVE_EPS_PX,
   REORDER_REST_MS,
+  REORDER_STILL_MS,
   REORDER_SETTLE_MS,
   REORDER_SHIFT_TRANS,
   REORDER_SLOT_FADE_MS,
@@ -667,10 +667,9 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
       let activeId: string | null = null;
       let draggingEl: HTMLElement | null = null;
       // --- Desktop reorder preview state (mechanism below, near dragTargetBefore) ---
-      // The chips currently carrying an inline transform: the lean during a hold,
-      // or the slide that commits it. One set, because both stages write the same
-      // two properties on the same elements and one settle function has to be able
-      // to hand every one of them back to the stylesheet.
+      // The chips currently carrying an inline displacement from the commit slide.
+      // A set plus one settle function, so whatever a slide wrote can always be handed
+      // back to the stylesheet — including when a second drag interrupts the first.
       const shifted = new Set<HTMLElement>();
       let shiftTimer: ReturnType<typeof setTimeout> | null = null;
       // The slot waiting to open and the rest window that will open it.
@@ -681,6 +680,9 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
       let restTimer: ReturnType<typeof setTimeout> | null = null;
       let restBefore: HTMLElement | null = null;
       let restX: number | null = null;
+      // When the pointer last actually MOVED. A stationary dragover this long after it
+      // is believed as a stop (see trackRest).
+      let restMovedAt = 0;
       // Whether a `drop` fired for the drag in flight. It is the exact signal for
       // "the user released deliberately" as opposed to "the drag was abandoned":
       // Escape and a refused release fire dragend with no drop at all. dragend
@@ -1833,33 +1835,30 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
       // in. The chip you were dragging looked like the slot it left, the slot it
       // was over, and the slot it would end up in.
       //
-      // The preview splits that into two different answers for two different
-      // actions, and the dragged chip stays in the flow throughout as the slot it
-      // will land in (`.wt-tab-dragging`, which 30-tabs.css renders as an empty
-      // dashed outline rather than a dimmed copy of the tab — the solid copy is
-      // the drag image under the pointer, and one of the two had to stop
-      // pretending to be the tab):
+      // The preview answers a MOVING pointer and a STOPPED one differently, and the
+      // dragged chip stays in the flow throughout as the slot it will land in
+      // (`.wt-tab-dragging`, which 30-tabs.css renders as an empty dashed outline
+      // rather than a dimmed copy of the tab — the solid copy is the drag image
+      // under the pointer, and one of the two had to stop pretending to be the tab):
       //
-      //  - SWEEPING across the strip only LEANS the chips a commit would displace,
-      //    a few px toward where they would go (leanToward). Instant, and it is
-      //    what says where the tab will fall while you are still looking for the
-      //    spot. Nothing is rearranged, so crossing five tabs does not reshuffle
-      //    the strip five times.
-      //  - COMING TO REST opens the slot for real (trackRest -> commitSlot): one
-      //    DOM move, the displaced chips slide from their old positions to their
-      //    new ones, and the slot fades in at its new home.
+      //  - SWEEPING across the strip rearranges NOTHING. Crossing five tabs used to
+      //    move all five, which is the whole complaint.
+      //  - COMING TO REST opens the slot (trackRest -> commitSlot): one DOM move,
+      //    the displaced chips slide from their old positions to their new ones, and
+      //    the slot fades in at its new home.
       //
-      // Rest is DETECTED, not waited out: REORDER_REST_MS is re-armed by movement,
-      // so it expires a rest window after the last movement rather than a fixed
-      // time after a decision. An earlier version made every commit serve a fixed
-      // hold, which is the wrong shape for a direct manipulation — it delayed the
-      // one case that should be instant (you found the spot and stopped) to
-      // protect a case the lean already covers (you are still moving). It also
-      // grew a progress bar to explain the wait, which is the tell that the wait
-      // should not have been there.
+      // Rest is DETECTED, not waited out: REORDER_REST_MS is re-armed by movement, so
+      // it expires a rest window after the last MOVEMENT rather than a fixed time
+      // after a decision. Two shapes were tried and removed before this one, and both
+      // failures are worth keeping: a fixed one-second HOLD (wrong shape for a direct
+      // manipulation — it delayed the one case that should be instant, and grew a
+      // progress bar to explain the wait, which is the tell that the wait should not
+      // have been there), and a sweep-time LEAN of the chips a commit would displace
+      // (it read as a second, competing preview and its distance from the real move
+      // was too small to tell them apart).
       //
       // A release never waits either: `drop` commits whatever slot is pending
-      // (flushRest), so dropping mid-sweep lands the tab where the lean said.
+      // (flushRest), so dropping mid-sweep still lands the tab where it was headed.
       //
       // dropTargetBefore returns the first tab whose horizontal midpoint is past
       // x (the element the dragged tab should sit before), or null to drop at the
@@ -1869,8 +1868,8 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
       //
       // It hit-tests LAYOUT geometry (offsetLeft/offsetWidth), never
       // getBoundingClientRect. That is not an optimisation, it is what makes an
-      // animated reorder hit-testable at all: a rect read while a chip is mid-lean or
-      // mid-slide returns the INTERPOLATED position, so the preview's own motion feeds
+      // animated reorder hit-testable at all: a rect read while a chip is mid-slide
+      // returns the INTERPOLATED position, so the preview's own motion feeds
       // back into the decision that produced it and the strip oscillates between two
       // slots for as long as the pointer sits near a boundary. Layout offsets are the
       // chip's position in the FLOW, which a transform does not affect at all.
@@ -1942,87 +1941,25 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
         shifted.clear();
       }
 
-      // leanToward tips the chips a commit would displace a few px toward their
-      // destination, for as long as the pointer is still choosing. No settle timer: the
-      // lean is a held state, not an animation with an end, and a timer that expired
-      // under it would snap it away mid-sweep.
+      // trackRest is the whole gate, called on every dragover over the strip.
       //
-      // This is the SWEEP preview and it is the only thing a moving pointer produces:
-      // it says where the tab will fall without rearranging anything, which is what lets
-      // a drag cross five tabs without the strip reshuffling five times.
+      // Sweeping and settling are DIFFERENT actions and get different answers. A
+      // travelling pointer rearranges nothing at all; the moment it comes to REST the
+      // slot opens.
       //
-      // Chips that were leaning and no longer would be are written back to zero in
-      // the SAME pass, so a changed candidate eases from one lean into the other
-      // rather than snapping through rest first.
-      function leanToward(before: HTMLElement | null): void {
-        if (!draggingEl) {
-          return;
-        }
-        // The preference is read live, so it can flip mid-gesture. Clearing here rather
-        // than returning bare is what honours a mid-hold opt-in: a bare return would
-        // leave the lean already applied under the previous preference sitting there.
-        if (prefersReduce()) {
-          endShift();
-          return;
-        }
-        const chips = [...scroller.querySelectorAll<HTMLElement>(".wt-tab")];
-        const from = chips.indexOf(draggingEl);
-        const to = before === null ? chips.length : chips.indexOf(before);
-        if (from < 0 || to < 0) {
-          return;
-        }
-        // Moving right past the chips in between shifts them LEFT, and moving left
-        // shifts the chips it displaces RIGHT — the direction the user reads as
-        // "that tab is getting out of the way".
-        const movers = from < to ? chips.slice(from + 1, to) : chips.slice(to, from);
-        const dx = from < to ? -REORDER_LEAN_PX : REORDER_LEAN_PX;
-        const next = new Map<HTMLElement, number>();
-        for (const el of movers) {
-          next.set(el, dx);
-        }
-        for (const el of shifted) {
-          if (!next.has(el)) {
-            next.set(el, 0);
-          }
-        }
-        applyShift(next, REORDER_SHIFT_TRANS);
-      }
-      // releaseLean eases every leaning chip back to rest and settles it, for when
-      // a candidate is withdrawn (the pointer came back to the committed slot, or left
-      // the strip). endShift would be wrong here: it strips the transition in the same
-      // write, so the lean would snap home.
-      function releaseLean(): void {
-        if (shifted.size === 0) {
-          return;
-        }
-        // ...except under reduced motion, where snapping IS the requested behaviour and
-        // easing back would animate the very motion the preference opted out of.
-        if (prefersReduce()) {
-          endShift();
-          return;
-        }
-        const rest = new Map<HTMLElement, number>();
-        for (const el of shifted) {
-          rest.set(el, 0);
-        }
-        applyShift(rest, REORDER_SHIFT_TRANS);
-        shiftTimer = setTimeout(endShift, REORDER_SETTLE_MS);
-      }
-      // trackRest is the whole gate, called on every dragover over the strip.
+      // Rest is detected from TWO signals, and separating them is what lets the slot
+      // open promptly without a fast sweep committing every slot it crosses:
       //
-      // Sweeping and settling are DIFFERENT actions and get different answers. While the
-      // pointer is still travelling the strip only LEANS the chips it would displace
-      // (leanToward): instant, cheap, and it is what says where the tab will fall while
-      // you are still looking for the spot. Nothing is rearranged, so crossing five tabs
-      // does not rearrange the strip five times. The moment the pointer comes to REST the
-      // slot opens for real.
+      //  - a `dragover` at an unchanged position is POSITIVE evidence of a stop, so it
+      //    commits after a short REORDER_STILL_MS confirmation. This is the signal that
+      //    normally decides, and the reason the delay is short.
+      //  - the absence of events is only a FALLBACK (armRestNet), for a browser that
+      //    stops delivering dragover entirely. That one has to out-wait the drag loop's
+      //    350ms cadence, so it is long — and it is rarely what decides.
       //
-      // Rest is detected, not waited out. An earlier version made every commit wait a
-      // fixed hold, which is the wrong shape for a direct manipulation: it delayed the
-      // one case that should be instant (you have found the spot and stopped) in order to
-      // protect the case that never needed protecting (you are still moving, and the lean
-      // already covers it). The timer here is re-armed by MOVEMENT, so it expires a rest
-      // window after the last movement rather than a fixed time after a decision.
+      // One quiet window had to serve both jobs before this, which is why it could not be
+      // shortened: the timer deciding responsiveness was the same one that had to survive
+      // the cadence.
       function trackRest(clientX: number): void {
         const dragged = draggingEl;
         if (!dragged) {
@@ -2037,30 +1974,40 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
           cancelRest();
           return;
         }
-        // Lean toward a NEW candidate. The test is guarded on a pending rest rather than
-        // on `before !== restBefore` alone, because null is a legitimate candidate here
-        // ("past the last chip") and would otherwise be indistinguishable from the
-        // initial "nothing pending" state — which is exactly how the first sweep of a
-        // drag toward the end of the strip ended up leaning nothing at all.
-        if (restTimer === null || before !== restBefore) {
-          restBefore = before;
-          leanToward(before); // the sweep preview: where this will fall
-        }
-        // Movement pushes the commit out; stillness lets the armed timer run down to it.
-        // A stationary pointer that has nothing armed still needs one — a browser may
-        // deliver dragover repeatedly at an unchanged position, and the first of those is
-        // the only signal that the pointer arrived and stopped.
-        if (moved || restTimer === null) {
-          if (restTimer !== null) {
-            clearTimeout(restTimer);
-          }
-          restTimer = setTimeout(() => {
-            restTimer = null;
-            const target = restBefore;
-            restBefore = null;
-            commitSlot(target);
-          }, REORDER_REST_MS);
+        restBefore = before;
+        const now = Date.now();
+        if (moved) {
+          // Still travelling. Push the net out and wait.
+          restMovedAt = now;
+          armRestNet();
+          return;
+        }
+        // A dragover at an UNCHANGED position is positive evidence that the pointer has
+        // stopped, which is a far stronger signal than the absence of events — and it is
+        // what lets the slot open promptly instead of out-waiting the drag loop's 350ms
+        // cadence. The elapsed check filters the coincidence where one event of a sweep
+        // lands within REORDER_MOVE_EPS_PX of the previous (a reversal, or a frame whose
+        // motion was almost all vertical); a real stop clears it on the next event.
+        if (now - restMovedAt >= REORDER_STILL_MS) {
+          flushRest();
+          return;
+        }
+        armRestNet(); // too soon to believe; keep the net alive
+      }
+      // armRestNet is the no-events fallback: if dragover stops arriving altogether, no
+      // stationary event will ever confirm the stop, so this commits anyway. Sized to
+      // out-wait the cadence (see REORDER_REST_MS) because it is the one timer that a
+      // fast sweep could otherwise expire between two of its own events.
+      function armRestNet(): void {
+        if (restTimer !== null) {
+          clearTimeout(restTimer);
         }
+        restTimer = setTimeout(() => {
+          restTimer = null;
+          const target = restBefore;
+          restBefore = null;
+          commitSlot(target);
+        }, REORDER_REST_MS);
       }
       function cancelRest(): void {
         if (restTimer === null) {
@@ -2069,11 +2016,10 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
         clearTimeout(restTimer);
         restTimer = null;
         restBefore = null;
-        releaseLean();
       }
       // flushRest commits a pending slot at once, because a release is a decision. It is
       // what stops the rest window from ever being felt as a floor on the gesture: drop
-      // mid-sweep and the tab lands where the lean said it would. Only a `drop` calls it;
+      // mid-sweep and the tab still lands where it was headed. Only a `drop` calls it;
       // an abandoned drag reaches dragend without one and reverts.
       function flushRest(): void {
         if (restTimer === null) {
@@ -2103,18 +2049,18 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
         // belongs HERE and not only in the CSS, because these transitions are written
         // inline and no stylesheet gate can reach them; the switcher's release reel
         // guards its own call site the same way. Read live, so toggling the OS setting
-        // mid-drag takes effect on the next commit and strips any existing lean.
+        // mid-drag takes effect on the very next commit.
         if (prefersReduce()) {
           endShift();
           mutate();
           return;
         }
-        // FIRST — where each chip is right now, LEAN INCLUDED, so a slide continues
-        // out of the lean instead of jumping back through rest first. The switcher's
-        // release reel captures its live swipe preview the same way, and for the
-        // same reason. Rects, not layout offsets: this is VISUAL position, which is
-        // what the animation interpolates (hit-testing wants the opposite, see
-        // dropTargetBefore).
+        // FIRST — where each chip is right now, MID-SLIDE INCLUDED, so a second commit
+        // continues from wherever the first one got to instead of jumping back through
+        // rest first. The switcher's release reel captures its live swipe preview the
+        // same way, and for the same reason. Rects, not layout offsets: this is VISUAL
+        // position, which is what the animation interpolates (hit-testing wants the
+        // opposite, see dropTargetBefore).
         const first = new Map<HTMLElement, number>();
         for (const el of scroller.querySelectorAll<HTMLElement>(".wt-tab")) {
           if (el !== hold) {
@@ -2159,14 +2105,14 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
       // an OSC title) renders the committed order rather than flickering through
       // whatever the pointer is hovering.
       //
-      // Every early return releases the lean, and that is not belt-and-braces. The
-      // caller nulls `restTimer` BEFORE calling in (both the rest timer and flushRest
-      // do), so by the time control arrives here `cancelRest` has already become a no-op
-      // and nothing else would ever hand those chips back.
+      // The caller nulls `restTimer` BEFORE calling in (both the rest timer and
+      // flushRest do), so `cancelRest` is already a no-op by the time control arrives
+      // here: an early return must leave nothing behind that only cancelRest would
+      // Nothing exists pre-commit for it to have cleared, and a slide already in flight
+      // is owned by its own settle timer.
       function commitSlot(before: HTMLElement | null): void {
         const dragged = draggingEl;
         if (!dragged?.isConnected) {
-          releaseLean();
           return; // the dragged session was closed elsewhere mid-gesture
         }
         // The pending slot was chosen a rest window ago, and a session closed in another
@@ -2176,11 +2122,9 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
         // child, which would abandon the drop mid-way and leave DOM order and tabList
         // disagreeing. null stays legal: it means "past the last chip".
         if (before !== null && before.parentNode !== scroller) {
-          releaseLean();
           return;
         }
         if (before === dragged || before === dragged.nextElementSibling) {
-          releaseLean();
           return; // already in that slot
         }
         flipTo(() => {
@@ -2270,8 +2214,8 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
         }
       }
 
-      // endReorderPreview ends the GESTURE's state: the pending hold (easing any
-      // lean home as it goes) and the slot's fade.
+      // endReorderPreview ends the GESTURE's state: the pending rest and the slot's
+      // fade.
       //
       // It deliberately does NOT stop a slide that is already playing. A slide is an
       // animation with its own settle timer, and cutting it here is exactly what
@@ -2291,9 +2235,9 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
       // sweep). Two removals matter, for different reasons:
       //
       //  - the pending reference chip: commitSlot would hand a detached node to
-      //    insertBefore. It guards that too, but standing the hold down here means the
-      //    user's lean comes off at the moment the target vanishes rather than a second
-      //    later, and a fresh dragover can arm a slot that still exists.
+      //    insertBefore. It guards that too, but withdrawing the pending slot here means
+      //    a fresh dragover arms against a chip that still exists rather than waiting out
+      //    a rest window against one that does not.
       //  - the DRAGGED chip: the gesture is over and there is no source left to deliver
       //    a dragend. A browser is not obliged to fire one for a removed source, and
       //    without this the feature would keep `draggingEl` set to a detached node for
@@ -3353,7 +3297,7 @@ export function tabs(opts: TabsOptions = {}): TerminalFeature<TabsApi> {
         return false;
       });
       // Drive the reorder preview while dragging a tab over the strip. A sweep only
-      // leans the chips; the slot opens when the pointer comes to rest (trackRest).
+      // rearranges nothing; the slot opens when the pointer comes to rest (trackRest).
       bar.addEventListener("dragover", (e) => {
         if (!draggingEl) {
           return;

package/src/features/tabs/strip.ts

@@ -21,37 +21,41 @@ import { statusPhrase, statusRevealsDot } from "./model.js";
 // motion is spelled in — index.ts owns the mechanism, strip.ts owns the values,
 // the same split switcher.ts keeps for the mobile swipe.
 
-/** The quiet window (ms) that means the pointer has STOPPED. When it elapses with no
- *  movement, the strip opens the slot the pointer is over.
+/** How long (ms) the pointer must have been un-moved before a stationary `dragover` is
+ *  believed as "stopped".
  *
- *  This is a rest detector, not a hold. The difference is the whole interaction: a hold
- *  makes you wait a fixed time whatever you do, which is exactly the wrong shape here —
- *  a reorder is a direct manipulation and the answer to "when does it move" is "when you
- *  stop looking for the spot". Sweeping across the strip only leans the chips (cheap,
- *  instant, and it is what says where the tab will fall); coming to rest is what commits.
+ *  This is the number that decides how fast the slot opens, and it is small because a
+ *  `dragover` at an UNCHANGED position is positive evidence of rest — far better
+ *  evidence than the absence of events, which is all the fallback below has. The drag
+ *  loop keeps delivering events while the pointer is held still, so a genuinely stopped
+ *  pointer announces itself; this only filters the coincidence where one event of a
+ *  sweep happens to land within REORDER_MOVE_EPS_PX of the previous one (a direction
+ *  reversal, or a frame where the motion was almost entirely vertical). */
+export const REORDER_STILL_MS = 90;
+
+/** Fallback guard (ms): commit the pending slot this long after the last MOVEMENT, for
+ *  the case where `dragover` stops arriving altogether and no stationary event ever
+ *  confirms the stop.
  *
- *  Sized to sit above the gap between two dragover events during a real sweep and below
- *  human perception of delay, so stopping reads as immediate. If a browser's dragover
- *  cadence is ever slower than this, the failure mode is benign: the strip commits the
- *  slot the pointer is over slightly eagerly, which is what it would have done anyway.
+ *  **Its floor is set by the platform, not by taste, and this is the timer that floor
+ *  applies to.** HTML5 drag-and-drop only guarantees a `dragover` every 350ms — the drag
+ *  loop runs on that cadence, not per mouse movement — so a guard at or below it can
+ *  expire BETWEEN two events of a fast sweep, and the strip then commits every slot the
+ *  pointer crosses. Measured in production: at 120ms a quick pass over five tabs moved
+ *  all five.
  *
- *  A release never waits for it either — a drop commits whatever is pending (flushRest). */
-export const REORDER_REST_MS = 120;
+ *  A pure quiet-window design has to make this ONE number carry both jobs, which is why
+ *  it could not be shortened — the same timer that decides responsiveness was the one
+ *  that had to out-wait the cadence, so 500ms was safe and felt slow. Splitting rest
+ *  DETECTION (the stationary event above) from the no-events NET (here) lets each be
+ *  sized for its own job. This one is rarely the deciding signal at all. */
+export const REORDER_REST_MS = 450;
 
 /** Movement (px) between two dragover events below which the pointer counts as still.
  *  A hand resting on a mouse is never perfectly still, and treating a 1px tremor as a
  *  sweep would keep pushing the commit out for as long as someone held the tab. */
 export const REORDER_MOVE_EPS_PX = 3;
 
-/** How far (px) each chip a commit would displace leans toward its destination while
- *  the pointer is still sweeping.
- *
- *  Small enough to read as a lean rather than a move, and large enough to be
- *  unambiguous at a glance: it is what answers "where will this fall" during the sweep,
- *  before anything has actually moved. The same purpose the mobile switcher's
- *  PREVIEW_PEEK_MAX serves for its live swipe. */
-export const REORDER_LEAN_PX = 7;
-
 /** The one transition both preview stages use (the lean, and the slide that
  *  commits it).
  *