Refresh-on-focus can miss a focus that arrives just as a page finishes loading (flaky Thread test) #1036

New issue

Closed

opened 2026-10-02 05:01:10 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-10-02 05:01:10 +00:00

Collaborator

Seen

PR #1034 (backend only) went red on CI / Frontend (shard 2/2), run https://git.rhoving.com/rbrooks/Quest-Board/actions/runs/1797 :

src/pages/discussions/Thread.test.jsx
reading it > what was unread when it was opened (#1020) > keeps them marked after the thread is read again, which says nothing is new
TestingLibraryElementError: Unable to find an element with the text: Arrived while reading.
  147 |       window.dispatchEvent(new Event("focus"));
  148 |       await screen.findByText("Arrived while reading.");

1 failed, 1563 passed; the shard took 888 s (a busy runner). The find waits 5 s, so this was not slowness: the focus never caused a second read.

Cause (read from the code; not reproduced locally)

useFocusRefresh (pages/discussions/useTalk.js) keeps the latest refresh in a ref and updates that ref in a passive effect (useEffect). Thread's callback is if (thread && !deleted) load(). Passive effects run some time after the commit that draws the page, so there is a moment when the posts are on screen and the ref still holds the callback from the render before, in which thread was null. A focus in that moment does nothing. The test dispatches focus as soon as the posts appear, which on a loaded runner lands inside it.

For a person it means a focus or tab-visible event in the instant a thread, a thread list or a Talk count finishes loading is dropped; the next one works.

Fix

Update the ref in a layout effect, which runs inside the commit, so the callback is current by the time the page can be seen. One line in useFocusRefresh, for all three callers (Thread, useThreads, useTalkCount).

## Seen PR #1034 (backend only) went red on **CI / Frontend (shard 2/2)**, run https://git.rhoving.com/rbrooks/Quest-Board/actions/runs/1797 : ``` src/pages/discussions/Thread.test.jsx reading it > what was unread when it was opened (#1020) > keeps them marked after the thread is read again, which says nothing is new TestingLibraryElementError: Unable to find an element with the text: Arrived while reading. 147 | window.dispatchEvent(new Event("focus")); 148 | await screen.findByText("Arrived while reading."); ``` 1 failed, 1563 passed; the shard took 888 s (a busy runner). The find waits 5 s, so this was not slowness: the focus never caused a second read. ## Cause (read from the code; not reproduced locally) `useFocusRefresh` (`pages/discussions/useTalk.js`) keeps the latest `refresh` in a ref and updates that ref in a passive effect (`useEffect`). Thread's callback is `if (thread && !deleted) load()`. Passive effects run some time after the commit that draws the page, so there is a moment when the posts are on screen and the ref still holds the callback from the render before, in which `thread` was null. A focus in that moment does nothing. The test dispatches focus as soon as the posts appear, which on a loaded runner lands inside it. For a person it means a focus or tab-visible event in the instant a thread, a thread list or a Talk count finishes loading is dropped; the next one works. ## Fix Update the ref in a layout effect, which runs inside the commit, so the callback is current by the time the page can be seen. One line in `useFocusRefresh`, for all three callers (`Thread`, `useThreads`, `useTalkCount`).

claude-bot referenced this issue

2026-10-02 05:07:36 +00:00

A character can't be given a name another character is "heard as" (#634) #1034

rbrooks referenced this issue from a commit

2026-10-02 05:27:40 +00:00

Refresh-on-focus answers with the current callback as soon as the page is drawn (#1036)

claude-bot referenced this issue

2026-10-02 20:45:49 +00:00

Flaky Preview test: the second scroll-into-view is asserted before the effect that makes it has run #1039

claude-bot referenced this issue from a pull request that will close it,

2026-10-02 21:37:04 +00:00

Refresh-on-focus answers with the current callback as soon as the page is drawn (#1036) #1040

claude-bot closed this issue

2026-10-02 22:46:03 +00:00

claude-bot referenced this issue from a commit

2026-10-02 22:46:04 +00:00

Merge PR #1040: refresh-on-focus answers with the current callback as soon as the page is drawn (#1036)

claude-bot commented

2026-10-02 22:46:20 +00:00

Author

Collaborator

Done in PR #1040, merged to main on 2026-10-02 with CI green.

useFocusRefresh now sets its callback ref in a layout effect, inside the commit, so a focus or tab-visible event arriving just as a thread, a thread list or a Talk count finishes loading is no longer dropped. New useTalk.test.jsx covers it.

The PR's first CI run went red on a different flaky test (Preview.test.jsx, #1039); it passed once main carried that fix (PR #1041). Branches opened before this merge need main merged in to pick it up; #1034 has been updated.

Done in PR #1040, merged to main on 2026-10-02 with CI green. `useFocusRefresh` now sets its callback ref in a layout effect, inside the commit, so a focus or tab-visible event arriving just as a thread, a thread list or a Talk count finishes loading is no longer dropped. New `useTalk.test.jsx` covers it. The PR's first CI run went red on a different flaky test (`Preview.test.jsx`, #1039); it passed once main carried that fix (PR #1041). Branches opened before this merge need main merged in to pick it up; #1034 has been updated.

claude-bot referenced this issue

2026-10-04 15:27:29 +00:00

Flaky test: AppFrame "choosing a rule opens it in place" does not find its dialog under load #1080