Fix some links in documentation related to layout tests.

docs/testing/layout_tests.md

 # Layout Tests
 
 Layout tests are used by Blink to test many components, including but not
 limited to layout and rendering. In general, layout tests involve loading pages
 in a test renderer (`content_shell`) and comparing the rendered output or
 JavaScript output against an expected output file.
 
 This document covers running and debugging existing layout tests. See the
 [Writing Layout Tests documentation](./writing_layout_tests.md) if you find
 yourself writing layout tests.
@@ skipping 166 matching lines @@
 ***
 
 A test that runs but produces the wrong output is marked as "failed", one that
 causes the test shell to crash is marked as "crashed", and one that takes longer
 than a certain amount of time to complete is aborted and marked as "timed out".
 A row of dots in the script's output indicates one or more tests that passed.
 
 ## Test expectations
 
 The
-[TestExpectations](../../WebKit/LayoutTests/TestExpectations) file (and related
-files, including
-[skia_test_expectations.txt](../../skia/skia_test_expectations.txt))
-contains the list of all known layout test failures. See the
+[TestExpectations](../../third_party/WebKit/LayoutTests/TestExpectations) file (and related
+files) contains the list of all known layout test failures. See the
 [Layout Test Expectations documentation](./layout_test_expectations.md) for more
 on this.
 
 ## Testing Runtime Flags
 
 There are two ways to run layout tests with additional command-line arguments:
 
 * Using `--additional-driver-flag`:
 
   ```bash
   run-webkit-tests --additional-driver-flag=--blocking-repaint
   ```
 
   This tells the test harness to pass `--blocking-repaint` to the
   content_shell binary.
 
   It will also look for flag-specific expectations in
   `LayoutTests/FlagExpectations/blocking-repaint`, if this file exists. The
   suppressions in this file override the main TestExpectations file.
 
 * Using a *virtual test suite* defined in
-  [LayoutTests/VirtualTestSuites](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/VirtualTestSuites).
+  [LayoutTests/VirtualTestSuites](../../third_party/WebKit/LayoutTests/VirtualTestSuites).
   A virtual test suite runs a subset of layout tests under a specific path with
   additional flags. For example, you could test a (hypothetical) new mode for
   repainting using the following virtual test suite:
 
   ```json
   {
     "prefix": "blocking_repaint",
     "base": "fast/repaint",
     "args": ["--blocking-repaint"],
   }
@@ skipping 94 matching lines @@
       produce a page including links to the expected result, actual result, and
       diff.
     * Add the `--sources` option to `run_webkit_tests.py` to see exactly which
       expected result it's comparing to (a file next to the test, something in
       platform/mac/, something in platform/chromium-win/, etc.)
     * If you're still sure it's correct, rebaseline the test (see below).
       Otherwise...
 * If you're lucky, your test is one that runs properly when you navigate to it
   in content_shell normally. In that case, build the Debug content_shell
   project, fire it up in your favorite debugger, and load the test file either
-  from a file:// URL.
+  from a `file:` URL.
     * You'll probably be starting and stopping the content_shell a lot. In VS,
       to save navigating to the test every time, you can set the URL to your
-      test (file: or http:) as the command argument in the Debugging section of
+      test (`file:` or `http:`) as the command argument in the Debugging section of
       the content_shell project Properties.
     * If your test contains a JS call, DOM manipulation, or other distinctive
       piece of code that you think is failing, search for that in the Chrome
       solution. That's a good place to put a starting breakpoint to start
       tracking down the issue.
     * Otherwise, you're running in a standard message loop just like in Chrome.
       If you have no other information, set a breakpoint on page load.
 * If your test only works in full layout-test mode, or if you find it simpler to
   debug without all the overhead of an interactive session, start the
   content_shell with the command-line flag `--run-layout-test`, followed by the
-  URL (file: or http:) to your test. More information about running layout tests
+  URL (`file:` or `http:`) to your test. More information about running layout tests
   in content_shell can be found [here](./layout_tests_in_content_shell.md).
     * In VS, you can do this in the Debugging section of the content_shell
       project Properties.
     * Now you're running with exactly the same API, theme, and other setup that
       the layout tests use.
     * Again, if your test contains a JS call, DOM manipulation, or other
       distinctive piece of code that you think is failing, search for that in
       the Chrome solution. That's a good place to put a starting breakpoint to
       start tracking down the issue.
     * If you can't find any better place to set a breakpoint, start at the
@@ skipping 65 matching lines @@
       `blink/tools/run_layout_tests.sh
       --additional_driver_flag='--remote-debugging-port=9222'
       --time-out-ms=6000000`
     * Option B) If you need to debug an http/tests/inspector test, start httpd
       as described above. Then, run content_shell:
       `out/Default/content_shell --remote-debugging-port=9222 --run-layout-test
       http://127.0.0.1:8000/path/to/test.html`
 * Open `http://localhost:9222` in a stable/beta/canary Chrome, click the single
   link to open the devtools with the test loaded.
 * You may need to replace devtools.html with inspector.html in your URL (or you
-  can use local chrome inspection of content_shell from chrome://inspect
+  can use local chrome inspection of content_shell from `chrome://inspect`
   instead)
 * In the loaded devtools, set any required breakpoints and execute `test()` in
   the console to actually start the test.
 
 ## 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)
@@ skipping 36 matching lines @@
 See
 [bugs with the component Blink>Infra](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3ABlink%3EInfra)
 for issues related to Blink tools, include the layout test runner.
 
 * Windows and Linux: Do not copy and paste while the layout tests are running,
   as it may interfere with the editing/pasteboard and other clipboard-related
   tests. (Mac tests swizzle NSClipboard to avoid any conflicts).
 * If QuickTime is not installed, the plugin tests
   `fast/dom/object-embed-plugin-scripting.html` and
   `plugins/embed-attributes-setting.html` are expected to fail.