Update web-platform-tests to revision 8a2ceb5f18911302b7a5c1cd2791f4ab50ad4326

tests/wpt/web-platform-tests/docs/.ruby-version

@@ -1 +1 @@
-ruby-2.3.3
+ruby-2.4.0

tests/wpt/web-platform-tests/docs/OWNERS

@@ -1,4 +1,3 @@
 @sideshowbarker
 @dontcallmedom
-@zcorpan
 @gsnedders

tests/wpt/web-platform-tests/docs/_running-tests/index.md

@@ -7,7 +7,28 @@ in a browser window. For running larger groups of tests, or running
 tests frequently, this is not a practical approach and several better
 options exist.
 
+## From the Command Line
+
+The simplest way to run tests is to use the `wpt run` command from the
+root of the repository. This will automatically load the tests in the
+chosen browser, and extract the test results. For example to run the
+`dom/historical.html` tests in a local copy of Chrome:
+
+    ./wpt run chrome dom/historical.html
+
+Or to run in a specified copy of Firefox:
+
+    ./wpt run --binary ~/local/firefox/firefox firefox dom/historical.html
+
+On Windows `edge` is also supported, and if you have a sauce labs
+account, any browser can be run using product `sauce`. For details on
+how to pass information to sauce, including credentials see `./wpt run
+--help`. That also details a large number of other options for
+customising the test run.
+
+
 ## From Inside a Browser
+Tests that have been merged on GitHub are mirrored at [http://w3c-test.org/].
 
 For running multiple tests inside a browser, there is a test runner
 located at `/tools/runner/index.html`.
@@ -24,27 +45,13 @@ more than one reference involved.
 Because it runs entirely in-browser, this runner cannot deal with
 edge-cases like tests that cause the browser to crash or hang.
 
-## By Automating the Browser
-
-For automated test running designed to be robust enough to use in a CI
-environment, the [wptrunner](https://github.com/w3c/wptrunner) test runner
-can be used. This is a test runner written in Python and designed to
-control the browser from the outside using some remote control
-protocol such as WebDriver. This allows it to handle cases such as the
-browser crashing that cannot be handled by an in-browser harness. It
-also has the ability to automatically run both testharness-based tests
-and reftests.
-
-Full instructions for using wptrunner are provided in its own
-[documentation](https://wptrunner.readthedocs.org).
-
 ## Writing Your Own Runner
 
 Most test runners have two stages: finding all tests, followed by
 executing them (or a subset thereof).
 
 To find all tests in the repository, it is **strongly** recommended to
-use the included `manifest` tool: the required behaviors are more
+use the included `wpt manifest` tool: the required behaviors are more
 complex than what are documented (especially when it comes to
 precedence of the various possibilities and some undocumented legacy
 ways to define test types), and hence its behavior should be

tests/wpt/web-platform-tests/docs/_writing-tests/ahem.md

@@ -86,4 +86,4 @@ On Linux, copy the file to `~/.local/share/fonts` and then run
 `fc-cache`.
 
 [ahem-readme]: https://www.w3.org/Style/CSS/Test/Fonts/Ahem/README
-[download-ahem]: https://www.w3.org/Style/CSS/Test/Fonts/Ahem/AHEM____.TTF
+[download-ahem]: https://github.com/w3c/web-platform-tests/raw/master/fonts/Ahem.ttf

tests/wpt/web-platform-tests/docs/_writing-tests/file-names.md

@@ -0,0 +1,65 @@
+---
+layout: page
+title: File Name Flags
+order: 2
+---
+
+The test filename is significant in determining the type of test it
+contains, and enabling specific optional features. This page documents
+the various flags available and their meaning.
+
+
+### Test Type
+
+These flags must be the last element in the filename before the
+extension e.g. `foo-manual.html` will indicate a manual test, but
+`foo-manual-other.html` will not. Unlike test features, test types
+are mutually exclusive.
+
+
+`-manual`
+ : Indicates that a test is a non-automated test.
+
+`-support`
+ : Indicates that a file is not a test but a support file.  Not
+   required for files in a directory called `resources`, `tools` or
+   `support`.
+
+`-visual`
+ : Indicates that a file is a visual test.
+
+
+### Test Features
+
+These flags are preceded by a `.` in the filename, and must
+themselves precede any test type flag, but are otherwise unordered.
+
+
+`.https`
+ : Indicates that a test is loaded over HTTPS.
+
+`.sub`
+ : Indicates that a test uses the [server-side substitution][]
+   feature.
+
+`.window`
+ : (js files only) Indicates that the file generates a test in which
+    it is run in a Window environment.
+
+`.worker`
+ : (js files only) Indicates that the file generates a test in which
+    it is run in a dedicated worker environment.
+
+`.any`
+ : (js files only) Indicates that the file generates tests in which it
+    is run in Window and dedicated worker environments.
+
+`.tentative`
+ : Indicates that a test makes assertions not yet required by any specification,
+   or in contradiction to some specification. This is useful when implementation
+   experience is needed to inform the specification. It should be apparent in
+   context why the test is tentative and what needs to be resolved to make it
+   non-tentative.
+
+
+[server-side substitution]: https://wptserve.readthedocs.io/en/latest/pipes.html#sub

tests/wpt/web-platform-tests/docs/_writing-tests/general-guidelines.md

@@ -25,14 +25,24 @@ integer that follows is normally just increased incrementally, and
 padded to three digits. (If you'd end up with more than 999 tests,
 your `test-topic` is probably too broad!)
 
-In csswg-test, the file names should be unique within the repository,
-regardless of where they are in the directory structure.
+The test filename is significant in enabling specific optional features, such as HTTPS
+or server-side substitution. See the documentation on [file names flags][file-name-flags]
+for more details.
 
+In the css directory, the file names should be unique within the whole
+css/ directory, regardless of where they are in the directory structure.
+
+### HTTPS
+
+By default, tests are served over plain HTTP. If a test requires HTTPS
+it must be given a filename containing `.https` before the extension,
+e.g. `test-secure.https.html`. For more details see the documentation
+on [file names][file-name-flags].
 
 #### Support Files
 
 Various support files are available in in the `/common/` and `/media/`
-directories (web-platform-tests) and `/support/` (csswg-test). Reusing
+directories (web-platform-tests) and `/support/` (in css/). Reusing
 existing resources is encouraged where possible, as is adding
 generally useful files to these common areas rather than to specific
 testsuites.
@@ -138,17 +148,16 @@ not uniformly enforced throughout the existing tests, but will be for
 new tests. Any of these rules may be broken if the test demands it:
 
  * No trailing whitespace
-
  * Use spaces rather than tabs for indentation
-
- * Use UNIX-style line endings (i.e. no CR characters at EOL).
+ * Use UNIX-style line endings (i.e. no CR characters at EOL)
 
 We have a lint tool for catching these and other common mistakes. You
-can run it manually by starting the `lint` executable from the root of
-your local web-platform-tests working directory like this:
+can run it manually by starting the `wpt` executable from the root of
+your local web-platform-tests working directory, and invoking the
+`lint` subcommand, like this:
 
 ```
-./lint
+./wpt lint
 ```
 
 The lint tool is also run automatically for every submitted pull request,
@@ -178,3 +187,4 @@ for CSS have some additional requirements for:
 [lint-tool]: {{ site.baseurl }}{% link _writing-tests/lint-tool.md %}
 [css-metadata]: {{ site.baseurl }}{% link _writing-tests/css-metadata.md %}
 [css-user-styles]: {{ site.baseurl }}{% link _writing-tests/css-user-styles.md %}
+[file-name-flags]: {{ site.baseurl }}{% link _writing-tests/file-names.md %}

tests/wpt/web-platform-tests/docs/_writing-tests/idlharness.md

@@ -26,7 +26,11 @@ var s = "";
   //https://www.w3.org/Bugs/Public/show_bug.cgi?id=14914
   if (!idl.classList.contains("extract"))
   {
-    s += idl.textContent + "\n\n";
+    if (s !== "")
+    {
+      s += "\n\n";
+    }
+    s += idl.textContent.replace(/ +$/mg, "");
   }
 });
 document.body.innerHTML = '<pre></pre>';

tests/wpt/web-platform-tests/docs/_writing-tests/lint-tool.md

@@ -4,11 +4,11 @@ title: Lint Tool
 order: 9
 ---
 We have a lint tool for catching common mistakes in test files. You can run
-it manually by starting the `lint` executable from the root of your local
+it manually by running the `wpt lint` command from the root of your local
 web-platform-tests working directory like this:
 
 ```
-./lint
+./wpt lint
 ```
 
 The lint tool is also run automatically for every submitted pull request,
@@ -37,6 +37,9 @@ below to fix all errors reported.
   `<script src='/resources/testharnessreport.js'>` prior to
   `<script src='/resources/testharness.js'>`; **fix**: flip the order.
 
+* **GENERATE_TESTS**: Test file line has a generate_tests call; **fix**: remove
+  the call and call `test()` a number of times instead.
+
 * **INDENT TABS**: Test-file line starts with one or more tab characters;
   **fix**: use spaces to replace any tab characters at beginning of lines.
 
@@ -48,6 +51,9 @@ below to fix all errors reported.
   `<script src='/resources/testharnessreport.js'>` element ; **fix**: move
   the `<meta name="timeout"...>` element to precede the `script` element.
 
+* **LAYOUTTESTS APIS**: Test file uses `eventSender`, `testRunner`, or
+  `window.internals` which are LayoutTests-specific APIs used in WebKit/Blink.
+
 * **MALFORMED-VARIANT**: Test file with a `<meta name='variant'...>`
   element whose `content` attribute has a malformed value; **fix**: ensure
   the value of the `content` attribute starts with `?` or `#` or is empty.

tests/wpt/web-platform-tests/docs/_writing-tests/server-features.md

@@ -8,7 +8,7 @@ order: 12
 
 Certain test scenarios require more than just static HTML
 generation. This is supported through the
-[wptserve](https://github.com/w3c/wptserve) server. Several scenarios
+[wptserve](http://wptserve.readthedocs.io) server. Several scenarios
 in particular are common:
 
 

tests/wpt/web-platform-tests/docs/_writing-tests/testharness-api.md

@@ -261,7 +261,7 @@ tests".
 In order for a test to be interpreted as a single page test, then
 it must simply not call `test()` or `async_test()` anywhere on the page, and
 must call the `done()` function to indicate that the test is complete. All
-the `assert_*` functions are avaliable as normal, but are called without
+the `assert_*` functions are available as normal, but are called without
 the normal step function wrapper. For example:
 
 ```html
@@ -281,7 +281,7 @@ The test title for single page tests is always taken from `document.title`.
 ## Making assertions ##
 
 Functions for making assertions start `assert_`. The full list of
-asserts avaliable is documented in the [asserts](#list-of-assertions) section
+asserts available is documented in the [asserts](#list-of-assertions) section
 below. The general signature is:
 
 ```js
@@ -428,7 +428,7 @@ event in a document. Therefore these worker tests always behave as if the
 event which is fired following the completion of [running the
 worker](https://html.spec.whatwg.org/multipage/workers.html#run-a-worker).
 
-## Generating tests ##
+## **DEPRECATED** Generating tests ##
 
 There are scenarios in which is is desirable to create a large number of
 (synchronous) tests that are internally similar but vary in the parameters
@@ -451,8 +451,14 @@ generate_tests(assert_equals, [
 Is equivalent to:
 
 ```js
-test(function() {assert_equals(1+1, 2)}, "Sum one and one")
-test(function() {assert_equals(1+0, 1)}, "Sum one and zero")
+var a_got = 1+1;
+var a_exp = 2;
+var a_nam = "Sum one and one";
+var b_got = 1+0;
+var b_exp = 1;
+var b_nam = "Sum one and zero";
+test(function() {assert_equals(a_got, a_exp)}, a_nam);
+test(function() {assert_equals(b_got, b_exp)}, b_nam);
 ```
 
 Note that the first item in each parameter list corresponds to the name of
@@ -461,6 +467,11 @@ the test.
 The properties argument is identical to that for `test()`. This may be a
 single object (used for all generated tests) or an array.
 
+This is deprecated because it runs all the tests outside of the test functions
+and as a result any test throwing an exception will result in no tests being
+run. In almost all cases, you should simply call test within the loop you would
+use to generate the parameter list array.
+
 ## Callback API ##
 
 The framework provides callbacks corresponding to 4 events:
@@ -594,7 +605,7 @@ workers](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/).
 Testing from a worker script is different from testing from an HTML document in
 several ways:
 
-* Workers have no reporting capability since they are runing in the background.
+* Workers have no reporting capability since they are running in the background.
   Hence they rely on `testharness.js` running in a companion client HTML document
   for reporting.
 
@@ -683,6 +694,11 @@ asserts that `actual` and `expected` have the same
 length and the value of each indexed property in `actual` is the strictly equal
 to the corresponding property value in `expected`
 
+### `assert_array_approx_equals(actual, expected, epsilon, description)`
+asserts that `actual` and `expected` have the same
+length and each indexed property in `actual` is a number
+within ±`epsilon` of the corresponding property in `expected`
+
 ### `assert_approx_equals(actual, expected, epsilon, description)`
 asserts that `actual` is a number within ±`epsilon` of `expected`
 

tests/wpt/web-platform-tests/docs/introduction.md

@@ -74,7 +74,7 @@ The testsuite has a few types of tests, outlined below:
 
 ## GitHub
 
-GitHub is used both for issue tracking and test submissions; we
+[GitHub](https://github.com/w3c/web-platform-tests/) is used both for [issue tracking](https://github.com/w3c/web-platform-tests/issues) and [test submissions](https://github.com/w3c/web-platform-tests/pulls); we
 provide [a limited introduction][github-intro] to both git and
 GitHub.