Simulation results

Run against a Studio actually serving this tree (unsloth studio --frontend <dist>). Worth stating, because a plain local Studio serves the copy installed in its own venv, not the worktree, so a run that looks like it is testing your branch is not.

Does the fix do anything, and does the check have teeth

Firefox and WebKit spot passes: 221 checks, 0 failed each. The broken tree reproduces the CI symptom exactly (scrolls=True pointerEvents=none), so the assertion is load-bearing rather than incidentally green.

Feedback-loop risk, which is the one worth worrying about

overflowing now reads the node's own scrollHeight/clientHeight, and the class it drives decides whether the engine paints a classic scrollbar, which changes clientWidth, which can reflow the cards, which feeds the same ResizeObserver. If that loop has no fixed point the rail flickers forever.

Held at 8 viewports x 3 engines, sampled every 100 ms for 6 s each (24 cases): 0 state flips, 1 distinct state, constant card width in every case, and the flip from none to auto lands exactly at the boundary (921x364 no-scroll/none, 921x360 scroll/auto).

ResizeObserver loop completed with undelivered notifications shows up intermittently in WebKit, at about 1 case-run in 24. It is pre-existing: the merge-base build produces it at the same rate (1 of 3 sweeps, at a different viewport) and so does this branch (1 of 3). Both settle regardless. Not introduced here, and not fixed here.

Blast radius

The whole diff is 24 lines in one hook plus test diagnostics. Nothing touches localStorage, any /api/ call, any schema or any migration, so no existing install, settings file, thread or UNSLOTH_STUDIO_HOME can be affected: the change is in-memory layout state that is recomputed from scratch on every mount.

The desktop branch of provider.tsx uses the same hook and the same class expression, so it gets the identical fix rather than diverging.

Direction is one-way. It is an ||, so it can only add the case the prediction misses, never take pointer input away from a rail that already had it. The existing assertion for the opposite direction, a rail with nothing to scroll to stays click-through, passed in every run above.

Not covered

Chromium stands in for Chrome, Edge and Windows WebView2, and Playwright WebKit is a proxy for Safari and for the WKWebView/WebKitGTK the desktop app embeds, not those webviews themselves. Neither PR touches a GPU or hardware path, so no hardware matrix was run and none is claimed.

The card-width half of the CI failure is still open and deliberately unfixed here; see the commit message for why guessing at it would be worse than leaving it, and for the diagnostics added so the next run of this shard settles it.

@codex review

Codex Review: Didn't find any major issues. 🚀

Reviewed commit: b308f32ea8

Post-merge record: the two CI failures this branch had, and the pointer-events proof

Posting the evidence since the pointer-events change alters what a click DOES even where no pixel moves, and that deserves to be on the record rather than in a run log.

The branch's own regression, and why it was two red jobs

Frontend build + bundle sanity and Frontend unit tests (Windows) were both red, and both on the same step for the same reason: update-banner-flex-priority.test.ts asserts that the restored cap is handed straight back to the transition.

not ok 3558 - a scrolling rail takes pointer input, a fitting one stays click-through
  error: 'the restored cap is handed back to a transition'
  location: 'studio/frontend/tests/update-banner-flex-priority.test.ts:262:1'

Confirmed as this branch's own, not inherited: on the merge base the same file is 15 tests, 15 pass, 0 fail; at the pre-fix head it was 14 pass, 1 fail. The DOM reading had been inserted between the flush of the restored cap and the line putting the eased transition back, which is the one place the store has to keep adjacent.

Fixed by moving the read below the restore. The cap change is already committed under the suppression by the flush above it, and transition is not itself a transitionable property, so no reflow the read forces can hand that cap to an animation. Full suite after: 3671 tests, 3671 pass, 0 fail, typecheck clean.

The width half, which this branch's own diagnostics answered

The diagnostics added earlier here paid for themselves on the first run. WebKit leg:

FAIL 921x534 new chat collapsed: the card keeps its full width whatever the scrollbar does
  cardWidth=430 want=448 railGutter=0 scrolls=True
  why={"borderBox": 448, "cssWidth": "448px", "maxWidth": "448px", "railContentW": 448,
       "railOffsetW": 472, "railClientW": 472, "railMaxHeight": "250.84375px",
       "transform": "matrix(0.96, 0, 0, 0.96, 0, 12)", "kids": [177, 139]}

matrix(0.96, 0, 0, 0.96, 0, 12) is character for character the initial={{ opacity: 0, y: 12, scale: 0.96 }} in components/web/update-banner.tsx, and 448 * 0.96 = 430.08. Nothing had taken any width: borderBox 448, railContentW 448, railGutter 0. The card simply had not been painted at full size yet, so the assertion was racing the enter animation, not catching a scrollbar. The scrollbar-gutter: stable theory in the description was wrong, which is exactly why it was right not to guess at it.

Four candidate mechanisms were written down before the fix was designed, each with the measurement that would tell it apart from the others: a classic scrollbar taking content width (predicts offsetWidth == 430), an unfinished transform (predicts offsetWidth == 448), different rail padding or card cap (predicts cssWidth != 448px), and page zoom (predicts docClientWidth != innerWidth). The observations refute all but the transform.

So the assertion now reads the layout box rather than the painted one. getBoundingClientRect includes transforms, offsetWidth does not, and a scrollbar taking width out of the rail's content box still shrinks offsetWidth, which is the question the assertion is actually asking. Checked across all three engines that this is red exactly when it should be:

chromium  transform only        rect=430 offset=448  OLD=FAIL NEW=PASS
chromium  18px really lost      rect=430 offset=430  OLD=FAIL NEW=FAIL
chromium  both at once          rect=413 offset=430  OLD=FAIL NEW=FAIL
chromium  settled healthy box   rect=448 offset=448  OLD=PASS NEW=PASS
firefox   ... identical to chromium on all four
webkit    ... identical to chromium on all four

The transform cannot mask a real width loss, and the healthy box stays green. Nothing was relaxed; the same check fails on the same condition, measured off the right box.

The pointer-events change: what it captures

overflowing gains one extra true case, the rail really scrolling while the prediction said it fits, and in that case the rail goes from pointer-events: none to auto. Two things had to be established, neither of them by opinion.

What it captures. A 4px grid was walked over the rail's border box in both states, recording elementFromPoint per point:

chromium  7316 points examined   rail scrolling: {'send -> rail': 596}   rail fitting: {}
firefox   7316 points examined   rail scrolling: {'send -> rail': 596}   rail fitting: {}
webkit    7316 points examined   rail scrolling: {'send -> rail': 596}   rail fitting: {}

596 of 7316 points change owner, about 8 percent, and every single one of them is the rail's own chrome, its 12px padding gutters and the 8px gaps between cards. No point is ever taken from a card on any engine, which matters because the cards opt back in with pointer-events-auto even while the rail is click-through, so they were never at risk. Nothing outside the rail's border box changes at all. And in the state the fix does not touch, a rail that genuinely fits, the ownership map is byte-identical, which is what an || should do: it can only add, never subtract.

The points it does take belong to a rail that is scrolling, which is precisely the state where the rail must be interactive or the reader has no scrollbar and no drag and the cards above the fold are unreachable. That is what the existing assertion already specifies; this makes reality match it.

What it paints. Zero difference, on all three engines, in both states:

chromium  scroll  differing_px=0  bbox=None   (of 491814)
chromium  fit     differing_px=0  bbox=None
firefox   scroll  differing_px=0  bbox=None
firefox   fit     differing_px=0  bbox=None
webkit    scroll  differing_px=0  bbox=None
webkit    fit     differing_px=0  bbox=None

One honest caveat rather than a clean claim: every Playwright engine available here draws overlay scrollbars. A control test with a plain overflow-y: scroll box reports offsetWidth - clientWidth == 0 on chromium, firefox and webkit alike, so the classic-scrollbar case is not reproducible on this host at all. On a platform that does draw a classic bar, the product styles it at 8px, and turning pointer input on would both show that bar and take 8px out of the rail's content box. That is REASONED, not run. It is also the intended trade: 8px of card width in exchange for content that was otherwise unreachable, in a state where the rail was already broken.

Playwright's webkit is used throughout as the proxy for Safari and for the WebKitGTK Tauri embed. It is not real Safari and nothing here should be read as a Safari result.

Before, after, and whether it is real

Before: on a rail whose cards stopped short of the floor measured for them, the box overflowed a cap the prediction said it fit inside, so the rail scrolled while still click-through, with no scrollbar and no drag. After: the actual state is or-ed in, read off the node with the real cap back on, refreshed every pass and never latched. Real issue, and the CI run proves it independently, since the pointer-events assertion went green on the WebKit leg while only the width one remained.

Backwards compatibility: the change is confined to the frontend store and one test. No settings key, no schema, no on-disk format, so an existing ~/.unsloth/studio with settings and threads is unaffected.