Skip to content

[py] fix flaky BiDi input tests that raced the page's autofocus - #17981

Open
AutomatedTester wants to merge 1 commit into
trunkfrom
copse/we-raised-17979-let-s-fix-it-and-assign-th-09c926
Open

[py] fix flaky BiDi input tests that raced the page's autofocus#17981
AutomatedTester wants to merge 1 commit into
trunkfrom
copse/we-raised-17979-let-s-fix-it-and-assign-th-09c926

Conversation

@AutomatedTester

Copy link
Copy Markdown
Member

Description

Fixes #17979.

common/src/web/single_text_input.html focuses #textInput with the autofocus attribute, and every keyboard test in the two BiDi input test files relied on that having taken effect by the time pages.load() returned. Firefox flushes autofocus candidates during the update-the-rendering steps, which can land after the load event, so keys dispatched immediately afterwards go to <body> and the leading characters are dropped.

That explains the reported symptom — a different test failing on each run rather than one broken assertion. The affected tests are all and only the ones that load single_text_input.html.

test_combined_input_actions looked immune because it clicks the input first, but it isn't: the pointer and key sources advance tick-for-tick, so keyDown("t") fires in the same tick as the pointer move, one tick before the button press that would have focused the element. Its leading t depended on autofocus just like the others.

Change

Added a _load_single_text_input() helper to both files that loads the page, requests focus explicitly, and waits for document.activeElement to be the input before the test performs actions. The eight call sites in each file now use it. No production code changes; nothing about the actions under test changed.

Applied to both py/test/selenium/webdriver/common/_bidi/input_tests.py (the generated-command mirror named in the issue) and py/test/selenium/webdriver/common/bidi/input_tests.py (the driver.input facade tests), because the race is identical in both and fixing only one would just move the flake.

test_wheel_scroll_with_duration is deliberately untouched — the issue notes it has a different cause and is being fixed separately.

Verification

⚠️ Not verified locally. The host I worked on ran out of disk (121 MiB free on a 460 GiB volume; ~81 GiB is the Bazel cache), so neither the reproducer nor ./scripts/format.sh could run — both need Bazel. ruff format --diff on the two files is clean, and both files compile.

Reproducer to confirm once space is available:

bazel test //py:test/selenium/webdriver/common/_bidi/input_tests-firefox-bidi \
  --pin_browsers=true --headless=true --local_test_jobs 1 \
  --cache_test_results=no --runs_per_test=5

and the same for //py:test/selenium/webdriver/common/bidi/input_tests-firefox-bidi.

Cross-binding impact

None to production code. Java, Ruby, .NET and JS have their own tests against single_text_input.html that make the same autofocus assumption; worth a follow-up issue if they show the same flake, but none was reported.

AI disclosure

Root-cause analysis and the change were produced with Claude Code (per CONTRIBUTING.md, disclosed here rather than in commit metadata). The reasoning above is mine to defend; the Bazel run that would back it is the outstanding gap noted under Verification.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)

Checklist

  • I have added tests to prove my fix is effective or that my feature works — N/A, this is a test-only fix; the existing tests are the coverage
  • I have added/updated documentation — N/A
  • Tests pass locally — blocked on disk space, see Verification

Co-Authored-By: Copse noreply@copse.dev
Copse-Models: acp:claude-agent-acp#opus[1m]

single_text_input.html focuses #textInput via autofocus. Firefox may apply that after the load event, so keys dispatched immediately after pages.load() can land on <body> and the leading characters get dropped. That is why the failure rotated between the keyboard tests in the file instead of pinning to one assertion.

test_combined_input_actions was affected too: the pointer and key sources advance tick-for-tick, so keyDown("t") fires alongside the pointer move, before the click that would have focused the input.

Request focus explicitly and wait for document.activeElement before performing actions, in both the generated _bidi mirror and the driver.input facade tests.

Fixes #17979
@selenium-ci selenium-ci added C-py Python Bindings B-devtools Includes everything BiDi or Chrome DevTools related labels Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

B-devtools Includes everything BiDi or Chrome DevTools related C-py Python Bindings

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[🐛 Bug]: Flaky Firefox failures in py _bidi input tests

2 participants