Skip to content

Release 2.80.1: no white square where a view's two scrollbars meet - #1031

Merged
adibhanna merged 3 commits into
mainfrom
v2.80.1
Oct 30, 2026
Merged

adibhanna merged 3 commits into
mainfrom
v2.80.1

Conversation

@adibhanna

Copy link
Copy Markdown
Contributor

Same-day patch for 2.80.0 (Adib: "we need all these fixes to be release today with the rest").

  • eef398b Fix(theme): no white square where a view's two scrollbars meet. app-core styled ::-webkit-scrollbar but never its corner, so every view that scrolls both ways (the Kanban board with lanes, new in 2.80.0, and wide database grids) drew a white 10px square in dark themes. One transparent rule; a test pins it. Checked over CDP on the built app in Gruvbox dark and light.
  • b707072 Release: align desktop and shared packages at 2.80.1
  • 06ab9d6 Docs(whats-new): 2.80.1 takes the white square out of the scrollbar corner

Local gates on 06ab9d6: npm ci, typecheck, test:run uncached (shared 2298, app-core 4619+1, desktop 1351+5, quicklook 18), build:prod, the three smoke suites, pack + packaged launch check (2.80.1, page target, rendered), hazard scan, dash lint.

A view that scrolls both ways drew a solid white 10px square in its
bottom-right corner, where the vertical and horizontal scrollbars meet.
In a dark theme it was the brightest thing on screen: rgb(255,255,255)
against Gruvbox dark's rgb(30,32,33). The 2.80.0 phone walk found it on
the Kanban board with lanes, and a check of the desktop build found the
same square on wide database grids.

The global stylesheet styles ::-webkit-scrollbar, its track and its
thumb, but never ::-webkit-scrollbar-corner. Once a page styles the
scrollbar, Chromium draws the corner as a custom part too, and a corner
with no style of its own paints white. The rule was missing long before
2.80.0; lanes only put one more two-way scroller on a screen people look
at all day.

The corner is now transparent beside the global track, so it shows
whatever sits behind the scroller, the same as the track does. That is
the page background in every theme, dark or light, with no new token.
It is one rule in app-core, so desktop, the self-hosted web app and the
phones all get it; the phone shells already carry an equal rule in
their own mobile.css for 1.35.0 / 1.1.51, which this makes redundant
but harmless. The thumb and track are left as they were.

Checked in the built app with both stores isolated, on a Kanban board
with Lanes: Priority (1792 by 8762 inside 654 by 432) and a 24 column,
80 row CSV database (3099 by 2721 inside 654 by 476). In Gruvbox dark
every one of the corner's 400 device pixels reads rgb(30,32,33), the
page's own colour, on both views. Deleting just this rule in the same
session turns all 400 white, and restoring it brings the page colour
back. Gruvbox light reads rgb(250,242,204), the page again, where the
missing rule left a fainter white square on the cream page.

Tests: the stylesheet has a ::-webkit-scrollbar-corner rule with a
transparent background (red without the rule).
@adibhanna
adibhanna merged commit 06ab9d6 into main Oct 30, 2026
10 checks passed
@adibhanna
adibhanna deleted the v2.80.1 branch October 30, 2026 22:21
@adibhanna
adibhanna restored the v2.80.1 branch October 30, 2026 22:21
@adibhanna
adibhanna deployed to boundary-artifacts October 30, 2026 22:46 — with GitHub Actions Active
@adibhanna
adibhanna deployed to boundary-artifacts October 30, 2026 22:48 — with GitHub Actions Active

This branch was successfully deployed

1 active deployment
boundary-artifacts — 06ab9d60 Deployed Oct 30, 2026 by adibhanna via draft #100
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.

1 participant