@jsenv/navi 0.29.380 → 0.29.382

package/dist/jsenv_navi.js

@@ -22296,11 +22296,13 @@ const withCurrentHandlers = (computed, props) => {
  * - It runs the update no matter what. A transition is about the animation,
  *   never about the change.
  * - It swallows the rejection a SKIPPED transition produces. Starting a
- *   transition while another is running skips that other one, and a skipped
- *   transition rejects its promises; nothing is waiting on them, so the
- *   rejection surfaces as an unhandled error (a full error overlay in dev) for
- *   something that is not an error at all — two updates close together is
- *   normal in a list that is being edited.
+ *   transition while another is running skips that other one, and so does the
+ *   document going hidden or its viewport changing size mid-movement; a skipped
+ *   transition rejects `ready` with a DOMException that has no stack. Nothing
+ *   is waiting on it, so the rejection surfaces as an unhandled error (a full
+ *   error overlay in dev, an `unhandledrejection` in an app's error reporting)
+ *   for something that is not an error at all — two updates close together is
+ *   normal in a list that is being edited, and a phone locks its screen.
  *
  * navi calls it from wherever it animates a DOM change itself (see list.jsx),
  * which is why an application using navi finds the API already there.
@@ -22362,12 +22364,22 @@ const startViewTransition$2 = (updateCallback) => {
 };
 
 // "Skipped" is an outcome, not a failure — anything else is still a real error
-// and must keep travelling.
+// and must keep travelling. The browser skips for three reasons and names them
+// differently: `skipTransition()` / another transition starting is an
+// "AbortError" that says skipped, while a document hidden mid-movement, a
+// snapshot containing block that changed size (address bar folding, keyboard
+// opening) and the DOM-update timeout are "InvalidStateError"s that say
+// aborted. All three are recognized by the message: the name alone would let
+// an update callback throwing its own InvalidStateError pass for a skip.
 const ignoreSkip = (e) => {
   if (e && e.name === "AbortError") {
     return;
   }
-  if (e && typeof e.message === "string" && e.message.includes("skipped")) {
+  if (
+    e &&
+    typeof e.message === "string" &&
+    /^Transition was (?:skipped|aborted)/.test(e.message)
+  ) {
     return;
   }
   throw e;
@@ -39810,6 +39822,11 @@ const uiStateHoldsNothing = (uiState) => {
  */
 const NO_ACTION_YET = Symbol("no_action_yet");
 
+// The control types rendered as an element `<label for>` can name: HTML's
+// labelable elements are button, input, select, textarea, output, meter and
+// progress — a picker's trigger is one of them, a link or a details is not.
+const CONTROL_TYPES_A_LABEL_CAN_POINT_AT = new Set(["button", "input", "select", "picker"]);
+
 // Resets field-specific contexts so nested fields inside this component
 // don't inherit the current field's id, message props, or interface reporting.
 // Sets ParentUIStateControllerContext to the leaf's own uiStateController so
@@ -39906,8 +39923,13 @@ const useControlProps = (props, {
     standalone
   } = props;
   const idDefault = useId();
-  const controlId = useContext(ControlIdContext);
-  props.id = props.id || controlId || idDefault;
+  // A Field's id is what its Label points at, so only a control a label can
+  // point at (see the set) takes it. A link in the label's own text is a
+  // control too, but never that target: taking the id would make two elements
+  // answer for it, and the label would read the link's state as its control's.
+  const fieldId = useContext(ControlIdContext);
+  const labelable = CONTROL_TYPES_A_LABEL_CAN_POINT_AT.has(controlType);
+  props.id = props.id || (labelable ? fieldId : undefined) || idDefault;
   const controlName = useContext(ControlNameContext);
   props.name = props.name || controlName;
   const isCheckable = isCheckableInput(controlType, props.type);