BASELINE: Update Chromium to 61.0.3163.99

Change-Id: I8452f34574d88ca2b27af9bd56fc9ff3f16b1367
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>

3 files changed, 158 insertions, 44 deletions

diff --git a/chromium/docs/testing/layout_test_expectations.md b/chromium/docs/testing/layout_test_expectations.md
index 53545442206..2023fbd0326 100644
--- a/chromium/docs/testing/layout_test_expectations.md
+++ b/chromium/docs/testing/layout_test_expectations.md
@@ -90,21 +90,28 @@ platforms.
 ### Rebaselining using try jobs
 
 The recommended way to rebaseline for a currently-in-progress CL is to use
-results from try jobs. To do this:
-
-1. Upload a CL with changes in Blink source code or layout tests.
-2. Trigger Blink try jobs. The bots to use are the release builders on
+results from try jobs, by using the command-tool
+`third_party/WebKit/Tools/Scripts/webkit-patch rebaseline-cl`:
+
+1. First, upload a CL.
+   There is no need to add `[ NeedsRebaseline ]` lines in TestExpectations for
+   tests that are rebaselined by this method.
+2. Trigger try jobs by running `webkit-patch rebaseline-cl`. This should
+   trigger jobs on
    [tryserver.blink](https://build.chromium.org/p/tryserver.blink/builders).
-   This can be done via the code review Web UI or via `git cl try`.
 3. Wait for all try jobs to finish.
-4. Run `third_party/WebKit/Tools/Scripts/webkit-patch rebaseline-cl` to fetch
-   new baselines.
+4. Run `webkit-patch rebaseline-cl` again to fetch new baselines.
+   By default, this will download new baselines for any failing tests
+   in the try jobs.
+   (Run `webkit-patch rebaseline-cl --help` for more specific options.)
 5. Commit the new baselines and upload a new patch.
 
 This way, the new baselines can be reviewed along with the changes, which helps
 the reviewer verify that the new baselines are correct. It also means that there
 is no period of time when the layout test results are ignored.
 
+#### Options
+
 The tests which `webkit-patch rebaseline-cl` tries to download new baselines for
 depends on its arguments.
 
@@ -114,6 +121,9 @@ depends on its arguments.
   considered.
 * You can also explicitly pass a list of test names, and then just those tests
   will be rebaselined.
+* If some of the try jobs failed to run, and you wish to continue rebaselining
+  assuming that there are no platform-specific results for those platforms,
+  you can add the flag `--fill-missing`.
 
 ### Rebaselining with rebaseline-o-matic
 
diff --git a/chromium/docs/testing/layout_tests.md b/chromium/docs/testing/layout_tests.md
index c6d57e271e3..f89bcd7b931 100644
--- a/chromium/docs/testing/layout_tests.md
+++ b/chromium/docs/testing/layout_tests.md
@@ -153,8 +153,7 @@ to see a full list of options. A few of the most useful options are below:
 | `--nocheck-sys-deps`        | Don't check system dependencies; this allows faster iteration. |
 | `--verbose`                 |	Produce more verbose output, including a list of tests that pass. |
 | `--no-pixel-tests`          | Disable the pixel-to-pixel PNG comparisons and image checksums for tests that don't call `testRunner.dumpAsText()` |
-| `--reset-results`           |	Write all generated results directly into the given directory, overwriting what's there. |
-| `--new-baseline`            |	Write all generated results into the most specific platform directory, overwriting what's there. Equivalent to `--reset-results --add-platform-expectations` |
+| `--reset-results`           |	Overwrite the current baselines (`-expected.{png|txt|wav}` files) with actual results, or create new baselines if there are no existing baselines. |
 | `--renderer-startup-dialog` | Bring up a modal dialog before running the test, useful for attaching a debugger. |
 | `--fully-parallel`          | Run tests in parallel using as many child processes as the system has cores. |
 | `--driver-logging`          | Print C++ logs (LOG(WARNING), etc).  |
@@ -427,40 +426,105 @@ machine?
 * In the loaded devtools, set any required breakpoints and execute `test()` in
   the console to actually start the test.
 
+## Bisecting Regressions
+
+You can use [`git bisect`](https://git-scm.com/docs/git-bisect) to find which
+commit broke (or fixed!) a layout test in a fully automated way.  Unlike
+[bisect-builds.py](http://dev.chromium.org/developers/bisect-builds-py), which
+downloads pre-built Chromium binaries, `git bisect` operates on your local
+checkout, so it can run tests with `content_shell`.
+
+Bisecting can take several hours, but since it is fully automated you can leave
+it running overnight and view the results the next day.
+
+To set up an automated bisect of a layout test regression, create a script like
+this:
+
+```
+#!/bin/bash
+
+# Exit code 125 tells git bisect to skip the revision.
+gclient sync || exit 125
+ninja -C out/Debug -j100 blink_tests || exit 125
+
+blink/tools/run_layout_tests.sh -t Debug \
+  --no-show-results --no-retry-failures \
+  path/to/layout/test.html
+```
+
+Modify the `out` directory, ninja args, and test name as appropriate, and save
+the script in `~/checkrev.sh`.  Then run:
+
+```
+chmod u+x ~/checkrev.sh  # mark script as executable
+git bisect start <badrev> <goodrev>
+git bisect run ~/checkrev.sh
+git bisect reset  # quit the bisect session
+```
+
 ## Rebaselining Layout Tests
 
 *** promo
 To automatically re-baseline tests across all Chromium platforms, using the
-buildbot results, see the
-[Rebaselining keywords in TestExpectations](./layout_test_expectations.md)
-and the
-[Rebaselining Tool](https://trac.webkit.org/wiki/Rebaseline).
+buildbot results, see [How to rebaseline](./layout_test_expectations.md#How-to-rebaseline).
 Alternatively, to manually run and test and rebaseline it on your workstation,
 read on.
 ***
 
-By default, text-only tests (ones that call `testRunner.dumpAsText()`) produce
-only text results. Other tests produce both new text results and new image
-results (the image baseline comprises two files, `-expected.png` and
-  `-expected.checksum`). So you'll need either one or three `-expected.\*` files
-in your new baseline, depending on whether you have a text-only test or not. If
-you enable `--no-pixel-tests`, only new text results will be produced, even for
-tests that do image comparisons.
-
 ```bash
 cd src/third_party/WebKit
-Tools/Scripts/run-webkit-tests --new-baseline foo/bar/test.html
+Tools/Scripts/run-webkit-tests --reset-results foo/bar/test.html
 ```
 
-The above command will generate a new baseline for
-`LayoutTests/foo/bar/test.html` and put the output files in the right place,
-e.g.
-`LayoutTests/platform/chromium-win/LayoutTests/foo/bar/test-expected.{txt,png,checksum}`.
+If there are current expectation files for `LayoutTests/foo/bar/test.html`,
+the above command will overwrite the current baselines at their original
+locations with the actual results. The current baseline means the `-expected.*`
+file used to compare the actual result when the test is run locally, i.e. the
+first file found in the [baseline search path]
+(https://cs.chromium.org/search/?q=port/base.py+baseline_search_path).
+
+If there are no current baselines, the above command will create new baselines
+in the platform-independent directory, e.g.
+`LayoutTests/foo/bar/test-expected.{txt,png}`.
 
 When you rebaseline a test, make sure your commit description explains why the
-test is being re-baselined. If this is a special case (i.e., something we've
-decided to be different with upstream), please put a README file next to the new
-expected output explaining the difference.
+test is being re-baselined.
+
+### Rebaselining flag-specific expectations
+
+Though we prefer the Rebaseline Tool to local rebaselining, the Rebaseline Tool
+doesn't support rebaselining flag-specific expectations.
+
+```bash
+cd src/third_party/WebKit
+Tools/Script/run-webkit-tests --additional-driver-flag=--enable-flag --new-flag-specific-baseline foo/bar/test.html
+```
+
+New baselines will be created in the flag-specific baselines directory, e.g.
+`LayoutTests/flag-specific/enable-flag/foo/bar/test-expected.{txt,png}`.
+
+Then you can commit the new baselines and upload the patch for review.
+
+However, it's difficult for reviewers to review the patch containing only new
+files. You can follow the steps below for easier review. The steps require a
+try bot already setup for the flag-specific tests (e.g.
+`linux_layout_tests_slimming_paint_v2` for `--enable-slimming-paint-v2`).
+
+1. Before the rebaseline, upload a patch for which the tests to be rebaselined
+   will fail. If the tests are expected to fail in
+   `LayoutTests/FlagExpectations/<flag>`, remove the failure expectation lines
+   in the patch.
+
+2. Schedule a try job on the try bot for the flag.
+
+3. Rebaseline locally, and upload a new version of patch containing the new
+   baselines to the same CL.
+
+4. After the try job finishes, request review of the CL and tell the reviewer
+   the URL of the `layout_test_result` link under the `archive_webkit_tests_results`
+   step of the try job. The reviewer should review the layout test result
+   assuming that the new baselines in the latest version of the CL are the same
+   as the actual results in the linked page.
 
 ## web-platform-tests
 
diff --git a/chromium/docs/testing/web_platform_tests.md b/chromium/docs/testing/web_platform_tests.md
index eec59f43200..36f2dae72e2 100644
--- a/chromium/docs/testing/web_platform_tests.md
+++ b/chromium/docs/testing/web_platform_tests.md
@@ -42,26 +42,59 @@ The easiest way to check the status of recent imports is to look at:
 -   Recent logs on Buildbot for [wpt-importer
     builder](https://build.chromium.org/p/chromium.infra.cron/builders/wpt-importer)
 -   Recent CLs created by
-    [blink-w3c-test-autoroller@chromium.org](https://codereview.chromium.org/search?owner=blink-w3c-test-autoroller%40chromium.org).
+    [blink-w3c-test-autoroller@chromium.org](https://chromium-review.googlesource.com/q/owner:blink-w3c-test-autoroller%40chromium.org).
 
 Automatic imports are intended to run at least once every 24 hours.
 
+### Failures caused by automatic imports.
+
+If there are new test failures that start after an auto-import,
+there are several possible causes, including:
+
+ 1. New baselines for flaky tests were added (http://crbug.com/701234).
+ 2. Modified tests should have new results for non-Release builds but they weren't added (http://crbug.com/725160).
+ 3. New baselines were added for tests with non-deterministic test results (http://crbug.com/705125).
+
+Because these tests are imported from the Web Platform tests, it is better
+to have them in the repository (and marked failing) than not, so prefer to
+[add test expectations](layout_test_expectations.md) rather than reverting.
+However, if a huge number of tests are failing, please revert the CL so we
+can fix it manually.
+
 ### Automatic export process
 
-If a commit to Chromium master changes any files in the
-[third_party/WebKit/LayoutTests/external/wpt](../../third_party/WebKit/LayoutTests/external/wpt)
-directory, the WPT Exporter will create a Pull Request on GitHub for it.
-All PRs use the `chromium-export` label: see
-[all of them here](https://github.com/w3c/web-platform-tests/pulls?utf8=%E2%9C%93&q=is%3Apr%20label%3Achromium-export).
-The exporter runs continuously under the chromium.infra.cron master:
-see [all recent builds](https://build.chromium.org/p/chromium.infra.cron/builders/wpt-exporter).
-The source for the exporter lives in
-[third_party/WebKit/Tools/Scripts/wpt-exporter](../../third_party/WebKit/Tools/Scripts/wpt-exporter).
-
-In the unlikely event that the exporter starts misbehaving -- for example,
-creating the same PR over and over again -- **all you need to do to disable the
-exporter is [land this CL](https://chromium-review.googlesource.com/c/462381/)**,
-which will put it in "dry run" mode.
+If you upload a CL with any changes in
+[third_party/WebKit/LayoutTests/external/wpt](../../third_party/WebKit/LayoutTests/external/wpt),
+once you add reviewers the exporter will create a provisional pull request with
+those changes in the [upstream WPT GitHub repository](https://github.com/w3c/web-platform-tests/).
+
+Once you're ready to land your CL, please check the Travis CI status on the
+upstream PR (link at the bottom of the page). If it's green, go ahead and land your CL
+and the exporter will automatically remove the "do not merge yet" label and merge the PR.
+
+If Travis CI is red on the upstream PR, please try to resolve the failures before
+merging. If you run into Travis CI issues, or if you have a CL with WPT changes that
+the exporter did not pick up, please reach out to ecosystem-infra@chromium.org.
+
+Additional things to note:
+
+-   CLs that change over 1000 files will not be exported.
+-   All PRs use the
+    [`chromium-export`](https://github.com/w3c/web-platform-tests/pulls?utf8=%E2%9C%93&q=is%3Apr%20label%3Achromium-export) label.
+-   All PRs for CLs that haven't yet been landed in Chromium also use the
+    [`do not merge yet`](https://github.com/w3c/web-platform-tests/pulls?q=is%3Apr+is%3Aopen+label%3A%22do+not+merge+yet%22) label.
+-   The exporter cannot create upstream PRs for in-flight CLs with binary files (e.g. webm files).
+    An export PR will still be made after the CL lands.
+
+For maintainers:
+
+-   The exporter runs continuously under the
+    [chromium.infra.cron master](https://build.chromium.org/p/chromium.infra.cron/builders/wpt-exporter).
+-   The source lives in
+    [third_party/WebKit/Tools/Scripts/wpt-exporter](../../third_party/WebKit/Tools/Scripts/wpt-exporter).
+-   If the exporter starts misbehaving
+    (for example, creating the same PR over and over again)
+    put it in "dry run" mode by landing [this CL](https://crrev.com/c/462381/).
 
 ### Skipped tests
 
@@ -134,9 +167,16 @@ APIs cannot yet be written as part of web-platform-tests.
 
 An alternative is to write manual tests that are automated with scripts from
 [wpt_automation](../../third_party/WebKit/LayoutTests/external/wpt_automation).
+Injection of JS in manual tests is determined by `loadAutomationScript` in
+[testharnessreport.js](../../third_party/WebKit/LayoutTests/resources/testharnessreport.js).
+
 Such tests still require case-by-case automation to run for other browser
 engines, but are more valuable than purely manual tests.
 
+Manual tests that have no automation are still imported, but skipped in
+[NeverFixTests](../../third_party/WebKit/LayoutTests/NeverFixTests); see
+[issue 738489](https://crbug.com/738489).
+
 *** note
 TODO(foolip): Figure out and document a more scalable test automation solution.
 ***