From c9cc0f1743dff257e7f692aafdd40b6ddc563e17 Mon Sep 17 00:00:00 2001
From: feder-cr <85809106+feder-cr@users.noreply.github.com>
Date: Thu, 11 Jun 2026 18:08:11 +0200
Subject: [PATCH] test(mouse): widen hover->mouseenter wait to 10s (full-suite
 load flake)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

test_hover_triggers_mouseenter timed out at the old 5s wait when run as part of
the full e2e suite — browser startup + CPU contention occasionally push the
mouseenter past the window. In isolation the event fires in well under a second
(5/5), so this is load-sensitivity, not a real regression. A 10s wait absorbs it
while still failing fast if mouseenter genuinely never fires.
---
 tests/test_mouse.py | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/test_mouse.py b/tests/test_mouse.py
index ae57486..d915b9e 100644
--- a/tests/test_mouse.py
+++ b/tests/test_mouse.py
@@ -185,8 +185,11 @@ def test_hover_triggers_mouseenter(firefox_binary):
         # Wait for the event rather than reading immediately: under load / on a
         # virtual display the mouseenter can land a beat after hover() returns,
         # which made an instant read flaky. wait_for_function still fails (times
-        # out) if mouseenter genuinely never fires.
-        page.wait_for_function("() => window.__h === true", timeout=5000)
+        # out) if mouseenter genuinely never fires. Timeout is generous (10s) so a
+        # busy full-suite run — where browser startup + CPU contention can push
+        # the event past a tight 5s window — doesn't flake; the event itself fires
+        # in well under a second when run in isolation.
+        page.wait_for_function("() => window.__h === true", timeout=10_000)
 
 
 # ────────────────────────────────────────────────────────────────────