#283 · Don't leave a view loading when its window request is lost
- timeline-app
- pull request
Closes #218. After a bulk delete, `test/desktop-bulk.mjs` sometimes ended with the view loading and no markers. In that state no window request for the view was left pending, so nothing would ever clear it. Reading `render()` and the prediction code turned up three ways to get there. This PR closes all three in `src/app.ts`: - **Dropped reply.** A view's reply for a revision or timeline that's no longer open was dropped while its request was still the current one, and nothing asked again. Now such a reply triggers a fresh render; one that arrives after a later view still does, as before. - **Predictions ahead of the view.** A prediction could start while the view was still waiting for its own window. A desktop prediction can't be interrupted, so the view's request had to wait behind it. Now predictions wait until the view's window is in the cache. - **Skipped render.** A render skipped because the stage was hidden or had zero height dropped the window fetch it was meant to make. Now the fetch is kept for the next frame. **I couldn't reproduce the hang.** Here are the runs, all under `xvfb-run` with `WEBKIT_DISABLE_DMABUF_RENDERER=1 WEBKIT_DISABLE_COMPOSITING_MODE=1`: | Build | Runs | Failed | |---|---|---| | `main` (b4ba7e1), plain | 26 | 0 | | `main`, pinned to one CPU | 10 | 0 | | `main`, with random delays of up to 300 ms or 1.2 s on native queries, document reads and staging, to shake out ordering races | 20 | 0 | | 194069f (the commit in the issue) | 10 | 0 | | this branch, plain | 12 | 0 | | this branch, delays of up to 800 ms | 8 | 0 | One delayed run on `main` failed, but at the app's first load (WebDriver reported a page crash), not after the delete. So this is a fix by reading the code, not one confirmed against a reproduction. If the hang comes back, the remaining suspect is a native `invoke` that never settles: that would leave `windowInFlight` set for good. Testing: - `npm test`: 304 of 305 passed. The one failure was the README listing check, caused by my temporary fuzz copy of the test; I moved it out before committing. - `npm run build` passed. - `test/browser.mjs` passed in Chromium, Firefox and WebKit. Chromium timed out once waiting for the "Fit in view" duration menu item (an in-memory timeline that doesn't use the code changed here) and passed on rerun.
Sources
Open #283 · Don't leave a view loading when its window request is lost in the timeline