5 Commits

Include renames

Author	SHA1	Message	Date
Matyshandclaude[bot]	165dabc5d7	test: restore lazy split mutation coverage ... Issue: #337 User-Visible: no	2026-08-28 05:40:28 +00:00
Sergey Matyunin	e6ac0337d0	fix(tabs): restore captured mouse reordering ... Issue: #243 User-Visible: yes	2026-08-22 19:42:15 +03:00
Codex	82bb03cdf9	fix: end a tab drag when the card is disconnected ... Review CODE-REVIEW-220-r2/r3, F1. The M1 fix installs window listeners for the length of the gesture, and disconnectedCallback — which takes down everything else, down to the other local gesture — did not take those down. Losing the card mid-drag (Lovelace rebuilding its tree, the user leaving the view with the button still down) left them alive: the closure holds the instance and its config, and the next pointerup anywhere on the page would have an invisible card write its order. The smoke now holds a tab, removes the card, and checks that the release it should no longer hear changes nothing. Registered as a mutant too. Issue: #220 User-Visible: no	2026-08-21 08:02:03 +03:00
Codex	a8aeecc32c	fix: judge order dependence by the area in force, close the stuck drag ... Review CODE-REVIEW-220-r1. H1: markersNeedingPlacement decided who depends on the order by reading marker.area alone, while resolveExplicitMarkerPlacement reads `marker.area || <area of the HA device>`. The ordinary marker — bind an HA device, store neither field — is anchored by the registry and never depended on the order, yet it was being written a space it never asked for. Dormant today, and the day that HA area changes it moves the marker to whatever space used to be first. The resolver now asks for the area actually in force. M1: a mouse released past the panel left the gesture stuck, swallowing the next click. Pointer capture is the usual answer and is now taken, but it is not a guarantee — the browser grants it only for a live pointer. The window listener is what actually closes the gesture. M2: the fifth mutant from the spec is registered, plus a sixth for the stuck drag above. Writing the smoke for M1 turned up why the first attempt passed against broken code: synthetic PointerEvents default to composed:false and never leave the shadow root, so nothing outside the panel could ever hear them. Real pointer events are composed; the smoke now says so. Issue: #220 User-Visible: no	2026-08-21 00:50:15 +03:00
Codex	8369c0e839	feat: reorder space tabs by dragging one to a new position ... The order of config.spaces used to be whatever order the spaces were created in, and there was no way back other than deleting a space and drawing it again. The gesture is deliberately narrow — mouse, editors only. The same tabs are the primary way to switch spaces in View, where touch is first class, so a drag there would compete with the tap that switches. Recorded in the spec as "Touch editor: not exposed". The part that needed care is not the drag. Position in the array feeds three things: the marker placement fallback, the swipe neighbour and a positional `floor`. So the write that stores the new order also writes down the placement that used to depend on it: a marker with neither an explicit space nor an area that names one gets the space it has right now. Both changes go in one save; splitting them would leave a window in which markers move on their own. The positional `floor` cannot be fixed from here, so the card says so once. Issue: #220 User-Visible: yes	2026-08-21 00:27:35 +03:00