test: fix WebKit-sensitive browser specs and a slow App.profile case - #3058

…r shrinks

"decoded image resizing preserves reading and bottom following across
remounts" failed twice in CI WebKit at the `toBeLessThan(1)` check for
the visible row, which received 1.03125.

The check asserts that Virtua keeps the first visible message when its
decoding placeholder shrinks, rather than the next paragraph. Keeping
the paragraph would move the row by most of the placeholder's height.
In WebKit the shrink also measures rows above the viewport. Virtua
compensates for them with whole-pixel scrollTop writes, while row
geometry is in 1/64 px layout units. Measured locally across that
shrink, scrollTop moved from 2785 to 3380 and the row settled 0.96875
px away; Chromium measured no rows above and stayed within 0.03125 px.
So the about-one-pixel residue is rounding, not an anchoring
regression.

The check now uses expectAnchor's `< 4` px tolerance (timeline.mjs),
which still fails if the paragraph is kept instead.

Verification: WebKit 10/10 with 1 worker; Chromium 5/5 with 2 workers.
In runs with 2-3 workers, 19 more runs timed out in `page.goto` before
reaching the check. That came from local CPU contention: the spec starts
a cold dev server per test (see the U1 commit's remaining gap). None of
the runs that reached the check failed it.

Signed-off-by: mtoohey <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 31ba06d957da293d9ce2f13de83c6d906ab94a6e)

"inline video controls follow playback, hover and keyboard focus" failed
in CI WebKit on unrelated branches: after the Pause click, the video
stayed `paused: false` for 10 s. The diagnostic added for run
41331319960 recorded repeated `seeking@0` events and `stalled` around
the click.

The test set `loop = true` so the 2 s clip kept playing through the
visibility assertions. On Linux WebKit (GStreamer), the loop's seek back
to 0 during playback can leave the clip re-seeking to 0 and stalling,
and a Pause landing then leaves the element playing. The controls under
test only need the element to be playing, not its clock to advance.

- Set `playbackRate = 0` instead of `loop`: the video plays without
  reaching its end or seeking.
- Assert the pause with `toHaveJSProperty("paused", true)`.
- Remove the diagnostic instrumentation, now that the failure is
  explained.

Verification: not reproduced locally before the change. After it, the
test passed 10/10 in WebKit and 5/5 in Chromium (1 worker; the spec
starts its own cold dev server per test, which times out under heavier
local parallelism).

Signed-off-by: mtoohey <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 3f86261ab8f2062d95481be4f411c4c9c589aaf0)

…nsition wait

"activity details keep readable text through both handoffs and survive
new..." (activity-groups.spec.mjs:423) timed out in CI WebKit inside
`toggleActivity`, which waited without limit for a `transitionrun` on
the panel's height after `page.setViewportSize`.

WebKit delivers the new size to the page 20-100 ms after
`setViewportSize` resolves. The rows then remeasure and Virtua restores
the reading position in later rendering updates. The toggle was clicked
during that reflow, and in the CI trace, that opening never reported the
height transition the helper samples. Nothing ended the wait, so the
test ran out its 120 s budget with no hint of why.

- After each resize, wait until the page reports the new `innerWidth`,
  then for Virtua to go idle, so the toggle happens at the settled
  width.
- `toggleActivity` also looks for the running height transition once
  per frame, in case its `transitionrun` was missed. If no transition
  starts within 5 s, it rejects with the panel's state (connected,
  expanded, attributes, height, transition) instead of waiting out the
  test.

Verification: not reproduced locally before the change. After it, the
spec passed 48/48 across WebKit and Chromium. A forced no-transition
toggle failed in about 5 s with the panel state.

Signed-off-by: mtoohey <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit e11e2769d6ea2443767011fdd498a7c1f4f68650)

… 15 s budget

"retains a dirty Profile through a same-scope pending/unavailable
Settings destination" (App.profile.test.tsx:936) timed out at vitest's
default 5 s on loaded CI runners.

Each Settings navigation in the journey renders the whole app again.
Timed on a loaded machine: setup 1.0 s, open Profile 1.3 s, Back 1.0 s,
clear 0.5 s, Back 1.1 s, about 5.9 s in total. So the budget is
genuinely too small for the work, as it already was for the
neighbouring tests, which use 15 s. Typing the draft one keystroke at a
time also re-rendered the app per character.

- Paste the draft instead of typing it: the test is about the draft's
  content, not how it was entered.
- Use the neighbouring tests' 15_000 ms timeout.

Verification: the test file passed 10/10 in a loop.
Signed-off-by: mtoohey <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 2a92bdfd96fe3cdaf3427a66d2ca69a8d6760ceb)

…he anchor tolerance

31ba06d957 widened the check that the visible row stays put after its
placeholder decodes to expectAnchor's `< 4` px. That tolerance separates
WebKit's rounding from an anchoring regression only while the
placeholder shrinks by much more than 4 px: keeping the paragraph after
it would move the row by about the shrink. The spec checked the height
of a different image (`beforeHeight > 10`), not `visible`'s.

Assert that `visible`'s placeholder is taller than 40 px. The image
decodes to 10 px, so a wrongly kept paragraph would move the row by over
30 px. The placeholder is about 320 px in both engines today. If fixture
sizes change, the test fails here instead of the tolerance passing
silently.

Verification: the :481 test passed 5/5 in WebKit and 3/3 in Chromium
(1 worker).

Signed-off-by: mtoohey <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
(cherry picked from commit 51c260c80311b72bd2423c5e4faa8a01ad0ca09d)