Settle the panel before pressing, and read the key line's whole register - #39
Conversation
|
Same failure again on What is new is an independent check at 141a430, which is
On a browser-binary reading of this failure, which came up on #37's thread: this ran on Playwright's pinned headless shell, which is what
|
|
Both runs the comment above left in flight have finished, and they disagree — which is worth recording, because the disagreement is the failure's own shape rather than evidence against the fix. Run 32781525387 at 61bf2af failed exactly as described: Run 32781880560 at 141a430 — So the race is load-dependent on CI while reproducing deterministically at |
The walk that puts the reader in a comment opens the panel, and the document slides into its new width over the fifth of a second after. The point for the pointer was taken on that flight, so the slide carried the mark out from under the pointer and no second mousemove came to correct it: the wait for the hover ran out thirty seconds later, reading as though the page had stopped lighting what the pointer is on. Wait on the slide with panel_settled before reading the point.
The line paints two chips and hides the rest behind More, so `inner_text` no longer says what a row's `when` decided: on a board page the widget's own two rows take both seats and `z undo` is invisible whether it is live or not. The after-drop read asked for a chip that page can never paint, and the mid-drag read passed on the same absence, proving nothing about the edge it was written for. Read every row the line painted instead. A repaint that never came still leaves the rows the previous state put there, so both bug-backs stand: dropping paintKeys from `dragging` fails the mid-drag assertion, and returning onEnd to a bare classList.remove fails the one after the drop.
f4de73f to
c9f0e59
Compare
leaf-agent
changed the title
|
Run 32784826135 at d3151de is the first run where both halves land together — What is new beyond the recurrence is that both reproduce deterministically on a CI runner, not only on a workstation. Previous readings had the standing-mark failure as load-dependent under xdist and deterministic at The 37s → 5.9s drop is the 30s hover wait that no longer times out. How this was runSame runner as the failing job, Playwright's pinned headless shell ( uv run pytest tests/test_render.py -q -n0 --run-nightly \
-k "test_the_page_marks_the_comment_the_reader_is_standing_in or test_a_pointer_drag_stops_the_line_offering_the_press_it_refuses"On d3151de the standing-mark test fails at |
2 participants
Two test reads are holding
cired onmain, one per commit, and neither can show a greentestwhile the other stands — so they are here together rather than in two PRs that would each stay red. They revert independently; nothing in one depends on the other.The standing mark's pointer
test_the_page_marks_the_comment_the_reader_is_standing_in—Page.wait_for_function: Timeout 30000ms exceededwaiting forlf-mark-hoverafter the pointer is put on the standing mark. First seen on run 32779874922; the run that opened this session, 32778837094, failed instead on the note-set axis, which 90ba2a7 had already fixed four minutes after that run was queued.The walk that puts the reader in a comment opens the panel, and the document slides into its new width over the fifth of a second that follows (
syncLayout, the slidepanel_settledwas written for). The point handed topage.mouse.moveis taken on that flight, against a column that is still moving, so the pointer goes where the mark was and the slide carries the mark out from under it. The runtime is right to drop the hover —pageShiftedrecomputesmarkAt(pointer.x, pointer.y)after the reflow, and by then the pointer is over ordinary prose. Measured at the read, on Linux:Nothing retries, because a highlight is not an element — so it surfaces 30s later at the hover wait, reading as though the page had stopped lighting what the pointer is on.
panel_settled(page)before the point is read; it consumes the transition throughgetAnimations(), so it returns on the frame the slide ends rather than encoding the stylesheet's duration. It goes at the geometry read rather than up at the walk, because the three readings in between are about the arrival's lift and are green as they stand.The key line's rows
test_a_pointer_drag_stops_the_line_offering_the_press_it_refuses—assert 'undo' in '⏎ / space\ngrab the card\nesc\nlet go\n?\nmore'. New with 141a430 (#22), which was verified against a base that predates ee4d444.renderLinenow paints two chips — the first row and the way out — and hides the rest behind More, whatever the page is offering. Soinner_textno longer answers what a row'swhendecided: on a board page the widget's own⏎ / space grab the cardandesc let gotake both seats, andz undois invisible whether it is live or not. The read after the drop asked for a chip that page can never paint, and the read mid-drag passed on that same permanent absence — proving nothing about the edge it was written for. Whatwhendecides is whether the row is in the line at all:_painted_linereturns those rows instead of the visible text. A repaint that never came still leaves the rows the previous state put there, so the reading stays once-only and both edges keep their bug-backs.Testing
Each fix reproduced at its own failure before the change and green after, at
-n0 --run-nightlyon Linux, then again together on the rebase onto currentmain(d3151de):8 passedover the two tests and the key-line tests around them.Bug-backs, since a wait added to a timing failure and a widened read are both shapes that can green a test by removing what it proves:
paintHover(id)→paintHover(null)inleaf.jspanel_settledin placepaintKeys()fromdraggingthe line offered a press the dispatcher refuses for the length of a dragonEnd'sdragging(this, false)→ bareclassList.removethe drop that sent nothing left the line refusing a press that is liveuv run pytest tests -n2— 494 passed, 6 skipped.pre-commitclean on the changed file. The full--run-nightlymodule is left to this PR's ownci.Automated fix for failed run