[Bug]: Browser (`pest-plugin-browser`) test *file* order affects reliability of later files' click→navigate sequences (resource buildup? relates to #1480 / #1755)

What Happened

A test doing visit() → click() → read state → navigate() → read state again is reliable (~100%) when its file is the first Browser test file Pest runs in a process, but fails intermittently (~15-30%) when other Browser test files ran first in the same process — even though those prior files don't touch the same page, component, or storage key. Two distinct symptoms were observed on the same pattern, run to run:

1. click() hangs for ~2x the configured Playwright::timeout() (e.g. ~10s at the 5000ms default) before failing with "Timeout Xms exceeded."
2. A state read immediately after click() silently returns the pre-click value (as if the click had no effect), no error/timeout, ~instant.

Both disappear when either:

• the affected test's file is renamed to run first alphabetically (Pest's discovery order), or
• the test suite for that file is the only one run in the process.

Neither disappears from any application-level fix — ruled out (in own app) an external network request, CSS transitions interfering with actionability checks, and a hydration-timing race in own test (fixing that last one did eliminate symptom no. 2 specifically, suggesting 1. and 2. may have a shared timing root but aren't identical).

How to Reproduce

Two files with byte-identical, self-contained content:

<?php
// tests/Browser/AFile.php AND tests/Browser/BFile.php (identical)
declare(strict_types=1);

test('toggle', function (): void {
    $page = visit('/');
    $before = $page->script('document.documentElement.className');

    $page->click('@some-toggle'); // any real, visible, clickable element
    $after = $page->script('document.documentElement.className');
    expect($after)->not->toBe($before);
});

Run both files together:

vendor/bin/pest tests/Browser/AFile.php tests/Browser/BFile.php

BFile.php's test fails intermittently; run it alone and it's reliable. Run AFile.php alone and it's also reliable — the failure tracks file position in the run, not which file's content is "the" content.

Expected

A test's reliability shouldn't depend on which unrelated Browser test file ran before it in the same process.

Sample Repository

No response

Pest Version

4.7.5

PHP Version

8.5.8

Operation System

macOS

Notes

Versions

• pestphp/pest-plugin-browser: v4.3.1 (latest)
• pestphp/pest: v4.7.5
• PHP: 8.5.8
• Node: v26.5.0
• Playwright: 1.61.1
• OS: macOS (Darwin 25.5.0, arm64)

Given #1480's open report of accumulating Chrome/page instances across test cases, and #1755's finding that all page actions (not just assertions) go through the same hardcoded-1000ms retry loop, the best guess is these compound: accumulated resource pressure from prior files' unfreed browser/page instances pushes actions in later files past the per-attempt window more often, and the loop in #1755 masks how close to the edge each attempt is running

Start with the two identical tests described as tests/Browser/AFile.php and tests/Browser/BFile.php, then run vendor/bin/pest tests/Browser/AFile.php tests/Browser/BFile.php and compare it with running each file alone. Trace the Browser plugin's page and action lifecycle while reproducing the intermittent click and state-read failures. Done means unrelated earlier Browser files no longer affect the later file's click→navigate reliability.