Skip to content

fix(layout): enlarge tiling scrollbar hit area - #261

Open
OliverBennettdev wants to merge 1 commit into
johannesjo:mainfrom
OliverBennettdev:fix/255-tiling-scrollbar-hit-area
Open

fix(layout): enlarge tiling scrollbar hit area#261
OliverBennettdev wants to merge 1 commit into
johannesjo:mainfrom
OliverBennettdev:fix/255-tiling-scrollbar-hit-area

Conversation

@OliverBennettdev

@OliverBennettdev OliverBennettdev commented Aug 15, 2026

Copy link
Copy Markdown

Description

Increases the horizontal scrollbar hit area for the tiling layout strip from 5px to 10px while keeping the painted thumb approximately 6px tall.

The tiling strip previously inherited the global 5px scrollbar size, making it difficult to target. Missing the scrollbar could also place the pointer over nearby panel resize handles.

This change:

  • scopes the larger scrollbar hit area to .tiling-layout-strip
  • preserves the existing 5px scrollbar size elsewhere
  • uses transparent thumb borders to retain a compact visual appearance
  • adds a CSSOM regression test covering both the scoped and global scrollbar dimensions

Issues Resolved

Fixes #255

Check List

  • New functionality includes testing.
  • New functionality has been documented in the README if applicable. (Not applicable; this change introduces no new configuration or user-facing API.)

@johannesjo

Copy link
Copy Markdown
Owner

Thanks for digging into this — the scrollbar-width: auto; scrollbar-color: auto trick is a real technique and it does re-enable the webkit pseudo-elements. But I think the premise is off, and as written the change doesn't enlarge anything.

The strip's scrollbar is already 10px

src/styles.css:996-1000 sets * { scrollbar-width: thin; scrollbar-color: … }. Since Chromium 121, any non-initial scrollbar-width/scrollbar-color makes Blink ignore ::-webkit-scrollbar* for that scroller — so the global ::-webkit-scrollbar { height: 5px } at line 1002 has never applied to anything in this app. Electron 40.8.5 bundles Chromium 144.

Measured against this branch's actual src/styles.css (offsetHeight - clientHeight on .tiling-layout-strip, at device scale 1 / 1.5 / 2, in Chrome 141 / 145 / 148 — bracketing Electron's 144; identical in all):

stylesheet scrollbar band
main 10px
this PR 10px

Controls, showing the mechanism works but isn't pointed at a new number:

test case band
::-webkit-scrollbar{height:5px}, no standard props 5px
scrollbar-width:thin + ::-webkit-scrollbar{height:20px} 10px — webkit ignored
scrollbar-width:auto + ::-webkit-scrollbar{height:20px} 20px — webkit honored

The drag target gets 1px smaller

I probed the real grab area row by row over CDP (synthetic mousePressedmouseMoved +100px → read scrollLeft; 5 trials per row, 3 x-positions, Chrome 145 and 148, fully reproducible):

main:  y+0 … y+9  draggable  → 10px
PR:    y+0 … y+8  draggable  →  9px   (bottom row dead)

So after this change the scrollbar is one pixel harder to grab, not five pixels easier.

What does change is the look

The strip switches from the native thin scrollbar to a custom Blink scrollbar: the arrow buttons disappear and the thumb runs flush to the ends, but painted thumb thickness is ~6px either way. Net effect is that this one scroller now renders differently from every other scroller in the app, with no targetability gain.

The test is green for the wrong reason

src/tiling-layout-scrollbar-styles.test.ts asserts that certain declarations exist in styles.css. It passes — I ran it — and it would pass just as happily with the rule fully overridden at runtime, which is exactly what is happening here. It also pins ::-webkit-scrollbar { width: 5px; height: 5px }, which is itself dead code.

The CSS-text pattern is fine in general and matches src/focus-visible-styles.test.ts — it's just the wrong instrument for "how many pixels tall is this". A geometry claim needs a layout measurement (offsetHeight - clientHeight under Playwright/Electron).

#255's second request is untouched

The handles (src/components/TilingLayout.tsx:608) are flex children inside the strip's content box, so they already stop above the scrollbar — measured 136px handle inside a 140px content box, identical before and after this PR. The dead zone the reporter describes sits above the scrollbar, where the handle legitimately lives, and the "the col-resize cursor … doesn't actually work" half isn't addressed.

Suggested direction

Since the band is already 10px and draggable across its full height, the reporter's problem is most likely aim/visibility plus the neighbouring resize zone:

  1. Contrast, not size — override scrollbar-color on .tiling-layout-strip with a stronger thumb colour. One line, stays on the standard-property path, stays consistent with every other scroller.
  2. If a genuinely bigger band is wanted, it has to be a number above 10 — scrollbar-width: auto on its own (15px native), or the webkit path with height: 14px+. 10px is a no-op.
  3. The non-working resize handle deserves its own issue.
  4. Separately: ::-webkit-scrollbar* at src/styles.css:1002-1018 is dead code app-wide and could be dropped.

If the auto/auto pair survives into a follow-up, please add a comment explaining why it's there — both values are the initial values, so it reads as a no-op and the next person will delete it.

Happy to share the measurement harness (static HTML + the CDP probe script) if it's useful for the follow-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tiling strip's horizontal scrollbar is 5px and collides with the resize handles — a dead click zone right above it

2 participants