On Fri, Mar 15, 2024 at 6:42 PM Raphael Kubo da Costa < raphael.kubo.da.co...@intel.com> wrote:
> Philip Jägenstedt <foo...@chromium.org> writes: > > > Taking a closer look, I think it's really because the tests depend on > > MojoJS, and if we exclude tentative tests > > < > https://wpt.fyi/results/compute-pressure?label=master&label=experimental&aligned&q=%21is%3Atentative > > > > only > > surface level tests remain. > > > > Compute Pressure tests were mentioned in > > https://github.com/web-platform-tests/rfcs/issues/172 and my read is > that > > Apple and Mozilla would prefer that we not upstream tests that depend on > > unspecified testing APIs. > > Thanks for bringing this up, I wasn't aware of this discussion in the > rfcs repository. We went with MojoJS because it was the easiest option > while the API and the implementation were changing rapidly. And because > in the past (for better or worse) other APIs depending on MojoJS had > been added to WPT, we just went ahead with what felt like the usual and > landed those tests in WPT too. > > > I'd suggest one of the following: > > > > - Define a WebDriver Classic endpoint in the style of > > https://w3c.github.io/sensors/#automation > > - Define a WebDriver BiDi command in the style of > > https://w3c.github.io/permissions/#automation-webdriver-bidi > > - Define a testing API in the style of > > https://wicg.github.io/webusb/test/ > > - Move the tests to wpt_internal (meaning much fewer shared tests for > a > > second implementer) > > > > What do you think makes the most sense here? > > The quickest solution is to just move all web tests that currently > depend on MojoJS to wpt_internal. > > A WebDriver Classic endpoint is what we'd need next. We've got > experience with that (in fact, in the past few months I've added > WebDriver endpoints to the Generic Sensor and Device Orientation specs > and removed the dependency that their web tests in WPT had on MojoJS), > and there are plans to add some DevTools support for Compute Pressure in > the not too distant future that would help with it too. > > Would going with the options above block the shipping process somehow? > The current web tests work and offer good coverage of the > implementation, they just aren't as interoperable as they should. > LGTM1 I don't want to block shipping on this :) LGTM assumes that https://github.com/w3c/compute-pressure/issues/253 is resolved in some way, I'm not insisting on any particular outcome. And that tests are moved into wpt_internal some time soon, but that could happen after branch point. It would be fantastic if you also want to do the work to allow adding the tests back to WPT, but at present we're not requiring shared tests when it requires new test infrastructure. I would certainly like to move in that direction, but would like to wait for WebDriver BiDi integration into testharness.js before that feels like a reasonable ask for all or most features. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYczFYrzzMWwv3p0H-uT_NdeN5TNzrqDkmff5ciWpHnqaw%40mail.gmail.com.
