fix(webapp): #content shows it scrolls, Public links moves up (BEA-79) - #128
Open
ssowonny wants to merge 1 commit into
Open
fix(webapp): #content shows it scrolls, Public links moves up (BEA-79)#128ssowonny wants to merge 1 commit into
ssowonny wants to merge 1 commit into
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
#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.browse.spec.tsreached 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-coloralongside::-webkit-scrollbar. Measured in headless Chromium on macOS, that combination reserves 0px — Chromium discards every::-webkit-scrollbarrule 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.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 instyle.csssays 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.cssscrollbar-gutter: stableon#content, plus the pointer-fine scrollbar blocksrc/components/ProjectSettings.tsxe2e/layout.spec.ts#contentreserves a scrollbare2e/browse.spec.ts.admin-card-table.last()→.shares-tablee2e/helpers.ts#contentdoes — for the next persona tour's screenshotsinternal/webapp/staticNot 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 byoffsetWidth - clientWidth = 10and by the new e2e assertion.Mobile (iPhone 13) — the reorder carries, the scrollbar rules do not fire:
Verified
go build ./...,go vet ./...,go test ./...— all packages pass.npm run e2e— 154 passed, 1 skipped (a pre-existingtest.skipinsec14fe.spec.ts).frontend/check-dist.sh— committedstatic/matchesfrontend/src.#contentreserves 10px in Chromium, 0px on touch; Firefox on macOS reserves 0px (the known gap).Carry this
Firefox on macOS ignores
scrollbar-width,scrollbar-colorandscrollbar-gutteralike — 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
(only works on this machine)