Skip to content

Commit

Permalink
Bug 1545309 - Run ResizeObserver eventloop test after loading success…
Browse files Browse the repository at this point in the history
…fully. r=dholbert

In test0(), we use the callback of `requestAnimationFrame` to know in which
eventloop (i.e. `Tick()`) we are. However, we may not trigger the callback
of `requestAnimationFrame` if we are not visible. This is an optimization
in Bug 1145439.

Detail:
We use `Document::ShouldThrottleFrameRequests()` to check if we should throttle
the frame requests in the current `Tick()`. This function returns true if we
didn't get painted during the last paint, so we are not visible, so throttle
the frame requests. Note that because we have to paint this document at least
once to unthrottle it, we will drop one `requestAnimationFrame` frame when a
document that previously wasn't visible scrolls into view.

Therefore, we should make sure we got the first paint before running test0().
Using onload is not perfect, but we don't have other better choose for now.

Differential Revision: https://phabricator.services.mozilla.com/D29772

--HG--
extra : moz-landing-system : lando
  • Loading branch information
BorisChiou committed May 6, 2019
1 parent 006096c commit 029fb64
Show file tree
Hide file tree
Showing 2 changed files with 18 additions and 8 deletions.
7 changes: 0 additions & 7 deletions testing/web-platform/meta/resize-observer/eventloop.html.ini

This file was deleted.

19 changes: 18 additions & 1 deletion testing/web-platform/tests/resize-observer/eventloop.html
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,24 @@
}
}
]);
return helper.start(() => t1.remove());

return new Promise((resolve, reject) => {
// This test uses requestAnimationFrame() to check the count of event loop,
// but on some browsers, the FrameRequestCallback may be throttled (i.e.
// simply fired after some extra time) in cases where this test is running
// in an iframe that hasn't yet been painted (i.e. we're not visible).
// This may result in some intermittent failures if this test didn't get a
// first paint (and hence may not have started firing FrameRequestCallbacks)
// by the time the test starts expecting helper.rafCount to have changed.
//
// Therefore, we don't start the test logic until body.onload has fired.
// This increases the likelihood that this testcase will have gotten a
// chance to paint when we start invoking requestAnimationFrame, and that
// its rAF callbacks will fire when the test logic expects them to.
document.body.onload = () => resolve();
}).then(() => {
return helper.start(() => t1.remove());
});
}

function test1() {
Expand Down

0 comments on commit 029fb64

Please sign in to comment.