1638407 - [wpt-sync] Sync PR 23641 - sensors: Make frequency hint test wait for another slow sensor "tick".

Status: RESOLVED FIXED

(Testing :: web-platform-tests, task, P4)

Description

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Sync web-platform-tests PR 23641 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/23641
Details from upstream follow.

Raphael Kubo da Costa <[e-mail]> wrote:

sensors: Make frequency hint test wait for another slow sensor "tick".

This test was flaky, especially on the Mac bots, where timers can often fire
with varying precision.

SensorProxy uses an ObserverSet to store Sensor instances that need to be
notified of a reading, so in some cases we could end up with the following
sequence of notifications in C++ and JavaScript:

1. OnSensorReadingChanged() is called for the fast sensor (running at either
   10Hz or 60Hz).
2. A "reading" event is delivered to the fast sensor's event handler in
   script.
3. OnSensorReadingChanged() is called for the slow sensor (running at 1/4th
   of the fast sensor's frequency).
4. A "reading" event is delivered to the slow sensor's event handler in
   script.
5. OnSensorReadingChanged() is called for the slow sensor again, but it is
   too early so it posts a delayed task to call NotifyReading().
6. OnSensorReadingChanged() is called for the fast sensor.
7. A "reading" event is delivered to the fast sensor's event handler in
   script.
8. The delayed task is executed, and a "reading" event is delivered to the
   slow sensor's event handler in script.

At this point, both |slowSensorNotifierCounter| and
|fastSensorNotifierCounter| are set to 2, and the assertion in the test
fails.

Fix it by waiting for another "reading" event to be delivered to the slow
sensor. Given the frequencies we choose, at this point a working
implementation's |fastSensorNotifierCounter| will definitely be higher than
2.

The downside is that we slow down the test by the value of another sensor
period -- for regular sensors, that is around 0.016s, while for slower
sensors such as AmbientLightSensor and Magnetometer (capped at 10Hz) this is
a 0.4s slowdown.

Bug: 731018
Change-Id: I249ab88eccf316888177a93614c2955b516bc835
Reviewed-on: https://chromium-review.googlesource.com/2204023
WPT-Export-Revision: 929bf20ac0e22b8e090668ca2b2b626acfee4f82

Comment 1

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

PR 23641 applied with additional changes from upstream: 257af6a7bd889bf588a438d70f6f01fed9fca66f, 823cca0c2c6b421912973e7f699a357411738c64

Comment 2

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Pushed to try (stability) https://treeherder.mozilla.org/#/jobs?repo=try&revision=cee306d59b2dbaa476c9397a3cce6ff9b16e8626

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/62e7b353c52c
[wpt PR 23641] - sensors: Make frequency hint test wait for another slow sensor "tick"., a=testonly
https://hg.mozilla.org/integration/autoland/rev/fc1ed2ceab30
[wpt PR 23641] - Update wpt metadata, a=testonly

Comment 4

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Test result changes from PR not available.

Comment 5

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/62e7b353c52c
https://hg.mozilla.org/mozilla-central/rev/fc1ed2ceab30