fix(sortable-list): use draggable-relative indices so Lit slot elements don't shift the reorder

The `#header`/`#footer` slots (added in the 6-20 sortable-list round-out) render
as REAL `<slot>` elements inside the list container on Lit (shadow DOM), whereas
an empty named slot renders nothing on the 5 light-DOM targets. SortableJS's
plain `e.oldIndex`/`e.newIndex` count ALL element children, so the leading
`<slot name="header">` offset every index by +1 — but ONLY on Lit. Two sites
consumed those polluted indices:

  - handleStart stashed `current[e.oldIndex]` → captured the row AFTER the one
    actually grabbed; the identity-based commit then faithfully moved the wrong
    item (root cause of the off-by-one reorder).
  - handleCommit placed the moved item at `e.newIndex` → one slot too far.

Switch both to `e.oldDraggableIndex`/`e.newDraggableIndex`
(`index(dragEl, options.draggable)` — counts only the `.rozie-sortable-item`
rows, matching the `draggable: '.rozie-sortable-item'` already set). When no
non-draggable children exist the two coincide, so the 5 light-DOM targets are
byte-for-behavior unchanged.

Fixes the 4 Lit VR specs that regressed during the 6-20 round-out and were
masked for ~24h by the VR webServer timeout (058131a): sortable-drag,
-cross, -multi, and nested-lit-reset. Verified locally: all 29 sortable specs
green across all 6 targets; 6 leaves regenerated; lit/react/solid leaves
typecheck.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ArTPHLhYMwrjvvoF9VXDe

Author: serpentblade

packages/ui/sortable-list/packages/angular/src/internal/useSortableJS.ts

@@ -175,9 +175,19 @@ export function useSortableJS<T>(
    * it on the destination side. */
   const handleStart = (e: SortableEvent): void => {
     const current = opts.items();
-    // `e.oldIndex` is the source index in the source list (this list,
-    // since onStart fires from the source).
-    const fromIdx = typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+    // The source index in this list (onStart fires from the source). Prefer the
+    // DRAGGABLE-relative index: with non-draggable element children present
+    // (Lit shadow-DOM `#header`/`#footer` `<slot>`s), plain `e.oldIndex` counts
+    // all children and is offset — stashing `current[oldIndex]` would capture
+    // the WRONG item (the row after the one actually grabbed), and the
+    // identity-based commit lookup would then faithfully move that wrong item.
+    // `oldDraggableIndex` counts only the `.rozie-sortable-item` rows.
+    const fromIdx =
+      typeof e.oldDraggableIndex === 'number'
+        ? e.oldDraggableIndex
+        : typeof e.oldIndex === 'number'
+          ? e.oldIndex
+          : -1;
     if (fromIdx >= 0 && fromIdx < current.length) {
       const item = e.item as unknown as Record<string, unknown> | null;
       if (item !== null && typeof item === 'object') {
@@ -225,10 +235,31 @@ export function useSortableJS<T>(
       // physically moves the same node between lists).
       const stashedItem = readStash<T>(e.item);
 
+      // Prefer the DRAGGABLE-relative indices. SortableJS computes plain
+      // `oldIndex`/`newIndex` via `index(dragEl)` — counting ALL element
+      // siblings — while `oldDraggableIndex`/`newDraggableIndex` use
+      // `index(dragEl, options.draggable)`, counting only the
+      // `.rozie-sortable-item` rows. When the list container also holds
+      // non-draggable element children, the plain indices are offset. This bites
+      // ONLY on Lit: the `#header` / `#footer` named slots render as real
+      // `<slot>` ELEMENTS inside the shadow-DOM list container (the 5 light-DOM
+      // targets render nothing for an empty named slot), so the leading
+      // `<slot name="header">` shifts every plain `newIndex` by +1 and the
+      // writeback dropped items one slot too far. The draggable indices stay
+      // item-relative everywhere; when no non-draggable children exist the two
+      // coincide, so the 5 light-DOM targets are unchanged.
       const oldIndexHint =
-        typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+        typeof e.oldDraggableIndex === 'number'
+          ? e.oldDraggableIndex
+          : typeof e.oldIndex === 'number'
+            ? e.oldIndex
+            : -1;
       const newIndexHint =
-        typeof e.newIndex === 'number' ? e.newIndex : -1;
+        typeof e.newDraggableIndex === 'number'
+          ? e.newDraggableIndex
+          : typeof e.newIndex === 'number'
+            ? e.newIndex
+            : -1;
 
       let next: T[];
       let oldIndex: number;

packages/ui/sortable-list/packages/lit/src/internal/useSortableJS.ts

@@ -175,9 +175,19 @@ export function useSortableJS<T>(
    * it on the destination side. */
   const handleStart = (e: SortableEvent): void => {
     const current = opts.items();
-    // `e.oldIndex` is the source index in the source list (this list,
-    // since onStart fires from the source).
-    const fromIdx = typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+    // The source index in this list (onStart fires from the source). Prefer the
+    // DRAGGABLE-relative index: with non-draggable element children present
+    // (Lit shadow-DOM `#header`/`#footer` `<slot>`s), plain `e.oldIndex` counts
+    // all children and is offset — stashing `current[oldIndex]` would capture
+    // the WRONG item (the row after the one actually grabbed), and the
+    // identity-based commit lookup would then faithfully move that wrong item.
+    // `oldDraggableIndex` counts only the `.rozie-sortable-item` rows.
+    const fromIdx =
+      typeof e.oldDraggableIndex === 'number'
+        ? e.oldDraggableIndex
+        : typeof e.oldIndex === 'number'
+          ? e.oldIndex
+          : -1;
     if (fromIdx >= 0 && fromIdx < current.length) {
       const item = e.item as unknown as Record<string, unknown> | null;
       if (item !== null && typeof item === 'object') {
@@ -225,10 +235,31 @@ export function useSortableJS<T>(
       // physically moves the same node between lists).
       const stashedItem = readStash<T>(e.item);
 
+      // Prefer the DRAGGABLE-relative indices. SortableJS computes plain
+      // `oldIndex`/`newIndex` via `index(dragEl)` — counting ALL element
+      // siblings — while `oldDraggableIndex`/`newDraggableIndex` use
+      // `index(dragEl, options.draggable)`, counting only the
+      // `.rozie-sortable-item` rows. When the list container also holds
+      // non-draggable element children, the plain indices are offset. This bites
+      // ONLY on Lit: the `#header` / `#footer` named slots render as real
+      // `<slot>` ELEMENTS inside the shadow-DOM list container (the 5 light-DOM
+      // targets render nothing for an empty named slot), so the leading
+      // `<slot name="header">` shifts every plain `newIndex` by +1 and the
+      // writeback dropped items one slot too far. The draggable indices stay
+      // item-relative everywhere; when no non-draggable children exist the two
+      // coincide, so the 5 light-DOM targets are unchanged.
       const oldIndexHint =
-        typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+        typeof e.oldDraggableIndex === 'number'
+          ? e.oldDraggableIndex
+          : typeof e.oldIndex === 'number'
+            ? e.oldIndex
+            : -1;
       const newIndexHint =
-        typeof e.newIndex === 'number' ? e.newIndex : -1;
+        typeof e.newDraggableIndex === 'number'
+          ? e.newDraggableIndex
+          : typeof e.newIndex === 'number'
+            ? e.newIndex
+            : -1;
 
       let next: T[];
       let oldIndex: number;

packages/ui/sortable-list/packages/react/src/internal/useSortableJS.ts

@@ -175,9 +175,19 @@ export function useSortableJS<T>(
    * it on the destination side. */
   const handleStart = (e: SortableEvent): void => {
     const current = opts.items();
-    // `e.oldIndex` is the source index in the source list (this list,
-    // since onStart fires from the source).
-    const fromIdx = typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+    // The source index in this list (onStart fires from the source). Prefer the
+    // DRAGGABLE-relative index: with non-draggable element children present
+    // (Lit shadow-DOM `#header`/`#footer` `<slot>`s), plain `e.oldIndex` counts
+    // all children and is offset — stashing `current[oldIndex]` would capture
+    // the WRONG item (the row after the one actually grabbed), and the
+    // identity-based commit lookup would then faithfully move that wrong item.
+    // `oldDraggableIndex` counts only the `.rozie-sortable-item` rows.
+    const fromIdx =
+      typeof e.oldDraggableIndex === 'number'
+        ? e.oldDraggableIndex
+        : typeof e.oldIndex === 'number'
+          ? e.oldIndex
+          : -1;
     if (fromIdx >= 0 && fromIdx < current.length) {
       const item = e.item as unknown as Record<string, unknown> | null;
       if (item !== null && typeof item === 'object') {
@@ -225,10 +235,31 @@ export function useSortableJS<T>(
       // physically moves the same node between lists).
       const stashedItem = readStash<T>(e.item);
 
+      // Prefer the DRAGGABLE-relative indices. SortableJS computes plain
+      // `oldIndex`/`newIndex` via `index(dragEl)` — counting ALL element
+      // siblings — while `oldDraggableIndex`/`newDraggableIndex` use
+      // `index(dragEl, options.draggable)`, counting only the
+      // `.rozie-sortable-item` rows. When the list container also holds
+      // non-draggable element children, the plain indices are offset. This bites
+      // ONLY on Lit: the `#header` / `#footer` named slots render as real
+      // `<slot>` ELEMENTS inside the shadow-DOM list container (the 5 light-DOM
+      // targets render nothing for an empty named slot), so the leading
+      // `<slot name="header">` shifts every plain `newIndex` by +1 and the
+      // writeback dropped items one slot too far. The draggable indices stay
+      // item-relative everywhere; when no non-draggable children exist the two
+      // coincide, so the 5 light-DOM targets are unchanged.
       const oldIndexHint =
-        typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+        typeof e.oldDraggableIndex === 'number'
+          ? e.oldDraggableIndex
+          : typeof e.oldIndex === 'number'
+            ? e.oldIndex
+            : -1;
       const newIndexHint =
-        typeof e.newIndex === 'number' ? e.newIndex : -1;
+        typeof e.newDraggableIndex === 'number'
+          ? e.newDraggableIndex
+          : typeof e.newIndex === 'number'
+            ? e.newIndex
+            : -1;
 
       let next: T[];
       let oldIndex: number;

packages/ui/sortable-list/packages/solid/src/internal/useSortableJS.ts

@@ -175,9 +175,19 @@ export function useSortableJS<T>(
    * it on the destination side. */
   const handleStart = (e: SortableEvent): void => {
     const current = opts.items();
-    // `e.oldIndex` is the source index in the source list (this list,
-    // since onStart fires from the source).
-    const fromIdx = typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+    // The source index in this list (onStart fires from the source). Prefer the
+    // DRAGGABLE-relative index: with non-draggable element children present
+    // (Lit shadow-DOM `#header`/`#footer` `<slot>`s), plain `e.oldIndex` counts
+    // all children and is offset — stashing `current[oldIndex]` would capture
+    // the WRONG item (the row after the one actually grabbed), and the
+    // identity-based commit lookup would then faithfully move that wrong item.
+    // `oldDraggableIndex` counts only the `.rozie-sortable-item` rows.
+    const fromIdx =
+      typeof e.oldDraggableIndex === 'number'
+        ? e.oldDraggableIndex
+        : typeof e.oldIndex === 'number'
+          ? e.oldIndex
+          : -1;
     if (fromIdx >= 0 && fromIdx < current.length) {
       const item = e.item as unknown as Record<string, unknown> | null;
       if (item !== null && typeof item === 'object') {
@@ -225,10 +235,31 @@ export function useSortableJS<T>(
       // physically moves the same node between lists).
       const stashedItem = readStash<T>(e.item);
 
+      // Prefer the DRAGGABLE-relative indices. SortableJS computes plain
+      // `oldIndex`/`newIndex` via `index(dragEl)` — counting ALL element
+      // siblings — while `oldDraggableIndex`/`newDraggableIndex` use
+      // `index(dragEl, options.draggable)`, counting only the
+      // `.rozie-sortable-item` rows. When the list container also holds
+      // non-draggable element children, the plain indices are offset. This bites
+      // ONLY on Lit: the `#header` / `#footer` named slots render as real
+      // `<slot>` ELEMENTS inside the shadow-DOM list container (the 5 light-DOM
+      // targets render nothing for an empty named slot), so the leading
+      // `<slot name="header">` shifts every plain `newIndex` by +1 and the
+      // writeback dropped items one slot too far. The draggable indices stay
+      // item-relative everywhere; when no non-draggable children exist the two
+      // coincide, so the 5 light-DOM targets are unchanged.
       const oldIndexHint =
-        typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+        typeof e.oldDraggableIndex === 'number'
+          ? e.oldDraggableIndex
+          : typeof e.oldIndex === 'number'
+            ? e.oldIndex
+            : -1;
       const newIndexHint =
-        typeof e.newIndex === 'number' ? e.newIndex : -1;
+        typeof e.newDraggableIndex === 'number'
+          ? e.newDraggableIndex
+          : typeof e.newIndex === 'number'
+            ? e.newIndex
+            : -1;
 
       let next: T[];
       let oldIndex: number;

packages/ui/sortable-list/packages/svelte/src/internal/useSortableJS.ts

@@ -175,9 +175,19 @@ export function useSortableJS<T>(
    * it on the destination side. */
   const handleStart = (e: SortableEvent): void => {
     const current = opts.items();
-    // `e.oldIndex` is the source index in the source list (this list,
-    // since onStart fires from the source).
-    const fromIdx = typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+    // The source index in this list (onStart fires from the source). Prefer the
+    // DRAGGABLE-relative index: with non-draggable element children present
+    // (Lit shadow-DOM `#header`/`#footer` `<slot>`s), plain `e.oldIndex` counts
+    // all children and is offset — stashing `current[oldIndex]` would capture
+    // the WRONG item (the row after the one actually grabbed), and the
+    // identity-based commit lookup would then faithfully move that wrong item.
+    // `oldDraggableIndex` counts only the `.rozie-sortable-item` rows.
+    const fromIdx =
+      typeof e.oldDraggableIndex === 'number'
+        ? e.oldDraggableIndex
+        : typeof e.oldIndex === 'number'
+          ? e.oldIndex
+          : -1;
     if (fromIdx >= 0 && fromIdx < current.length) {
       const item = e.item as unknown as Record<string, unknown> | null;
       if (item !== null && typeof item === 'object') {
@@ -225,10 +235,31 @@ export function useSortableJS<T>(
       // physically moves the same node between lists).
       const stashedItem = readStash<T>(e.item);
 
+      // Prefer the DRAGGABLE-relative indices. SortableJS computes plain
+      // `oldIndex`/`newIndex` via `index(dragEl)` — counting ALL element
+      // siblings — while `oldDraggableIndex`/`newDraggableIndex` use
+      // `index(dragEl, options.draggable)`, counting only the
+      // `.rozie-sortable-item` rows. When the list container also holds
+      // non-draggable element children, the plain indices are offset. This bites
+      // ONLY on Lit: the `#header` / `#footer` named slots render as real
+      // `<slot>` ELEMENTS inside the shadow-DOM list container (the 5 light-DOM
+      // targets render nothing for an empty named slot), so the leading
+      // `<slot name="header">` shifts every plain `newIndex` by +1 and the
+      // writeback dropped items one slot too far. The draggable indices stay
+      // item-relative everywhere; when no non-draggable children exist the two
+      // coincide, so the 5 light-DOM targets are unchanged.
       const oldIndexHint =
-        typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+        typeof e.oldDraggableIndex === 'number'
+          ? e.oldDraggableIndex
+          : typeof e.oldIndex === 'number'
+            ? e.oldIndex
+            : -1;
       const newIndexHint =
-        typeof e.newIndex === 'number' ? e.newIndex : -1;
+        typeof e.newDraggableIndex === 'number'
+          ? e.newDraggableIndex
+          : typeof e.newIndex === 'number'
+            ? e.newIndex
+            : -1;
 
       let next: T[];
       let oldIndex: number;

packages/ui/sortable-list/packages/vue/src/internal/useSortableJS.ts

@@ -175,9 +175,19 @@ export function useSortableJS<T>(
    * it on the destination side. */
   const handleStart = (e: SortableEvent): void => {
     const current = opts.items();
-    // `e.oldIndex` is the source index in the source list (this list,
-    // since onStart fires from the source).
-    const fromIdx = typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+    // The source index in this list (onStart fires from the source). Prefer the
+    // DRAGGABLE-relative index: with non-draggable element children present
+    // (Lit shadow-DOM `#header`/`#footer` `<slot>`s), plain `e.oldIndex` counts
+    // all children and is offset — stashing `current[oldIndex]` would capture
+    // the WRONG item (the row after the one actually grabbed), and the
+    // identity-based commit lookup would then faithfully move that wrong item.
+    // `oldDraggableIndex` counts only the `.rozie-sortable-item` rows.
+    const fromIdx =
+      typeof e.oldDraggableIndex === 'number'
+        ? e.oldDraggableIndex
+        : typeof e.oldIndex === 'number'
+          ? e.oldIndex
+          : -1;
     if (fromIdx >= 0 && fromIdx < current.length) {
       const item = e.item as unknown as Record<string, unknown> | null;
       if (item !== null && typeof item === 'object') {
@@ -225,10 +235,31 @@ export function useSortableJS<T>(
       // physically moves the same node between lists).
       const stashedItem = readStash<T>(e.item);
 
+      // Prefer the DRAGGABLE-relative indices. SortableJS computes plain
+      // `oldIndex`/`newIndex` via `index(dragEl)` — counting ALL element
+      // siblings — while `oldDraggableIndex`/`newDraggableIndex` use
+      // `index(dragEl, options.draggable)`, counting only the
+      // `.rozie-sortable-item` rows. When the list container also holds
+      // non-draggable element children, the plain indices are offset. This bites
+      // ONLY on Lit: the `#header` / `#footer` named slots render as real
+      // `<slot>` ELEMENTS inside the shadow-DOM list container (the 5 light-DOM
+      // targets render nothing for an empty named slot), so the leading
+      // `<slot name="header">` shifts every plain `newIndex` by +1 and the
+      // writeback dropped items one slot too far. The draggable indices stay
+      // item-relative everywhere; when no non-draggable children exist the two
+      // coincide, so the 5 light-DOM targets are unchanged.
       const oldIndexHint =
-        typeof e.oldIndex === 'number' ? e.oldIndex : -1;
+        typeof e.oldDraggableIndex === 'number'
+          ? e.oldDraggableIndex
+          : typeof e.oldIndex === 'number'
+            ? e.oldIndex
+            : -1;
       const newIndexHint =
-        typeof e.newIndex === 'number' ? e.newIndex : -1;
+        typeof e.newDraggableIndex === 'number'
+          ? e.newDraggableIndex
+          : typeof e.newIndex === 'number'
+            ? e.newIndex
+            : -1;
 
       let next: T[];
       let oldIndex: number;