Consider ways of advancing virtual time

[domenic]

In C++ tests we have the ability to advance a virtual clock to test time-dependent things. In Web Platform Tests, e.g. testing default timeout behaviors or similar, we do not.

It's conceivable this virtual-clock infrastructure could be exposed as a test-only API. It would presumably affect setTimeout, Date.now, and various other related things.

The specific case that brought this up is wanting to test the default timeout for <std-toast> without actually waiting 3 seconds.

[stephenmcgruer]

We now have 3 requests for this feature; for std-toast (which is no longer a thing so won't be needed...), for periodic background sync, and for service workers.

cc @jgraham as well

[noamr]

It would probably make performance API testing a lot simpler as well. Some of those tests are super tricky flakiness-wise because of the time aspect.

[dbaron]

For an example of an existing mechanism that's similar to this, see these APIs on DOMWindowUtils that are used in a number of Gecko-internal mochitests. When I wrote them (for testing CSS animations, I think), I intended to hook them up to more sources of time than they're currently hooked up to (for example, in this bug), but never actually did so. (I wouldn't be surprised if hooking them up to more sources of time today might break some of the existing tests that use them.)

[wanderview]

This would be useful for testing privacy features that clear state based on a timer; e.g. bounce tracking mitigations. Without the ability to advance time we basically cannot write WPT tests for this kind of feature.