The TestRendered event is dispatched for reftests containing a
reftest-wait class on the root at the time the test would complete if
there wasn't such a class. This occurs after the initial paint is
complete, so any dynamic changes can be performed in such a way that
they are not batched with the initial layout/paint.
Details
Details
- Reviewers
• maja_zf • mattwoodrow • ato - Group Reviewers
Restricted Project - Commits
- rMOZILLACENTRAL033df21b3afe: Bug 1595564 - Dispatch TestRendered event for wpt reftests with reftest-wait…
- Bugzilla Bug ID
- 1595564
Diff Detail
Diff Detail
- Repository
- rMOZILLACENTRAL mozilla-central
Event Timeline
| testing/marionette/listener.js | ||
|---|---|---|
| 1741–1748 | What are we checking again here? Seems like we only check for reftest-wait before waiting for load now. Could we just check for reftest-wait for the first time at this point (loaded, painting all finished and stable), and then fire TestRendered if so? | |
| testing/marionette/listener.js | ||
|---|---|---|
| 1741–1748 | Oh yes, that comment is wrong. We certainly could just check here, but there's a small semantic difference between checking for reftest-wait at the point at which the load event fires and checking for it later when we're going to take the screenshot. It probably doesn't matter in practice, but this is closer to the old behaviour. That said it looks like the implementation for other browsers is closer to what you're suggesting and it does make the implementation easier so I guess I'll take the risk of changing it. | |
| testing/marionette/listener.js | ||
|---|---|---|
| 1741–1748 | So I tried delaying the check for reftest-wait and amazingly got a bunch of intermittents. So I'm going to land this version for now. | |