Skip to content

fix(webapp): #content shows it scrolls, Public links moves up (BEA-79) - #128

Open
ssowonny wants to merge 1 commit into
mainfrom
bea-79-ph-scan-bug-public-links-section-sits-below-the-fold-inside
Open

fix(webapp): #content shows it scrolls, Public links moves up (BEA-79)#128
ssowonny wants to merge 1 commit into
mainfrom
bea-79-ph-scan-bug-public-links-section-sits-below-the-fold-inside

Conversation

@ssowonny

@ssowonny ssowonny commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

TL;DR

  • Project settings at 1440x900 stopped at People — Public links, the section that answers "is anything of ours public right now?", was below the fold and nothing said so.
  • #content (the app's only scroller, on every route) now takes a real 10px scrollbar, and Public links moves from the 4th card to the 2nd.
  • The CSS the plan specified is a measured no-op — it would have shipped an invisible change on the exact platform the bug was reported from. Details below.
  • Known gap: Firefox on macOS always uses overlay scrollbars and no CSS overrides it, so the bar stays hidden there. It's an OS setting.
  • browse.spec.ts reached the shares table by .last(); the reorder would have silently repointed it at the members table. Now selects by class.

The one thing to actually check

The plan called for scrollbar-width + scrollbar-color alongside ::-webkit-scrollbar. Measured in headless Chromium on macOS, that combination reserves 0px — Chromium discards every ::-webkit-scrollbar rule the moment either standard property is set on the same element, and the standard properties alone leave the macOS overlay bar, which takes no width and is invisible at rest.

flowchart LR
  I["make #content show it scrolls"] --> A["plan: standard props AND<br/>webkit rules, same element"]
  I --> B["shipped: webkit rules alone;<br/>standard props behind an<br/>@supports not selector guard"]
  A --> A2["Chromium reserves 0px<br/>invisible, bug unchanged"]
  B --> B2["Chromium reserves 10px<br/>Firefox gets the styled thin bar"]
Loading

So the standard properties now sit inside @supports not selector(::-webkit-scrollbar) — engines with no webkit pseudo-element, i.e. Firefox. Setting both is the trap, and the comment in style.css says so, because the "tidier" edit restores the bug silently.

The whole block is scoped to @media (pointer: fine), so touch keeps overlay scrollbars — verified 0px reserved on iPhone 13 emulation, 10px at 1440x900.

What changed

src/style.css scrollbar-gutter: stable on #content, plus the pointer-fine scrollbar block
src/components/ProjectSettings.tsx General → Public links → People → About → Danger zone (was General → About → People → Public links)
e2e/layout.spec.ts new test: pins the card order and asserts #content reserves a scrollbar
e2e/browse.spec.ts .admin-card-table .last().shares-table
e2e/helpers.ts one note: the document never scrolls, #content does — for the next persona tour's screenshots
internal/webapp/static rebuilt

Not doing, per the spec: page-level scrolling (every route depends on the fixed shell), and a section-index nav (new UI for a papercut).

Screenshots

Project settings, 1440x900, member@example.com. Headless capture omits scrollbars in every engine — verified with a bright-red thumb that also failed to appear — so these show the reorder and the ~5px column shift from the reserved gutter, not the bar itself. The bar is evidenced by offsetWidth - clientWidth = 10 and by the new e2e assertion.

Before After
before after

Mobile (iPhone 13) — the reorder carries, the scrollbar rules do not fire:

Before After
mobile before mobile after

Verified

  • go build ./..., go vet ./..., go test ./... — all packages pass.
  • npm run e2e — 154 passed, 1 skipped (a pre-existing test.skip in sec14fe.spec.ts).
  • frontend/check-dist.sh — committed static/ matches frontend/src.
  • Measured directly at 1440x900: #content reserves 10px in Chromium, 0px on touch; Firefox on macOS reserves 0px (the known gap).

Carry this

Firefox on macOS ignores scrollbar-width, scrollbar-color and scrollbar-gutter alike — it uses overlay scrollbars unless the user sets System Settings → Appearance → Show scroll bars: Always. Where Firefox does use classic scrollbars (Windows, Linux, or that setting), the rules here give it the styled thin bar and the stable gutter; that path is reasoned, not measured, since this machine can't produce it. The issue's acceptance criterion asked for Firefox-on-macOS visibility, and that is the one criterion no CSS can meet.

Closes BEA-79.

Build session

cd $(git worktree list | grep bea-79 | awk '{print $1}') && claude --resume e76257b0-114e-4fb8-9907-d8056294b796

(only works on this machine)

Project settings at 1440x900 ended at People. Public links — the section
that answers "is anything of ours public right now?" — was below the fold
of #content, the app's only scroll container, and with macOS overlay
scrollbars nothing at rest said there was more.

#content now takes a real scrollbar. The plan called for scrollbar-width
+ scrollbar-color alongside ::-webkit-scrollbar; measured, that combination
is a no-op: Chromium drops every ::-webkit-scrollbar rule as soon as either
standard property is set on the same element, and the standard properties
alone leave the macOS overlay bar, which takes no width and is invisible at
rest. So the standard properties sit behind @supports not
selector(::-webkit-scrollbar) — Firefox only. Verified: 10px reserved in
Chromium, 0 on touch.

Public links also moves from fourth card to second (General → Public links
→ People → About → Danger zone), so the security answer is above the fold
even without the cue.

browse.spec reached the shares table by .last(), which the reorder would
have silently repointed at the members table — both render through
AdminTable. It selects .shares-table now.

Known gap: Firefox on macOS always uses overlay scrollbars and no CSS
overrides it, so the bar there stays hidden at rest — that is an OS
setting, not something this can fix.
@ssowonny
ssowonny requested a review from thefron August 5, 2026 11:23
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