Closed Bug 1438319 Opened 2 years ago Closed 2 years ago

[wpt-sync] PR 9524 - Fix timeouts in WPT AudioParam tests


(Core :: Web Audio, enhancement, P2)




Tracking Status
firefox61 --- fixed


(Reporter: wptsync, Unassigned)



(Whiteboard: [wptsync downstream])

Replace the tests that are using ScriptProcessor and online contexts
with an offline context and verify all the output values instead of
just one.

This change exposed a couple of issues:
  - setTargetAtTime wasn't actually testing setTargetAtTime because a
    linearRampToValueAtTime event was called at the same time,
    effectively replacing the setTargetAtTime event
  - linearRampToValue and exponentialRampToValue tests expose bugs in
    Chrome's implementation of these when the event is scheduled in
    the past, and there is no preceding event.

Bug: 812285, 626703
Change-Id: Iad3f54dd4373411431c019de44d4c3bad07587ff
WPT-Export-Revision: e6e307aa145bb763db9143cf52b57ae2bafa2be8
Component: web-platform-tests → Web Audio
Product: Testing → Core
Ran 5 tests and 10 subtests
PASS   : 10
ERROR  : 5

These tests have a worse result after import (e.g. they used to PASS and now FAIL)
/webaudio/the-audio-api/the-audioparam-interface/retrospective-exponentialRampToValueAtTime.html: ERROR
/webaudio/the-audio-api/the-audioparam-interface/retrospective-linearRampToValueAtTime.html: ERROR
/webaudio/the-audio-api/the-audioparam-interface/retrospective-setTargetAtTime.html: ERROR
/webaudio/the-audio-api/the-audioparam-interface/retrospective-setValueAtTime.html: ERROR
/webaudio/the-audio-api/the-audioparam-interface/retrospective-setValueCurveAtTime.html: ERROR
Rank: 19
Priority: -- → P2
Alex, would you mind doing first pass triage on this?
Rank: 19 → 18
Flags: needinfo?(achronop)
(In reply to Web Platform Test Sync Bot from comment #3)
> These tests have a worse result after import (e.g. they used to PASS and now

Does it mean we are not ready to import this one?
Flags: needinfo?(achronop)
Pushed by
[wpt PR 9524] - Fix timeouts in WPT AudioParam tests, a=testonly
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Is there a process to leave open bugs when tests that were passing start to fail when other browser vendors replace the tests with different test designs that now fail in Gecko?

The change essentially means that Gecko has no test coverage for a feature, because the tests now depend on an unrelated feature that Mozilla does not intend to support.

This is a major discouragement wrt moving Gecko tests to wpt if other vendors are essentially going to remove the tests. indicates that Google have replaced the test because the removed version exposed bugs in their implementation and would not work in their harness.
Flags: needinfo?(james)
We could start to create bugs where test results get worse; there is an open issue on the wpt-sync repo for that.

In this specific case it seems like you need to doone of two things:
* Talk to the Google engineers and come up with a solution that you're all happy with.
* Revert the changes, possibly by adding duplicate tests.

The first option seems prefereable.

There's no reason that Google's requirements should get priority over what we require; indeed doing so explicitly negates the point of the tests. Having said that, if there's a conflict we have to work together to figure out what to do about it.
Flags: needinfo?(james)
Depends on: 1478837
You need to log in before you can comment on or make changes to this bug.