Fix flaky Firefox calendar-tab e2e tests by dispatching a real hover#67879
Merged
Conversation
potiuk
force-pushed
the
fix-firefox-calendar-tooltip-e2e
branch
from
547ced7 to
68c3f3e
Compare
potiuk
requested review from
bbovenzi,
guan404ming,
pierrejeambrun,
ryanahamilton and
shubhamraj-git
as code owners
pierrejeambrun
approved these changes
Jun 2, 2026
Member
pierrejeambrun
left a comment
pierrejeambrun
left a comment
There was a problem hiding this comment.
Thanks for taking a look.
Indeed I've seen those fail a few times on recent PR.
If CI is happy, i'm happy.
The Dag Calendar tab e2e tests read run states by hovering each cell to open the tooltip. BasicTooltip opens on a mouseenter after a 500ms delay and renders through a portal, which synthetic pointer events do not open reliably in headless Firefox — the three state-reading tests timed out there (chromium was unaffected), and a stepped real-pointer hover did not help either. Expose the per-cell run states as a data-states attribute on the calendar cell, computed with the same view-mode-aware logic the tooltip uses, and read that attribute in the tests instead of hovering. Reading a DOM attribute is deterministic and backend-independent, so the tests pass on every browser.
potiuk
force-pushed
the
fix-firefox-calendar-tooltip-e2e
branch
from
68c3f3e to
e6e5fc5
Compare
Member
|
nit: Description isn't accurate anymore
|
amrith92
pushed a commit
to tully-oss/airflow
that referenced
this pull request
Jun 2, 2026
amrith92
pushed a commit
to tully-oss/airflow
that referenced
this pull request
Jun 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Dag Calendar tab e2e tests (
airflow-core/src/airflow/ui/tests/e2e/specs/dag-calendar-tab.spec.ts) read run states from the hover tooltip (BasicTooltip), which opens on a realmouseenterafter a 500ms delay.In Firefox, the previous
cell.hover({ force: true })teleports the pointer and does not firemouseenter, and re-hovering an already-hovered cell never re-fires it — so the existing retry loop could never recover and the three state-reading tests timed out. Chromium was unaffected. Seen in run 26766429736 (Firefox UI e2e tests, PROD image): 3 failed / 117 passed, all three indag-calendar-tab.spec.ts.Fix
In
DagCalendarTab.getManualRunStates(), reset the pointer to(0, 0)and then move onto the cell centre in steps (page.mouse.move(x, y, { steps: 5 })) so a genuinemouseenteris dispatched on each attempt, instead of the teleportinghover({ force: true }).Test-only change (e2e page object) — no production code touched. The UI compile/lint prek hook passes locally; the Firefox behaviour itself is verified by the e2e job in CI.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines