Spaces:
Sleeping
Sleeping
Commit History
-
Turn the ambient panel float off by default
Bisected against the user's report that the button used to work. Same save test, run repeatedly: c9d9189 "motion runtime + icons 1.0" save works 3/3 48fd5c7 "UI: 3D depth layer ..." save FAILS 0/4 float off (this commit) save works 4/4 The regression entered with the 3D depth layer. Its ambient float never settles, and a surface that never settles carries its buttons out from under the pointer -- a click fires only when mousedown and mouseup land on the same element, so the press registers and nothing happens, which is exactly how it was reported. Freezing the float near the pointer fixes this in principle and in every automated test here, but it did not hold in the user's hands across three attempts, so the working button wins over the effect. The proximity-freeze machinery is kept intact behind the flag. UPS_PANEL_FLOAT=1 restores the drift. Only that one effect is gated: aurora, motes, entrances, sheen, press, hover lift, card tilt, ring …0f6c856 -
Make the steady-surface listener idempotent; add a motion kill switch
Two things, both learned from this fix failing repeatedly in the hand while passing automated tests. 1. Real bug introduced by the previous commit. inject() appends the whole driver to the parent document on EVERY Streamlit rerun, so the driver's top level runs many times per page. The document-level pointermove listener and its surface list were being recreated each time: N reruns meant N listeners, each holding a private list the others could not see, and surfaces that survived a rerun were left registered only in an older list. Both now hang off `window` behind a guard, so exactly one listener and one list exist per page. 2. UPS_REDUCE_MOTION=1 loads the driver but starts nothing, through the same bail-out the OS accessibility preference already used. It exists to settle whether the motion layer is responsible for an interaction problem, without an OS setting or a code edit — a question three rounds of this fix could not answer from test evidence a…f81fd66 -
Freeze panel drift on pointer PROXIMITY, not on arrival
Third and correct cut at this. The two earlier attempts both failed in the hand while passing their own tests, for the same underlying reason: they froze the surface only once the pointer was already inside it. The surface keeps drifting throughout the approach. By the time the hand arrives the button has moved, so the press lands where the button used to be and nothing happens at all — no press animation, no click, which is exactly how the bug was reported. Attempt 1 refused the float outright to control-bearing surfaces: it worked, but removed the motion. Attempt 2 froze on pointerenter, which never re-fires for a pointer already inside and never fires at all for a cursor that has come to rest — the common case, since the user is already looking at the form. Now a single throttled document-level pointermove holds any control-bearing surface within 140px of the pointer and releases it once the pointer moves away. Proximity makes the surface still BEFORE the hand arrives, and being …b172c8d -
Keep the ambient float; freeze it only while the pointer is inside
Supersedes the previous attempt, which fixed the mis-click by refusing the perpetual float to any surface holding a control. That worked, but it took the motion off the main panels — the wrong trade. The float now runs exactly as before and simply stops advancing while the pointer is inside a surface the user can click into, resuming on pointerleave. A click only fires when mousedown and mouseup land on the same element, so the surface has to be still for the moment you are actually aiming at it — and nowhere else. Uses the existing holdFloat/resumeFloat pair, the same handoff tilt3d already performs, so the float remains the sole author of the transform and merely pauses. Pausing holds the current transform rather than clearing it, so nothing snaps. Measured on the running app: pointer away -> 6.7px x / 2.5px y drift (motion alive) pointer inside -> 0.0px / 0.0px (steady to click) pointer leaves -> 9.1px / 4.3px (drift resumes) Save Configuration a…8508ded -
Revert "Merge branch 'fix/floating-panels-swallow-clicks'"
This reverts commit 443ea080034996bf4e0f230e0f651cd4e0d14af6, reversing changes made to a722c74576559971be87178917adcc8b9854e4ff.61929ab -
Fix buttons needing several clicks: stop control-bearing panels drifting
Save Configuration and Run API Check often ignored a click. The Python handler was never at fault — it saves correctly on one click. The cause was in the browser: the ambient float3d loop runs on every surface in SURFACES, which includes [class*="st-key-ups_panel"], so the panel holding the buttons carried a perpetual inline transform (translateZ + rotateX, repeat: Infinity). Measured on the running app: the Save button drifted 7.4px horizontally and 4.3px vertically, continuously. A click only fires when mousedown and mouseup land on the same element, so the moving button silently swallowed clicks — Playwright could not click it at all, reporting "element is not stable" across 56 retries in 30s. motion_runtime already stated this rule for buttons ("a button that moves under the cursor is a button that gets mis-clicked"); it just never applied it to the surface carrying the button. Adds canDrift() — a stricter sibling of canMove() — and gates float3d, tilt3d and the .ups-ev depth wav…932e21f
-
UI: 3D depth layer — ambient float, pointer tilt, ring lie-back
48fd5c7 -
UI: motion runtime + icons 1.0
c9d9189