Update web-platform-tests to revision 9f01716569ae5dfd79675ea55718e48017d077a8

tests/wpt/web-platform-tests/docs/writing-tests/github-intro.md

@@ -249,7 +249,8 @@ GitHub UI.  Below is one method and others can be found on
 4. Wait for feedback on your pull request and once your pull request is
 accepted, delete your branch (see '[When Pull Request is Accepted](#cleanup)').
 
-That's it! Your pull request will go into a queue and will be reviewed soon.
+[This page on the submissions process](submission-process) has more detail
+about what to expect when contributing code to WPT.
 
 ## Refine
 

tests/wpt/web-platform-tests/docs/writing-tests/submission-process.md

@@ -1,28 +1,24 @@
 # Submitting Tests
 
-Test submission is via the typical [GitHub workflow][github flow]:
+Test submission is via the typical [GitHub workflow][github flow]. For detailed
+guidelines on setup and each of these steps, please refer to the [Github Test
+Submission](github-intro) documentation.
 
-* Fork the [GitHub repository][repo] (and make sure you're still relatively in
-sync with it if you forked a while ago)
+* Fork the [GitHub repository][repo].
 
-* Create a branch for your changes. Being a key of effective Git flow, it is
-strongly recommended that the **topic branch** tradition be followed here,
-i.e. the branch naming convention is based on the "topic" you will be working
-on, e.g. `git checkout -b topic-name`
+* Create a feature branch for your changes.
 
-* Make your changes
+* Make your changes.
 
 * Run the `lint` script in the root of your checkout to detect common
-  mistakes in test submissions. This will also be run after submission
-  and any errors will prevent your PR being accepted. If it detects an
-  error that forms an essential part of your test, edit the list of
-  exceptions stored in `tools/lint/lint.whitelist`.
+  mistakes in test submissions. There is [detailed documentation for the lint
+  tool](lint-tool).
 
 * Commit your changes.
 
 * Push your local branch to your GitHub repository.
 
-* Using the GitHub UI create a Pull Request for your branch.
+* Using the GitHub UI, create a Pull Request for your branch.
 
 * When you get review comments, make more commits to your branch to
   address the comments.
@@ -30,8 +26,9 @@ on, e.g. `git checkout -b topic-name`
 * Once everything is reviewed and all issues are addressed, your pull
   request will be automatically merged.
 
-For detailed guidelines on setup and each of these steps, please refer to the
-[Github Test Submission](../writing-tests/github-intro) documentation.
+We can sometimes take a little while to go through pull requests because we
+have to go through all the tests and ensure that they match the specification
+correctly. But we look at all of them, and take everything that we can.
 
 Hop on to the [mailing list][public-test-infra] or [IRC][]
 ([webclient][web irc], join channel `#testing`) if you have an issue.  There is

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

@@ -297,6 +297,11 @@ only takes `actual` and `description` as arguments.
 The description parameter is used to present more useful error messages when
 a test fails.
 
+When assertions are violated, they throw a runtime exception. This interrupts
+test execution, so subsequent statements are not evaluated. A given test can
+only fail due to one such violation, so if you would like to assert multiple
+behaviors independently, you should use multiple tests.
+
 NOTE: All asserts must be located in a `test()` or a step of an
 `async_test()`, unless the test is a single page test. Asserts outside
 these places won't be detected correctly by the harness and may cause
@@ -802,6 +807,24 @@ asserts that one `assert_func(actual, expected_array_N, extra_arg1, ..., extra_a
   allows multiple behaviours. Test authors should not use this method simply to hide
   UA bugs.
 
+## Formatting ##
+
+When many JavaScript Object values are coerced to a String, the resulting value
+will be `"[object Object]"`. This obscures helpful information, making the
+coerced value unsuitable for use in assertion messages, test names, and
+debugging statements.
+
+testharness.js provides a global function named `format_value` which produces
+more distinctive string representations of many kinds of objects, including
+arrays and the more important DOM Node types. It also translates String values
+containing control characters to include human-readable representations.
+
+```js
+format_value(document); // "Document node with 2 children"
+format_value("foo\uffffbar"); // "\"foo\\uffffbar\""
+format_value([-0, Infinity]); // "[-0, Infinity]"
+```
+
 ## Metadata ##
 
 It is possible to add optional metadata to tests; this can be done in