Closed Bug 1438319 Opened 2 years ago Closed 2 years ago
[wpt-sync] PR 9524 - Fix timeouts in WPT Audio
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 Reviewed-on: https://chromium-review.googlesource.com/919151 WPT-Export-Revision: e6e307aa145bb763db9143cf52b57ae2bafa2be8
Component: web-platform-tests → Web Audio
Product: Testing → Core
Pushed to try (stability) https://treeherder.mozilla.org/#/jobs?repo=try&revision=c4828c64632ba1602080a984cb79a050efd7886d
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
Alex, would you mind doing first pass triage on this?
Rank: 19 → 18
(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 > FAIL) Does it mean we are not ready to import this one?
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/762b46786b94 [wpt PR 9524] - Fix timeouts in WPT AudioParam tests, a=testonly
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. https://bugs.chromium.org/p/chromium/issues/detail?id=812285 indicates that Google have replaced the test because the removed version exposed bugs in their implementation and would not work in their harness.
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.
You need to log in before you can comment on or make changes to this bug.