Migrate WebUSB LayoutTests into external/wpt

third_party/WebKit/LayoutTests/external/wpt/webusb/resources/usb-helpers.js

 'use strict';
 
 function usb_test(func, name, properties) {
   promise_test(() => {
     return navigator.usb.test.initialize().then(() => {
       let testResult = func();
       let cleanup = () => {
         navigator.usb.test.reset();
       };
       testResult.then(cleanup, cleanup);
@@ skipping 24 matching lines @@
     } else if (Array.isArray(deviceInit[property])) {
       assert_equals(usbDevice[property].length, deviceInit[property].length);
       for (var i = 0; i < usbDevice[property].length; ++i)
         assertDeviceInfoEquals(usbDevice[property][i], deviceInit[property][i]);
     } else {
       assert_equals(usbDevice[property], deviceInit[property], property);
     }
   }
 }
 
 // TODO(reillyg): Remove when jyasskin upstreams this to testharness.js:

[ortuno, 2017/04/03 01:47:19]

I don't think we can upstream yet because of this TODO.

nzolghadr: How far along is the input injection test API?

[Navid Zolghadr, 2017/04/03 14:24:34]

I'm trying to push it through this PR.
https://github.com/w3c/testharness.js/pull/251

Although I didn't have any API for injecting key inputs as we don't have any way
of injecting it before IME. eventSender sends it after those filters and does
not test the whole pipeline. I'll talk about it with others and consider adding
a key injection API as well. I'm hoping to get it in by the end of this week.
But again I'm trying to convince people to have something like this there.

However, I'd like to unblock you guys as soon as I can. Maybe I can explain a
little better in a meeting. But would a structure similar to what we have in wpt
tests right now help?

https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/external/...

We also need some input from users and for now those tests are ending with
"-manual" in their name. Then we are using our Chrome APIs to automate them
through those "-automation.js" files on our bots.

[ortuno, 2017/04/03 23:22:30]

We don't necessarily need injecting key inputs. The current API as proposed
should be enough.
I would like to avoid having a "-manual" suffix for pretty much all of our
tests. Many new APIs require a user gesture which means that every single one of
our tests would end up with a "-manual" suffix. Ideally the API would just be
there or fail gracefully. For instance Bluetooth has 200+ tests, most of which
require a user gesture. Adding "-manual" to them would just generate noise.

[foolip, 2017/04/05 06:03:32]

It looks like all the calls to callWithKeyDown() were removed in this CL, at
least it looks like that when searching the raw diff. Are there other parts of
the helpers that are unused and can be removed?

[Reilly Grant (use Gerrit), 2017/04/05 18:39:37]

callWithKeyDown() is used when testing navigator.usb.requestDevice(). This is
only done in usb.https.html so I'm looking at making that a manual test and
using our existing automation scripts.

 // https://crbug.com/509058.
 function callWithKeyDown(functionCalledOnKeyPress) {
   return new Promise(resolve => {
     function onKeyPress() {
       document.removeEventListener('keypress', onKeyPress, false);
       resolve(functionCalledOnKeyPress());
     }
     document.addEventListener('keypress', onKeyPress, false);
 
     eventSender.keyDown(' ', []);
   });
 }
 
 function runGarbageCollection() {

[ortuno, 2017/04/03 01:47:19]

This is also Chromium specific. I think we will have to keep tests that use this
downstream for now and block their upstreaming on a standard GC Test API, which
might be a long shot. I can already imagine people arguing against it on the
premise that this types of tests should really be unit tests rather than Layout
Tests.

[Reilly Grant (use Gerrit), 2017/04/05 18:39:37]

I've moved the one test that used this back to LayoutTests/usb.

   // Run gc() as a promise.
   return new Promise((resolve, reject) => {
     GCController.collect();
     setTimeout(resolve, 0);
   });
 }