[Event Timing] Interop 2025: Reduce test flakiness with shadow dom. #55480
+12
−29
Conversation
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
The current Event Timing shadow dom null target test was poorly written and likely hiding a real Chromium issue, that only happens intermittently. Previously: for some reason we would create two spans and simulate two hover events-- but only make one of them long-running and then expect we only get one Event Timing. But the actual duration of an event is related to input and presentation delay, and especially on infra there is no reason to assume the "fast" event will be under 16ms. Further, the PerformanceObserver is registered after the event and afterNextPaint, but without buffering-- so it's a yield continuation task + observer registration request racing against a presentation feedback + observer callback. Given all that, I think we often ran the test expectations only for the first event, rather than the intended second event, or even for an observer that captured both events. (The reported failure is related to having two entries and expecting one). However, after simplifying the test to just test a single hover event, I get fairly consistent failures about the target value not actually being null. I can repro this in Chromium manual test outside of WPT. A fix for Chromium implementation will follow. Bug: 452637511 Change-Id: I2cb67554828669857fd765e78f9b103070de7608
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 current Event Timing shadow dom null target test was poorly written
and likely hiding a real Chromium issue, that only happens
intermittently.
Previously: for some reason we would create two spans and simulate two
hover events-- but only make one of them long-running and then expect we
only get one Event Timing.
But the actual duration of an event is related to input and presentation
delay, and especially on infra there is no reason to assume the "fast"
event will be under 16ms.
Further, the PerformanceObserver is registered after the event and
afterNextPaint, but without buffering-- so it's a yield continuation
task + observer registration request racing against a presentation
feedback + observer callback.
Given all that, I think we often ran the test expectations only for the
first event, rather than the intended second event, or even for an
observer that captured both events.
(The reported failure is related to having two entries and expecting
one).
However, after simplifying the test to just test a single hover event, I
get fairly consistent failures about the target value not actually being
null. I can repro this in Chromium manual test outside of WPT.
A fix for Chromium implementation will follow.
Bug: 452637511
Change-Id: I2cb67554828669857fd765e78f9b103070de7608
Reviewed-on: https://chromium-review.googlesource.com/7048840
WPT-Export-Revision: 465e8949d8e639a69665f6dfeb8324aa05b3ceb7