镜像站点 · 本页由第三方 GitHub 只读镜像提供，非 GitHub 官方站点，不接受任何登录或凭据输入。前往 github.com
Skip to content

test(solo): wait for search and access before Share focus reveal - #2573

Merged
matt2e merged 1 commit into
mainfrom
larry/solo-share-viewport-flake
Nov 6, 2026
Merged

test(solo): wait for search and access before Share focus reveal#2573
matt2e merged 1 commit into
mainfrom
larry/solo-share-viewport-flake

Conversation

@loganj

@loganj loganj commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

🤖

Summary

  • Fixes an intermittent WebKit failure in the browser test "Share opens View only and posts a link without promoting or moving the Solo chat" (tests/browser/solo-chats.spec.mjs). The failing check was expect(share).toBeInViewport({ ratio: 1 }) on the Share #Team button, at a ratio of 0.8366 for the full 10 s.
  • The test focused Share while the dialog's people search still showed "Searching…". The search waits 300 ms after typing before it runs. When it finished, the "Not in this chat" group changed to "No other matching people.", which wraps to two lines at the test's large text size and sits above Share. On Linux WebKit the member list then scrolled so the bottom 8 of Share's 48 px were cut off.
  • The test now waits for the people search, and for the General access summary above it, to finish before it resizes the window and focuses Share. So the focus-reveal check runs on the settled layout, as the test's own comment intends.

Details

  • Test-only change. The focus-reveal assertion added in feat(solo): share chats as view only #2375 is unchanged.
  • The CI traces of two failing runs (41957905132 and 41957189277, WebKit) show the same sequence. After focus, the member list's scroll offset was 490 and the people search still showed "Searching…". In the next snapshot the search had finished and the offset was 458. No app code writes this list's scroll position in that window; the move comes from the browser.
  • Locally on macOS (Playwright WebKit) the search finished about 200 ms after focus in 3 of 3 runs. There the browser kept the visible content in place (scroll offset 530), and Share stayed fully visible.
  • The search wait uses the same "Searching…" status check as solo-sharing.spec.mjs. The status renders in the same update that enables Share, so the wait cannot pass before the search starts.
  • The General access summary ("Existing members keep their access.") also loads asynchronously above Share. It settled before typing in both failing runs, but the test did not wait for it.

Follow-up

  • Not changed: the access dialog does not keep a focused row in view when content above it changes. Linux builds run the same WebKit engine as this CI job, so a Linux user who tabs to Share while a search is still loading, in a narrow window or with large text, may see Share partly cut off. They can still scroll to it.

@loganj Larry @claude
test(solo): wait for search and access before Share focus reveal
c0fcbf0 
The Share opens View only test focused Share #Team while the people
search still showed "Searching…". When the search settled, "No other
matching people." added 40 px above Share. On Linux WebKit the member
list then scrolled so the bottom 8 px of Share were clipped
(toBeInViewport ratio 0.8366) for the rest of the assertion.

Wait for the search status to clear, as solo-sharing.spec.mjs already
does, and for the General access summary to show Private, before the
resize and focus. Both results sit above Share and can change its
position. The focus-reveal check then runs on the settled layout it
describes.

Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Logan Johnson <loganj@squareup.com>
@matt2e
matt2e marked this pull request as ready for review November 6, 2026 01:03
@matt2e
matt2e requested a review from a team as a code owner November 6, 2026 01:03
@matt2e
matt2e merged commit 87c5cee into main Nov 6, 2026
43 checks passed
@matt2e
matt2e deleted the larry/solo-share-viewport-flake branch November 6, 2026 01:03
nathan-thillairajah added a commit that referenced this pull request Nov 6, 2026
@nathan-thillairajah
Merge remote-tracking branch 'origin/main' into dylan/browser-unavail…
213f097 
…able-page

* origin/main:
  feat(browser): show a refused Builderlab app as a page in the panel (#2680)
  fix(profiles): cache profiles on disk and keep dm partners through eviction (#2178)
  feat(profiles): let each reader show verified people by username or full name (#2356)
  fix(media): show transparent avatars without a black background (#2477)
  fix(channels): keep the reader's place when Back returns to a link-opened channel (#2500)
  BUZZ-518: Explain required community sign-in (#2710)
  feat(desktop): serve credentials to agents and your CLI, with pairing (#2260)
  test(solo): wait for search and access before Share focus reveal (#2573)
  fix(relay): answer bytes a failed spool wrote; deflake the memory read (#1970)
  ci(release): publish a signed Intel macOS DMG (#1825)

Signed-off-by: Nathan Thillairajah <nthillairajah@squareup.com>

# Conflicts:
#	docs/browser.md
#	src-tauri/src/browser/builderlab.rs
#	src/features/browser/BrowserHostView.test.tsx
#	src/features/browser/BrowserHostView.tsx
#	src/features/browser/platform.test.ts
@loganj loganj mentioned this pull request Nov 7, 2026
Merged
baxen pushed a commit that referenced this pull request Nov 7, 2026
@loganj Larry @claude
test(solo): wait for the header wrap and chat scroll before Share foc…
077925a 
…us (#2933)

🤖
## Summary
- Fixes an intermittent WebKit failure in the browser test "Share opens
View only and posts a link without promoting or moving the Solo chat"
(`tests/browser/solo-chats.spec.mjs`). After `share.focus()`, the
**Share #Team** button stayed at viewport ratio **0** for the full 10 s.
The focused button was never scrolled into view. This is separate from
the ratio-0.8366 failure fixed in #2573.
- Cause: the test narrows the window to 390 px and doubles the text size
just before it focuses Share. That makes the app header wrap Search onto
its own row, the header grows from 72 to 224 px, and the chat behind the
Share dialog loses 152 px of height. The chat list (Virtua) then scrolls
the chat back to its newest message with `scrollTo`, and repeats that on
size updates for 150 ms. WebKit does not scroll a newly focused element
into view right away: it schedules that on a 0 ms timer, and a
`scrollTo` or `scrollBy` on **any** element before the timer fires
cancels it, even when the position does not change. When the chat's
scroll fell in that window, Share stayed hidden.
- The test's old wait (two `requestAnimationFrame` callbacks) did not
cover this: the test installs Playwright's clock, which replaces
`requestAnimationFrame` with a timer, so the wait never waited for the
browser to render. On loaded Linux CI runners the header and chat
changes landed hundreds of milliseconds later, at focus time.
- The test now waits for the header to wrap and for the chat to rest at
its newest message, with no `scrollTo`/`scrollBy` call on the page for
more than 150 ms, and then focuses Share. Each reading first waits for
two real rendering updates: a new `ResizeObserver` reports only in one,
and the clock does not fake it.

## Details
- Test-only change. The focus-reveal assertion from #2375, the center
hit-test and Enter activation are unchanged.
- The cancel is in WebKit's shared code (`Element::scrollTo` →
`LocalFrameView::cancelScheduledScrolls`; focus →
`scheduleScrollToFocusedElement` on a 0 s timer). Assigning `scrollTop`
does not cancel it.
- CI traces of failing runs show the chat's scroll position jumping by
152 px at the same moment as focus, the header switching to its wrapped
layout around focus, and the member list never scrolling.
- Checks: a `scrollBy` on the chat right after `share.focus()` fails the
old test 3/3 with ratio 0. A no-op `scrollTo` on the chat at 350 and 450
ms after the text change moves the new wait's focus from about 500 ms to
about 950 ms. With the clock paused, the `ResizeObserver` wait still
resolves (0 fake frames ran), and an app observer has received a size
change made before it. The changed test passed 60/60 in Linux WebKit
(Playwright 1.63 image) under CPU load and 6/6 locally on macOS WebKit.
- The wait expects the wrapped header. A future header redesign that no
longer wraps at 390 px and 2x text needs to update it.

## Follow-up
- Not changed: while a dialog is open over a chat that follows its
newest message, a chat scroll correction (an incoming message, a window
resize) that lands between a Tab or `focus()` and WebKit's 0 ms reveal
stops the focused control from being scrolled into view. The window is
very short, so this should be rare. It is the same family as the
follow-up noted in #2573.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Logan Johnson <loganj@squareup.com>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@matt2e matt2e matt2e approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@loganj @matt2e