[web] flaky tests on inactive tabs: css transitions, requestAnimationFrame

[sigmundch]

A few lib/html and co19 tests are testing CSS transitions, and these tests currently timeout or flake on Chrome.

See for example lib/html/transition_event_test: https://dart-current-results.web.app/#/filter=lib/html/transition_event_test

This test passes consistently in FF and Safari, but flakes on dart2js-linux-chrome nearly 90% of the time.

It appears that, like setTimeout, Chrome ignores CSS transitions on background tabs. As a simple repro, you can create a small JS program that:

• creates an element with a css transition (like the one in transition_event_test)
• uses setTimeout to start the transition after a delay, this gives you time to switch tabs and put it in the background before triggering the CSS transition
• use a few additional setTimeout to log JS activity every few seconds.
• add a listener for transitionrun, transitionstart, and transitionend events to log when they occur

What I observe is that all the JS timers complete and log data on the console, but the transition events do not trigger until after I reopen the tab and bring it in the foreground.

This leads me to believe we can't run these tests unless:

• there a flag similar to what was recently discovered for timers that we can apply here to allow CSS transitions in background tabs
• we make sure tabs are always active instead (e.g. open multiple windows, instead of opening multiple tabs?)

@whesse - are any of these possible?
@srujzs - should we just delete these tests?

[sigmundch]

I'm also seeing a similar behavior with requestAnimationFrame API calls

[srujzs]

lib/html/transition_event_test mostly just uses native APIs and the conversion to a Stream. The latter conversion is tested in other places, so I think there isn't much value to testing the APIs that are within that test.

lib/html/request_animation_frame_test is a bit weird. There's one call to _ensureRequestAnimationFrame which does vendor-specific implementation checking, and then replaces requestAnimationFrame with a callback wrapped in a timeout?

[sigmundch]

lib/html/transition_event_test mostly just uses native APIs and the conversion to a Stream. The latter conversion is tested in other places, so I think there isn't much value to testing the APIs that are within that test.

agree

lib/html/request_animation_frame_test is a bit weird. There's one call to _ensureRequestAnimationFrame which does vendor-specific implementation checking, and then replaces requestAnimationFrame with a callback wrapped in a timeout?

Technically it is checking for whether it is implemented, and if not, it adds a polyfill for this feature. I believe we never hit the case of the polyfill.

Most of the test is doing 1 or 2 calls to requestAnimationFrame and testing whether the callback is called as expected or whether cancelling the request works as expected. All of this is native behavior, and nothing specific about Dart IMO.

FWIW - I just sent out https://dart-review.googlesource.com/c/sdk/+/335030 to start skipping these tests in Chrome for now.