BASELINE: Update Chromium to 59.0.3071.134

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

35 files changed, 2281 insertions, 915 deletions

diff --git a/chromium/docs/README.md b/chromium/docs/README.md
index c203f4ed8ec..b0d26a2965b 100644
--- a/chromium/docs/README.md
+++ b/chromium/docs/README.md
@@ -1,17 +1,22 @@
 # Chromium docs
 
 This directory contains chromium project documentation in
-[Gitiles-flavored Markdown].
+[Gitiles-flavored Markdown](https://gerrit.googlesource.com/gitiles/+/master/Documentation/markdown.md).
 It is automatically
 [rendered by Gitiles](https://chromium.googlesource.com/chromium/src/+/master/docs/).
 
+If you add new documents, please also add a link to them in the Document Index
+below.
+
+[TOC]
+
 ## Style guide
 
-Markdown documents must follow the [style guide].
+Markdown documents must follow the [style guide](https://github.com/google/styleguide/tree/gh-pages/docguide).
 
 ## Previewing changes
 
-You can preview your local changes using [md_browser]:
+You can preview your local changes using [md_browser](../tools/md_browser/):
 
 ```bash
 # in chromium checkout
@@ -26,6 +31,280 @@ git cl patch <CL number or URL>
 ./tools/md_browser/md_browser.py
 ```
 
-[Gitiles-flavored Markdown]: https://gerrit.googlesource.com/gitiles/+/master/Documentation/markdown.md
-[style guide]: https://github.com/google/styleguide/tree/gh-pages/docguide
-[md_browser]: ../tools/md_browser/
+## Document Index
+
+### Checking Out and Building
+*   [Linux Build Instructions](linux_build_instructions.md) - Linux
+*   [Mac Build Instructions](mac_build_instructions.md) - MacOS
+*   [Windows Build Instructions](windows_build_instructions.md) - Windows
+*   [Android Build Instructions](android_build_instructions.md) - Android target
+    (on a Linux host)
+*   [Cast Build Instructions](linux_cast_build_instructions.md) - Cast target
+    (on a Linux host)
+*   [Cast for Android Build Instructions](android_cast_build_instructions.md) -
+    Cast for Android (on a Linux host)
+*   [iOS Build Instructions](ios/build_instructions.md) - iOS target (on a MacOS
+    host)
+*   [Linux Chromium ARM Recipes](linux_chromium_arm.md) - Recipes for building
+    Chromium for ARM on Linux.
+*   [Common Build Tasks](common_build_tasks.md) - Recipes for slightly more
+    advanced build tasks
+*   [Chrome Component Build](component_build.md) - Faster builds using more
+    libraries
+*   [Using the BuildRunner](using_build_runner.md) - Scripts that extract build
+    stops from builders and runs them locally on a slave
+*   [Cr User Manual](cr_user_manual.md) - Manual for `cr`, a tool that tries to
+    hide some of the tools used for working on Chromium behind an abstraction
+    layer
+
+### Integrated Development Environment (IDE) Set Up Guides
+*   [Android Studio](android_studio.md) - Android Studio for Android builds
+*   [Eclipse for Android](eclipse.md) - Eclipse for Android
+*   [Eclipse for Linux](linux_eclipse_dev.md) - Eclipse for other platforms
+    (This guide was written for Linux, but is probably usable on Windows/MacOS
+    as well)
+*   [Qt Creator](qtcreator.md) - Using Qt Creator as an IDE or GUI debugger
+*   [Setting up Visual Studio Code](vscode.md) - Visual Studio Code
+*   [EMACS Notes](emacs.md) - EMACS commands/styles/tool integrations
+*   [Atom](atom.md) - Atom multi-platform code editor
+
+### Git
+*   [Git Cookbook](git_cookbook.md) - A collection of git recipes for common
+    tasks
+*   [Git Tips](git_tips.md) - More git tips
+
+### Clang
+*   [Clang Compiler](clang.md) - General information on the clang compiler, used
+    by default on Mac and Linux
+*   [Clang Tool Refactoring](clang_tool_refactoring.md) - Leveraging clang tools
+    to perform refactorings that are AST-aware
+*   [The Clang Static Analyzer](clang_static_analyzer.md) - How to enable static
+    analysis at build time
+*   [Writing Clang Plugins](writing_clang_plugins.md) - Don't write a clang
+    plugin, but if you do, read this
+*   [Updating Clang](updating_clang.md) - Updating the version of Clang used to
+    build
+*   [Using clang-format on Chromium C++ Code](clang_format.md) - Various ways to
+    invoke clang-format on C++ code
+*   [Clang Tidy](clang_tidy.md) - Support for the `clang-tidy` tool in Chromium
+*   [Updating Clang Format Binaries](updating_clang_format_binaries.md) - How up
+    update the clang-format binaries that come with a checkout of Chromium
+
+### General Development
+*   [Code Reviews](code_reviews.md) - Code review requirements and guidelines
+*   [Closure Compilation](closure_compilation.md) - The _Closure_ JavaScript
+    compiler
+*   [Callback<> and Bind()](callback.md) - All about Callbacks, Closures, and
+    Bind().
+*   [Views Platform Styling](ui/views/platform_style.md) - How views are styled
+    to fit in different native platforms
+*   [Tab Helpers](tab_helpers.md) - Using WebContents/WebContentsObserver to add
+    features to browser tabs.
+*   [Adding third_party Libraries](adding_to_third_party.md) - How to get code
+    into third_party/
+*   [Graphical Debugging Aid for Chromium Views](graphical_debugging_aid_chromium_views.md) -
+    Visualizing view trees during debugging
+*   [Bitmap Pipeline](bitmap_pipeline.md) - How bitmaps are moved from the
+    renderer to the screen.
+*   [base::Optional](optional.md) - How to use `base::Optional` in C++ code.
+*   [Using the Origin Trials Framework](origin_trials_integration.md) - A
+    framework for conditionally enabling experimental APIs for testing.
+*   [`SharedModelTypeProcessor` in Unified Sync and Storage](sync/uss/shared_model_type_processor.md) -
+    Notes on the central data structure used in Chrome Sync.
+*   [Chrome Sync's Model API](sync/model_api.md) - Data models used for syncing
+    information across devices using Chrome Sync.
+*   [Ozone Overview](ozone_overview.md) - Ozone is an abstraction layer between
+    the window system and low level input and graphics.
+*   [Optimizing Chrome Web UIs](optimizing_web_uis.md) - Notes on making webuis
+    more performant
+*   [ES6 Support in Chromium](es6_chromium.md) - Implementation of ECMAScript6
+    features in Chromium
+
+### Testing
+*   [Running and Debugging Layout Tests](testing/layout_tests.md)
+*   [Writing Layout Tests](testing/writing_layout_tests.md) - Layout Tests using
+    `content_shell`
+*   [Layout Test Expectations and Baselines](testing/layout_test_expectations.md) -
+    Setting expected results of layout tests.
+*   [Layout Tests Tips](testing/layout_tests_tips.md) - Best practices for Layout
+    Tests
+*   [Layout Tests with Manual Fallback](testing/layout_tests_with_manual_fallback.md) -
+    Writing tests that simulate manual interventions
+*   [Extending the Layout Test Framework](how_to_extend_layout_test_framework.md)
+*   [Fixing Layout Test Flakiness](testing/identifying_tests_that_depend_on_order.md) -
+    Diagnosing and fixing layout test flakiness due to ordering dependencies.
+*   [Running Layout Tests using `content_shell`](testing/layout_tests_in_content_shell.md) -
+    Running layout tests by hand.
+*   [Testing Browser Dialogs](testing/test_browser_dialog.md) - Using
+    TestBrowserDialog
+*   [Web Platform Tests](testing/web_platform_tests.md) - Shared tests across
+    browser vendors
+*   [Using Breakpad with `content_shell`](testing/using_breakpad_with_content_shell.md) -
+    Capture stack traces on layout test crashes without an attached debugger
+*   [Test Descriptions](test_descriptions.md) - Unit test targets that can be
+    built, with associated desciptions.
+*   [IPC Fuzzer](ipc_fuzzer.md) - Fuzz testing of Chromium IPC interfaces.
+
+### Misc Linux-Specific Docs
+*   [Linux Proxy Config](linux_proxy_config.md) - Network proxy sources on Linux
+*   [Debugging SSL on Linux](linux_debugging_ssl.md) - Tips on debugging SSL
+    code in Linux
+*   [Linux Cert Managment](linux_cert_management.md) - Managing X.509
+    Certificates in Linux
+*   [Tips for Debugging on Linux](linux_debugging.md)
+*   [Linux GTK Theme Integration](linux_gtk_theme_integration.md) - Having
+    Chrome match the GTK+ theme.
+*   [Gtk vs ViewsGtk](gtk_vs_views_gtk.md) - Notes on when to use Gtk vs
+    ViewsGtk
+*   [Browser Plugins on Linux](linux_plugins.md) - A collection of links to
+    information on how browser plugins work on Linux
+*   [Linux Crash Dumping](linux_crash_dumping.md) - How Breakpad uploads crash
+    reports to Google crash servers.
+*   [Linux Minidump to Core](linux_minidump_to_core.md) - How to convert a
+    Breakpad-generated minidump files to a core file readable by most debuggersx
+*   [Linux Sandbox IPC](linux_sandbox_ipc.md) - The lower level UPC system used
+    to route requests from the bottom of the call stack up into the browser.
+*   [Linux Dev Build as Default Browser](linux_dev_build_as_default_browser.md) -
+    How to configure a Dev build of Chrome as the default browser in Linux.
+*   [Linux Chromium Packages](linux_chromium_packages.md) - Packages of Chromium
+    browser (not Chrome) provided by some Linux distributions.
+*   [`seccomp` Sandbox Crash Dumping](seccomp_sandbox_crash_dumping.md) - Notes
+    on crash dumping a process running in a seccomp sandbox.
+*   [Linux Password Storage](linux_password_storage.md) - Keychain integrations
+    between Chromium and Linux.
+*   [Linux Sublime Development](linux_sublime_dev.md) - Using Sublime as an IDE
+    for Chromium development on Linux.
+*   [Building and Debugging GTK](linux_building_debug_gtk.md) - Building
+    Chromium against GTK using lower optimization levels and/or more debugging
+    symbols.
+*   [Debugging GTK](linux_debugging_gtk.md) - Using the GTK Debug packages and
+    related tools.
+*   [Chroot Notes](using_a_linux_chroot.md) - Setting up a chroot to work around
+    libfreetype differences in some versions of Linux.
+*   [Linux Sandboxing](linux_sandboxing.md) - The Linux multi-process model to
+    isolate browser components with different privileges.
+*   [Zygote Process](linux_zygote.md) - How the Linux Zygote process, used to
+    spawn new processes, works.
+*   [Running Layout Tests on Linux](layout_tests_linux.md) - Linux-specific
+    instructions for running layout tests.
+*   [Linux Sysroot Images](linux_sysroot.md) - How builds use libraries on Linux
+*   [`msttcorefonts` on Mandriva](mandriva_msttcorefonts.md) - Getting fonts
+    needed to build Chrome that are not available for Mandriva
+*   [Linux Hardware Video Decoding](linux_hw_video_decode.md) - Enabling
+    hardware video decode codepaths on Linux
+
+### Misc MacOS-Specific Docs
+*   [Using CCache on Mac](ccache_mac.md) - Speed up builds on Mac using ccache
+    with clang/ninja
+*   [Cocoa tips and tricks](cocoa_tips_and_tricks.md) - A collection of idioms
+    used when writing Cocoa views and controllers
+*   [MacViews Release Plan](ui/views/macviews_release.md)
+
+### Misc Windows-Specific Docs
+*   [Handling cygwin rebaseall failures](cygwin_dll_remapping_failure.md)
+*   [Hacking on ANGLE in Chromium](angle_in_chromium.md) - OpenGL ES 2.0 built
+    on top of DirectX
+*   [Retrieveing Code Analysis Warnings](retrieving_code_analysis_warnings.md) -
+    How to retrieve and summarize the warnings generated by Microsoft VC++'s
+    `/analyze` compile option.
+*   [Windows Split DLLs](windows_split_dll.md) - Splitting `chrome.dll` into
+    multiple dlls to work around toolchain limitations on Windows.
+
+### Misc Android-Specific Docs
+*   [Google Play Services in Chrome for Android](google_play_services.md)
+*   [Accessing C++ Enums in Java](android_accessing_cpp_enums_in_java.md) - How
+    to use C++-defined enums in Java code
+*   [Profiling Content Shell on Android](profiling_content_shell_on_android.md) -
+    Setting up profiling for `content_shell` on Android
+*   [Working Remotely with Android](working_remotely_with_android.md) - Building
+    on a remote machine for an Android device connected to your local machine
+*   [Using FindBugs for Android](use_find_bugs_for_android.md) - Using the open
+    source static analysis tool findbugs on the Java code.
+*   [Android Test Instructions](android_test_instructions.md) - Running a build
+    on an Android device or emulator.
+*   [Android Debugging](android_debugging_instructions.md) - Tools and tips for
+    how to debug Java and/or C/C++ code running on Android.
+*   [Android Logging](android_logging.md) - How Chrome's logging API works with
+    `android.util.Log` on Android, and usage guidelines.
+*   [Chromoting Android Hacking](chromoting_android_hacking.md) - Viewing the
+    logs and debugging the Chrome Remote Desktop Android client.
+
+### Misc iOS-Specific Docs
+*   [Continuous Build and Test Infrastructure for Chromium for iOS](ios/infra.md)
+*   [Opening links in Chrome for iOS](ios/opening_links.md) - How to have your
+    iOS app open links in Chrome.
+*   [User Agent in Chrome for iOS](ios/user_agent.md) - Notes on User Agent
+    strings using Chrome for iOS.
+
+### Media
+*   [Audio Focus Handling](media/audio_focus.md) - How multiple MediaSession
+    audio streams interact
+*   [Autoplay of HTMLMediaElements](media/autoplay.md) - How HTMLMediaElements
+    are autoplayed.
+*   [Piranha Plant](piranha_plant.md) - Future architecture of MediaStreams
+
+### Accessibility
+*   [Accessibility Overview](accessibility/overview.md) - Overview of
+    accessibility concerns and approaches in Chromium.
+*   [Accessibility Tests](accessibility/tests.md) - Where to find
+    accessibility-related tests in the codebase.
+*   [ChromeVox on Chrome OS](accessibility/chromevox.md) - Enabling spoken
+    feedback (ChromeVox) on Chrome OS.
+*   [ChromeVox on Desktop Linux](accessibility/chromevox_on_desktop_linux.md) -
+    Enabling spoken feedback (ChromeVox) on desktop Linux.
+*   [BRLTTY in Chrome OS](accessibility/brltty.md) - Chrome OS integration with
+    BRLTTY to support refreshable braille displays
+*   [PATTS on Chrome OS](accessibility/patts.md) - Notes on the PATTS speech
+    sythesis engine used on Chrome OS
+*   [VoiceOver](ios/voiceover.md) - Using Apple's VoiceOver feature with
+    Chromium on iOS.
+
+### Memory Infrastructure Timeline Profiling (MemoryInfra)
+*   [Overview](memory-infra/README.md)
+*   [GPU Profiling](memory-infra/probe-gpu.md)
+*   [Adding Tracing to a Component](memory-infra/adding_memory_infra_tracing.md)
+*   [Enabling Startup Tracing](memory-infra/memory_infra_startup_tracing.md)
+*   [Memory Usage in CC](memory-infra/probe-cc.md)
+*   [Memory Benchmarks](memory-infra/memory_benchmarks.md)
+*   [Heap Profiling](memory-infra/heap_profiler.md)
+*   [Heap Profiling Internals](memory-infra/heap_profiler_internals.md)
+
+### Misc
+*   [Useful URLs](useful_urls.md) - A collection of links to various tools and
+    dashboards
+*   [ERC IRC](erc_irc.md) - Using ERC in EMACS to access IRC
+*   [Kiosk Mode](kiosk_mode.md) - Simulating kiosk mode.
+*   [User Handle Mapping](user_handle_mapping.md) - Names of developers across
+    Chromium/IRC/Google
+*   [Documentation Best Practices](documentation_best_practices.md)
+*   [Documentation Guidelines](documentation_guidelines.md)
+*   [Shift-Based Development](shift_based_development.md) - An experiment in
+    handing off development of coordinated work between developers in different
+    time zones.
+*   [Chromium Browser vs Google Chrome](chromium_browser_vs_google_chrome.md) -
+    What's the difference between _Chromium Browser_ and _Google Chrome_?
+*   [Proxy Auto Config using WPAD](proxy_auto_config.md) - How WPAD servers are
+    used to automatically set proxy settings.
+*   [Installing Chromium OS on VMWare](installation_at_vmware.md) - How to
+    install Chromium OS on VMWare.
+
+### Probably Obsolete
+*   [Old ChromeOS build instructions](old_chromeos_build_instructions.md)
+*   [TPM Quick Reference](tpm_quick_ref.md) - Trusted Platform Module notes.
+*   [System Hardening Features](system_hardening_features.md) - A list of
+    current and planned Chrome OS security features.
+*   [Browser View Resizer](browser_view_resizer.md) - Design doc for making
+    browser window resizing easier on Windows.
+*   [WebView Policies](webview_policies.md)
+*   [Linux Profiling](linux_profiling.md) - How to profile Chromium on Linux
+*   [Linux Graphics Pipeline](linux_graphics_pipeline.md)
+*   [Linux `SUID` Sandbox](linux_suid_sandbox.md) - Sandboxing renderers using a
+    SUID binary on Linux
+*   [Linux `SUID` Sandbox Development](linux_suid_sandbox_development.md) -
+    Development on the above system.
+*   [Linux PID Namespace Support](linux_pid_namespace_support.md)
+*   [Vanilla msysgit workflow](vanilla_msysgit_workflow.md) - A workflow for
+    using mostly vanilla git on Windows.
+*   [Old Chromoting Build Instructions](old_chromoting_build_instructions.md)
+*   [Old Options](chrome_settings.md) - Pre-Material Design chrome://settings
+    notes.
diff --git a/chromium/docs/android_build_instructions.md b/chromium/docs/android_build_instructions.md
index be30dfa87bf..edc51d77fc6 100644
--- a/chromium/docs/android_build_instructions.md
+++ b/chromium/docs/android_build_instructions.md
@@ -112,19 +112,6 @@ keys](https://www.chromium.org/developers/how-tos/api-keys) if you want your
 build to talk to some Google services, but this is not necessary for most
 development and testing purposes.
 
-### Configure the JDK
-
-Make also sure that OpenJDK 1.7 is selected as default:
-
-```shell
-$ sudo update-alternatives --config javac
-$ sudo update-alternatives --config java
-$ sudo update-alternatives --config javaws
-$ sudo update-alternatives --config javap
-$ sudo update-alternatives --config jar
-$ sudo update-alternatives --config jarsigner
-```
-
 ## Setting up the build
 
 Chromium uses [Ninja](https://ninja-build.org) as its main build tool along
@@ -237,23 +224,16 @@ CHROMIUM_OUT_DIR env.
 export CHROMIUM_OUT_DIR=out_android
 ```
 
-### Build WebView shell
+### Build WebView
 
 [Android WebView](https://developer.android.com/reference/android/webkit/WebView.html)
 is a system framework component. Since Android KitKat, it is implemented using
 Chromium code (based off the [content module](https://dev.chromium.org/developers/content-module)).
-It is possible to test modifications to WebView using a simple test shell. The
-WebView shell is a view with a URL bar at the top (see [code](https://code.google.com/p/chromium/codesearch#chromium/src/android_webview/test/shell/src/org/chromium/android_webview/test/AwTestContainerView.java))
-and is **independent** of the WebView **implementation in the Android system** (
-the WebView shell is essentially a standalone unbundled app).
-As drawback, the shell runs in non-production rendering mode only.
-
-```shell
-ninja -C out/Release android_webview_apk
-build/android/adb_install_apk.py out/Release/apks/AndroidWebView.apk
-```
 
-If, instead, you want to build the complete Android WebView framework component and test the effect of your chromium changes in other Android app using the WebView, you should follow the [Android AOSP + chromium WebView instructions](https://www.chromium.org/developers/how-tos/build-instructions-android-webview)
+If you want to build the complete Android WebView framework component and test
+the effect of your chromium changes in Android apps using WebView, you should
+follow the [Android AOSP + chromium WebView
+instructions](https://www.chromium.org/developers/how-tos/build-instructions-android-webview)
 
 ### Running
 
@@ -271,12 +251,6 @@ For Chrome public:
 build/android/adb_run_chrome_public  http://example.com
 ```
 
-For Android WebView shell:
-
-```shell
-build/android/adb_run_android_webview_shell http://example.com
-```
-
 ### Logging and debugging
 
 Logging is often the easiest way to understand code flow. In C++ you can print
@@ -297,7 +271,6 @@ following commands:
 ```shell
 build/android/adb_gdb_content_shell
 build/android/adb_gdb_chrome_public
-build/android/adb_gdb_android_webview_shell http://example.com
 ```
 
 See [Debugging Chromium on Android](https://www.chromium.org/developers/how-tos/debugging-on-android)
diff --git a/chromium/docs/android_cast_build_instructions.md b/chromium/docs/android_cast_build_instructions.md
new file mode 100644
index 00000000000..f6d0287d28e
--- /dev/null
+++ b/chromium/docs/android_cast_build_instructions.md
@@ -0,0 +1,370 @@
+# Checking out and building Cast for Android
+
+**Note**: it is **not possible** to build a binary functionally
+equivalent to a Chromecast. This is to build a single-page content
+embedder with similar functionality to Cast products.
+
+## Instructions for Google Employees
+
+Are you a Google employee? See
+[go/building-android-cast](https://goto.google.com/building-android-cast) instead.
+
+[TOC]
+
+## System requirements
+
+* A 64-bit Intel machine running Linux with at least 8GB of RAM. More
+  than 16GB is highly recommended.
+* At least 100GB of free disk space.
+* You must have Git and Python installed already.
+
+Most development is done on Ubuntu. Other distros may or may not work;
+see the [Linux instructions](linux_build_instructions.md) for some suggestions.
+
+Building the Android client on Windows or Mac is not supported and doesn't work.
+
+## Install `depot_tools`
+
+Clone the `depot_tools` repository:
+
+```shell
+$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
+```
+
+Add `depot_tools` to the end of your PATH (you will probably want to put this
+in your `~/.bashrc` or `~/.zshrc`). Assuming you cloned `depot_tools`
+to `/path/to/depot_tools`:
+
+```shell
+$ export PATH="$PATH:/path/to/depot_tools"
+```
+
+## Get the code
+
+Create a `chromium` directory for the checkout and change to it (you can call
+this whatever you like and put it wherever you like, as
+long as the full path has no spaces):
+
+```shell
+$ mkdir ~/chromium && cd ~/chromium
+$ fetch --nohooks android
+```
+
+If you don't want the full repo history, you can save a lot of time by
+adding the `--no-history` flag to `fetch`.
+
+Expect the command to take 30 minutes on even a fast connection, and many
+hours on slower ones.
+
+If you've already installed the build dependencies on the machine (from another
+checkout, for example), you can omit the `--nohooks` flag and `fetch`
+will automatically execute `gclient runhooks` at the end.
+
+When `fetch` completes, it will have created a hidden `.gclient` file and a
+directory called `src` in the working directory. The remaining instructions
+assume you have switched to the `src` directory:
+
+```shell
+$ cd src
+```
+
+### Converting an existing Linux checkout
+
+If you have an existing Linux checkout, you can add Android support by
+appending `target_os = ['android']` to your `.gclient` file (in the
+directory above `src`):
+
+```shell
+$ echo "target_os = [ 'android' ]" >> ../.gclient
+```
+
+Then run `gclient sync` to pull the new Android dependencies:
+
+```shell
+$ gclient sync
+```
+
+(This is the only difference between `fetch android` and `fetch chromium`.)
+
+### Install additional build dependencies
+
+Once you have checked out the code, run
+
+```shell
+$ build/install-build-deps-android.sh
+```
+
+to get all of the dependencies you need to build on Linux, *plus* all of the
+Android-specific dependencies (you need some of the regular Linux dependencies
+because an Android build includes a bunch of the Linux tools and utilities).
+
+### Run the hooks
+
+Once you've run `install-build-deps` at least once, you can now run the
+Chromium-specific hooks, which will download additional binaries and other
+things you might need:
+
+```shell
+$ gclient runhooks
+```
+
+*Optional*: You can also [install API
+keys](https://www.chromium.org/developers/how-tos/api-keys) if you want your
+build to talk to some Google services, but this is not necessary for most
+development and testing purposes.
+
+## Setting up the build
+
+Chromium uses [Ninja](https://ninja-build.org) as its main build tool along
+with a tool called [GN](../tools/gn/docs/quick_start.md) to generate `.ninja`
+files. You can create any number of *build directories* with different
+configurations. To create a build directory which builds Chrome for Android,
+run:
+
+```shell
+$ gn gen --args='target_os="android" is_chromecast=true' out/Default
+```
+
+* You only have to run this once for each new build directory, Ninja will
+  update the build files as needed.
+* You can replace `Default` with another name, but
+  it should be a subdirectory of `out`.
+* For other build arguments, including release settings, see [GN build
+  configuration](https://www.chromium.org/developers/gn-build-configuration).
+  The default will be a debug component build matching the current host
+  operating system and CPU.
+* For more info on GN, run `gn help` on the command line or read the
+  [quick start guide](../tools/gn/docs/quick_start.md).
+
+Also be aware that some scripts (e.g. `tombstones.py`, `adb_gdb.py`)
+require you to set `CHROMIUM_OUTPUT_DIR=out/Default`.
+
+## Build cast\_shell\_apk
+
+Build cast\_shell\_apk with Ninja using the command:
+
+```shell
+$ ninja -C out/Default cast_shell_apk
+```
+
+## Installing and Running cast\_shell\_apk on a device
+
+If the `adb_install_apk.py` script below fails, make sure `aapt` is in your
+PATH. If not, add `aapt`'s parent directory to your `PATH` environment variable
+(it should be
+`/path/to/src/third_party/android_tools/sdk/build-tools/{latest_version}/`).
+
+Prepare the environment:
+
+```shell
+$ . build/android/envsetup.sh
+```
+
+### Plug in your Android device
+
+Make sure your Android device is plugged in via USB, and USB Debugging
+is enabled.
+
+To enable USB Debugging:
+
+*   Navigate to Settings \> About Phone \> Build number
+*   Click 'Build number' 7 times
+*   Now navigate back to Settings \> Developer Options
+*   Enable 'USB Debugging' and follow the prompts
+
+You may also be prompted to allow access to your PC once your device is
+plugged in.
+
+You can check if the device is connected by running:
+
+```shell
+third_party/android_tools/sdk/platform-tools/adb devices
+```
+
+Which prints a list of connected devices. If not connected, try
+unplugging and reattaching your device.
+
+### Build the APK
+
+```shell
+ninja -C out/Release cast_shell_apk
+```
+
+And deploy it to your Android device:
+
+```shell
+build/android/adb_install_apk.py out/Default/apks/CastShell.apk
+adb shell am start -d "http://google.com" org.chromium.chromecast.shell/.CastShellActivity
+
+```
+
+The app will appear on the device as "Chromium".
+
+### Build Content shell
+
+Wraps the content module (but not the /chrome embedder). See
+[https://www.chromium.org/developers/content-module](https://www.chromium.org/developers/content-module)
+for details on the content module and content shell.
+
+```shell
+ninja -C out/Release content_shell_apk
+build/android/adb_install_apk.py out/Release/apks/ContentShell.apk
+```
+
+this will build and install an Android apk under
+`out/Release/apks/ContentShell.apk`. (Where `Release` is the name of your build
+directory.)
+
+If you use custom out dir instead of standard out/ dir, use
+CHROMIUM_OUT_DIR env.
+
+```shell
+export CHROMIUM_OUT_DIR=out_android
+```
+
+### Build WebView shell
+
+[Android WebView](https://developer.android.com/reference/android/webkit/WebView.html)
+is a system framework component. Since Android KitKat, it is implemented using
+Chromium code (based off the [content module](https://dev.chromium.org/developers/content-module)).
+It is possible to test modifications to WebView using a simple test shell. The
+WebView shell is a view with a URL bar at the top (see [code](https://code.google.com/p/chromium/codesearch#chromium/src/android_webview/test/shell/src/org/chromium/android_webview/test/AwTestContainerView.java))
+and is **independent** of the WebView **implementation in the Android system** (
+the WebView shell is essentially a standalone unbundled app).
+As drawback, the shell runs in non-production rendering mode only.
+
+```shell
+ninja -C out/Release android_webview_apk
+build/android/adb_install_apk.py out/Release/apks/AndroidWebView.apk
+```
+
+If, instead, you want to build the complete Android WebView framework component and test the effect of your chromium changes in other Android app using the WebView, you should follow the [Android AOSP + chromium WebView instructions](https://www.chromium.org/developers/how-tos/build-instructions-android-webview)
+
+### Running
+
+Set [command line flags](https://www.chromium.org/developers/how-tos/run-chromium-with-flags) if necessary.
+
+For Content shell:
+
+```shell
+build/android/adb_run_content_shell  http://example.com
+```
+
+For Chrome public:
+
+```shell
+build/android/adb_run_chrome_public  http://example.com
+```
+
+For Android WebView shell:
+
+```shell
+build/android/adb_run_android_webview_shell http://example.com
+```
+
+### Logging and debugging
+
+Logging is often the easiest way to understand code flow. In C++ you can print
+log statements using the LOG macro or printf(). In Java, you can print log
+statements using [android.util.Log](https://developer.android.com/reference/android/util/Log.html):
+
+`Log.d("sometag", "Reticulating splines progress = " + progress);`
+
+You can see these log statements using adb logcat:
+
+```shell
+adb logcat...01-14 11:08:53.373 22693 23070 D sometag: Reticulating splines progress = 0.99
+```
+
+You can debug Java or C++ code. To debug C++ code, use one of the
+following commands:
+
+```shell
+build/android/adb_gdb_content_shell
+build/android/adb_gdb_chrome_public
+build/android/adb_gdb_android_webview_shell http://example.com
+```
+
+See [Debugging Chromium on Android](https://www.chromium.org/developers/how-tos/debugging-on-android)
+for more on debugging, including how to debug Java code.
+
+### Testing
+
+For information on running tests, see [android\_test\_instructions.md](https://chromium.googlesource.com/chromium/src/+/master/docs/android_test_instructions.md).
+
+### Faster Edit/Deploy (GN only)
+
+GN's "incremental install" uses reflection and side-loading to speed up the edit
+& deploy cycle (normally < 10 seconds). The initial launch of the apk will be
+a little slower since updated dex files are installed manually.
+
+*   Make sure to set` is_component_build = true `in your GN args
+*   All apk targets have \*`_incremental` targets defined (e.g.
+    `chrome_public_apk_incremental`) except for Webview and Monochrome
+
+Here's an example:
+
+```shell
+ninja -C out/Default chrome_public_apk_incremental
+out/Default/bin/install_chrome_public_apk_incremental -v
+```
+
+For gunit tests (note that run_*_incremental automatically add
+--fast-local-dev when calling test\_runner.py):
+
+```shell
+ninja -C out/Default base_unittests_incremental
+out/Default/bin/run_base_unittests_incremental
+```
+
+For instrumentation tests:
+
+```shell
+ninja -C out/Default chrome_public_test_apk_incremental
+out/Default/bin/run_chrome_public_test_apk_incremental
+```
+
+To uninstall:
+
+```shell
+out/Default/bin/install_chrome_public_apk_incremental -v --uninstall
+```
+
+A subtly erroneous flow arises when you build a regular apk but install an
+incremental apk (e.g.
+`ninja -C out/Default foo_apk && out/Default/bin/install_foo_apk_incremental`).
+Setting `incremental_apk_by_default = true` in your GN args aliases regular
+targets as their incremental counterparts. With this arg set, the commands
+above become:
+
+```shell
+ninja -C out/Default chrome_public_apk
+out/Default/bin/install_chrome_public_apk
+
+ninja -C out/Default base_unittests
+out/Default/bin/run_base_unittests
+
+ninja -C out/Default chrome_public_test_apk
+out/Default/bin/run_chrome_public_test_apk
+```
+
+If you want to build a non-incremental apk you'll need to remove
+`incremental_apk_by_default` from your GN args.
+
+## Tips, tricks, and troubleshooting
+
+### Rebuilding libchrome.so for a particular release
+
+These instructions are only necessary for Chrome 51 and earlier.
+
+In the case where you want to modify the native code for an existing
+release of Chrome for Android (v25+) you can do the following steps.
+Note that in order to get your changes into the official release, you'll
+need to send your change for a codereview using the regular process for
+committing code to chromium.
+
+1.  Open Chrome on your Android device and visit chrome://version
+2.  Copy down the id listed next to "Build ID:"
+3.  Go to
+    [http://storage.googleapis.com/chrome-browser-components/BUILD\_ID\_FROM\_STEP\_2/index.html](http://storage.googleapis.com/chrome-browser-components/BUILD_ID_FROM_STEP_2/index.html)
+4.  Download the listed files and follow the steps in the README.
diff --git a/chromium/docs/android_debugging_instructions.md b/chromium/docs/android_debugging_instructions.md
index 1102fbfcc2f..8fd2dd89118 100644
--- a/chromium/docs/android_debugging_instructions.md
+++ b/chromium/docs/android_debugging_instructions.md
@@ -92,6 +92,7 @@ private int mSuperNiftyDrawingProperty;
 
 ## Debugging Java
 
+### Eclipse
 *   In Eclipse, make a debug configuration of type "Remote Java Application".
     Choose a "Name" and set "Port" to `8700`.
 
@@ -109,6 +110,12 @@ private int mSuperNiftyDrawingProperty;
 
 *   Run your debug configuration, and switch to the Debug perspective.
 
+### Android Studio
+*   Build and install the desired target
+
+*   Click the "Attach debugger to Android process" (see
+[here](https://developer.android.com/studio/debug/index.html) for more)
+
 ## Waiting for Java Debugger on Early Startup
 
 *   To debug early startup, pass `--wait-for-java-debugger` as a command line
diff --git a/chromium/docs/android_studio.md b/chromium/docs/android_studio.md
index 3752122574c..b46f8631793 100644
--- a/chromium/docs/android_studio.md
+++ b/chromium/docs/android_studio.md
@@ -24,6 +24,12 @@ to generate projects for:
 build/android/gradle/generate_gradle.py --target //chrome/android:chrome_public_apk --target //android_webview/test:android_webview_apk
 ```
 
+For those upgrading from Android Studio 2.2 to 2.3:
+
+* Regenerate with `generate_gradle.py`.
+* Clean up in `//third_party/android_tools` with `git clean -ffd`.
+* Restart Android Studio with File -&gt; "Invalidate Caches / Restart".
+
 For first-time Android Studio users:
 
 * Avoid running the setup wizard.
@@ -55,8 +61,8 @@ Gradle sub-project.
 Gradle supports source directories but not source files. However, some
 directories in Chromium are split amonst multiple GN targets. To accommodate
 this, the script detects such targets and creates exclude patterns to exclude
-files not in the current target. You may still see them when editing, but they
-are excluded in gradle tasks.
+files not in the current target. You still see them when editing, but they are
+excluded in gradle tasks.
 ***
 
 Most generated .java files in GN are stored as `.srcjars`. Android Studio does
@@ -98,6 +104,7 @@ includes `R.java`).
 * `Shift + F6`: Rename variable
 * `Ctrl + Alt + O`: Organize imports
 * `Alt + Enter`: Quick Fix (use on underlined errors)
+* `F2`: Find next error
 
 ### Building from the Command Line
 
@@ -116,20 +123,23 @@ resources, native libraries, etc.
     * Add the line `org.gradle.daemon=true` to `~/.gradle/gradle.properties`,
       creating it if necessary.
 
-## Status (as of Feb 7th, 2017)
+## Status (as of April 4th, 2017)
 
 ### What works
 
-* Tested with Android Studio v2.2.
+* Tested with Android Studio v2.3.
 * Java editing and gradle compile works.
 * Instrumentation tests included as androidTest.
 * Symlinks to existing .so files in jniLibs (doesn't generate them).
 * Editing resource xml files.
+* Java debugging (see
+[here](/docs/android_debugging_instructions.md#Android-Studio)).
 
 ### What doesn't work (yet) ([crbug](https://bugs.chromium.org/p/chromium/issues/detail?id=620034))
 
-* Make gradle aware of assets
-* Layout editor
-* Add a mode in which gradle is responsible for generating `R.java`
-* Add support for native code editing
-* Make the "Make Project" button work correctly
+* Proper file resolution and imports for overlapping modules.
+* Make gradle aware of assets.
+* Layout editor.
+* Add a mode in which gradle is responsible for generating `R.java`.
+* Add support for native code editing.
+* Make the "Make Project" button work correctly.
diff --git a/chromium/docs/android_test_instructions.md b/chromium/docs/android_test_instructions.md
index b26130cc6f4..b941118f416 100644
--- a/chromium/docs/android_test_instructions.md
+++ b/chromium/docs/android_test_instructions.md
@@ -158,11 +158,11 @@ with the following commands:
 
 ```shell
 # Resize userdata partition to be 1G
-resize2fs android_emulator_sdk/sdk/system-images/android-24/x86/userdata.img 1G
+resize2fs android_emulator_sdk/sdk/system-images/android-25/x86/userdata.img 1G
 
 # Set filesystem parameter to continue on errors; Android doesn't like some
 # things e2fsprogs does.
-tune2fs -e continue android_emulator_sdk/sdk/system-images/android-24/x86/userdata.img
+tune2fs -e continue android_emulator_sdk/sdk/system-images/android-25/x86/userdata.img
 ```
 
 ## Symbolizing Crashes
diff --git a/chromium/docs/callback.md b/chromium/docs/callback.md
index b891a0f05fd..4194d510799 100644
--- a/chromium/docs/callback.md
+++ b/chromium/docs/callback.md
@@ -67,8 +67,11 @@ void Baz(OnceCallback<void(int)> cb) {
 
 // |Qux| takes the ownership of |cb| and transfers ownership to PostTask(),
 // which also takes the ownership of |cb|.
+// NOTE: TaskRunner is not actually migrated to OnceClosure yet. Once TaskRunner
+// supports OnceClosure, a OnceCallback can be posted as follows:
 void Qux(OnceCallback<void(int)> cb) {
-  PostTask(FROM_HERE, std::move(cb));
+  PostTask(FROM_HERE,
+           base::BindOnce(std::move(cb), 42));  // not yet implemented!
 }
 ```
 
@@ -149,6 +152,17 @@ void DoSomething(const RepeatingCallback<double(double)>& callback) {
 }
 ```
 
+If running a callback could result in its own destruction (e.g., if the callback
+recipient deletes the object the callback is a member of), the callback should
+be moved before it can be safely invoked. The `base::ResetAndReturn` method
+provides this functionality.
+
+```cpp
+void Foo::RunCallback() {
+  base::ResetAndReturn(&foo_deleter_callback_).Run();
+}
+```
+
 ### Passing Unbound Input Parameters
 
 Unbound parameters are specified at the time a callback is `Run()`. They are
diff --git a/chromium/docs/clang_static_analyzer.md b/chromium/docs/clang_static_analyzer.md
index dd79d0fc225..48bd21a6fa0 100644
--- a/chromium/docs/clang_static_analyzer.md
+++ b/chromium/docs/clang_static_analyzer.md
@@ -17,6 +17,3 @@ use_clang_static_analyzer = true
 The next time you rebuild, you should see static analysis warnings appear inline
 with the usual Clang build warnings and errors.
 
-## Future plans/potential issues
-* Support for running under GOMA is untested, but will be added shortly if
-  feasible.
diff --git a/chromium/docs/clang_tool_refactoring.md b/chromium/docs/clang_tool_refactoring.md
index 9b49df11b3a..9fc3a7f89cc 100644
--- a/chromium/docs/clang_tool_refactoring.md
+++ b/chromium/docs/clang_tool_refactoring.md
@@ -125,13 +125,6 @@ $gen_targets = $(ninja -C out/gn -t targets all \
 ninja -C out/Debug $gen_targets
 ```
 
-On Windows, generate the compile DB first, and after making any source changes.
-Then omit the `--generate-compdb` in later steps.
-
-```shell
-tools/clang/scripts/generate_win_compdb.py out/Debug
-```
-
 Then run the actual clang tool to generate a list of edits:
 
 ```shell
diff --git a/chromium/docs/get_the_code.md b/chromium/docs/get_the_code.md
index cc834b5622e..0d637d44bf5 100644
--- a/chromium/docs/get_the_code.md
+++ b/chromium/docs/get_the_code.md
@@ -12,7 +12,7 @@ you might want to build:
 * [Android](android_build_instructions.md)
 * [Cast](old_cast_build_instructions.md)
 * [Chrome OS](old_chromeos_build_instructions.md)
-* [iOS](ios_build_instructions.md)
+* [iOS](ios/build_instructions.md)
 * [Linux](linux_build_instructions.md)
 * [Mac](mac_build_instructions.md)
 * [Windows](windows_build_instructions.md)
diff --git a/chromium/docs/git_tips.md b/chromium/docs/git_tips.md
index 9576c4bc4bf..7bb9ffa2ceb 100644
--- a/chromium/docs/git_tips.md
+++ b/chromium/docs/git_tips.md
@@ -18,13 +18,13 @@ Various git commands have underlying executable with a hyphenated name, such as
 The following resources can provide background on how Git works:
 
 *   [Git-SVN Crash Course](http://git-scm.com/course/svn.html) -- this crash
-    course is useful for Subversion users  witching to Git.
+    course is useful for Subversion users switching to Git.
 *   [Think Like (a) Git](http://think-like-a-git.net/) -- does a great job of
     explaining the main purpose of Git operations.
 *   [Git User's Manual](http://schacon.github.com/git/user-manual.html) -- a
     great resource to learn more about ho to use Git properly.
 *   [A Visual Git Reference](http://marklodato.github.com/visual-git-guide/index-en.html)
-    -- a resource that explains various Git operations for visual reasons.
+    -- a resource that explains various Git operations for visual learners.
 *   [Git Cheat Sheet](http://cheat.errtheblog.com/s/git) -- now that you
     understand Git, here's a cheat sheet to quickly remind you of all the
     commands you need.
diff --git a/chromium/docs/ios/build_instructions.md b/chromium/docs/ios/build_instructions.md
new file mode 100644
index 00000000000..db1844c53c8
--- /dev/null
+++ b/chromium/docs/ios/build_instructions.md
@@ -0,0 +1,313 @@
+# Checking out and building Chromium for iOS
+
+There are instructions for other platforms linked from the
+[get the code](../get_the_code.md) page.
+
+## Instructions for Google Employees
+
+Are you a Google employee? See
+[go/building-chrome](https://goto.google.com/building-chrome) instead.
+
+[TOC]
+
+## System requirements
+
+* A 64-bit Mac running 10.11+.
+* [Xcode](https://developer.apple.com/xcode) 8.0+.
+* The OS X 10.10 SDK. Run
+
+    ```shell
+    $ ls `xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs
+    ```
+
+  to check whether you have it.  Building with the 10.11 SDK works too, but
+  the releases currently use the 10.10 SDK.
+* The current version of the JDK (required for the Closure compiler).
+
+## Install `depot_tools`
+
+Clone the `depot_tools` repository:
+
+```shell
+$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
+```
+
+Add `depot_tools` to the end of your PATH (you will probably want to put this
+in your `~/.bashrc` or `~/.zshrc`). Assuming you cloned `depot_tools` to
+`/path/to/depot_tools`:
+
+```shell
+$ export PATH="$PATH:/path/to/depot_tools"
+```
+
+## Get the code
+
+Create a `chromium` directory for the checkout and change to it (you can call
+this whatever you like and put it wherever you like, as
+long as the full path has no spaces):
+
+```shell
+$ mkdir chromium && cd chromium
+```
+
+Run the `fetch` tool from `depot_tools` to check out the code and its
+dependencies.
+
+```shell
+$ fetch ios
+```
+
+If you don't want the full repo history, you can save a lot of time by
+adding the `--no-history` flag to `fetch`.
+
+Expect the command to take 30 minutes on even a fast connection, and many
+hours on slower ones.
+
+When `fetch` completes, it will have created a hidden `.gclient` file and a
+directory called `src` in the working directory. The remaining instructions
+assume you have switched to the `src` directory:
+
+```shell
+$ cd src
+```
+
+*Optional*: You can also [install API
+keys](https://www.chromium.org/developers/how-tos/api-keys) if you want your
+build to talk to some Google services, but this is not necessary for most
+development and testing purposes.
+
+## Setting up the build
+
+Since the iOS build is a bit more complicated than a desktop build, we provide
+`ios/build/tools/setup-gn.py`, which will create four appropriately configured
+build directories under `out` for Release and Debug device and simulator
+builds, and generates an appropriate Xcode workspace as well.
+
+You can customize the build by editing the file `$HOME/.setup-gn` (create it if
+it does not exist).  Look at `src/ios/build/tools/setup-gn.config` for
+available configuration options.
+
+From this point, you can either build from Xcode or from the command line using
+`ninja`. `setup-gn.py` creates sub-directories named
+`out/${configuration}-${platform}`, so for a `Debug` build for simulator use:
+
+```shell
+$ ninja -C out/Debug-iphonesimulator gn_all
+```
+
+Note: you need to run `setup-gn.py` script every time one of the `BUILD.gn`
+file is updated (either by you or after rebasing). If you forget to run it,
+the list of targets and files in the Xcode solution may be stale.
+
+You can also follow the manual instructions on the
+[Mac page](../mac_build_instructions.md), but make sure you set the
+GN arg `target_os="ios"`.
+
+## Building for device
+
+To be able to build and run Chromium and the tests for devices, you need to
+have an Apple developer account (a free one will work) and the appropriate
+provisioning profiles, then configure the build to use them.
+
+### Code signing identity
+
+Please refer to the Apple documentation on how to get a code signing identity
+and certificates. You can check that you have a code signing identity correctly
+installed by running the following command.
+
+```shell
+$ xcrun security find-identity -v -p codesigning
+  1) 0123456789ABCDEF0123456789ABCDEF01234567 "iPhone Developer: someone@example.com (XXXXXXXXXX)"
+     1 valid identities found
+```
+
+If the command output says you have zero valid identities, then you do not
+have a code signing identity installed and need to get one from Apple. If
+you have more than one identity, the build system may select the wrong one
+automatically, and you can use the `ios_code_signing_identity` gn variable
+to control which one to use by setting it to the identity hash, e.g. to
+`"0123456789ABCDEF0123456789ABCDEF01234567"`.
+
+### Mobile provisioning profiles
+
+Once you have the code signing identity, you need to decide on a prefix
+for the application bundle identifier. This is controlled by the gn variable
+`ios_app_bundle_id_prefix` and usually corresponds to a reversed domain name
+(the default value is `"org.chromium"`).
+
+You then need to request provisioning profiles from Apple for your devices
+for the following bundle identifiers to build and run Chromium with these
+application extensions:
+
+-   `${prefix}.chrome.ios.herebedragons`
+-   `${prefix}.chrome.ios.herebedragons.ShareExtension`
+-   `${prefix}.chrome.ios.herebedragons.TodayExtension`
+
+All these certificates need to have the "App Groups"
+(`com.apple.security.application-groups`) capability enabled for
+the following groups:
+
+-   `group.${prefix}.chrome`
+-   `group.${prefix}.common`
+
+The `group.${prefix}.chrome` is only shared by Chromium and its extensions
+to share files and configurations while the `group.${prefix}.common` is shared
+with Chromium and other applications from the same organisation and can be used
+to send commands to Chromium.
+
+### Mobile provisioning profiles for tests
+
+In addition to that, you need provisioning profiles for the individual test
+suites that you want to run. Their bundle identifier depends on whether the
+gn variable `ios_automatically_manage_certs` is set to true (the default)
+or false.
+
+If set to true, then you just need a provisioning profile for the bundle
+identifier `${prefix}.gtest.generic-unit-test` but you can only have a
+single test application installed on the device (all the test application
+will share the same bundle identifier).
+
+If set to false, then you need a different provisioning profile for each
+test application. Those provisioning profile will have a bundle identifier
+matching the following pattern `${prefix}.gtest.${test-suite-name}` where
+`${test-suite-name}` is the name of the test suite with underscores changed
+to dashes (e.g. `base_unittests` app will use `${prefix}.gest.base-unittests`
+as bundle identifier).
+
+To be able to run the EarlGrey tests on a device, you'll need two provisioning
+profiles for EarlGrey and OCHamcrest frameworks:
+
+-   `${prefix}.test.OCHamcrest`
+-   `${prefix}.test.EarlGrey`
+
+In addition to that, then you'll need one additional provisioning profile for
+the XCTest module too. This module bundle identifier depends on whether the
+gn variable `ios_automatically_manage_certs` is set to true or false. If set
+to true, then `${prefix}.test.gtest.generic-unit-test.generic-unit-test-module`
+will be used, otherwise it will match the following pattern:
+`${prefix}.test.${test-suite-name}.${test-suite-name}-module`.
+
+### Other applications
+
+Other applications like `ios_web_shell` usually will require mobile provisioning
+profiles with bundle identifiers that may usually match the following pattern
+`${prefix}.${application-name}` and may require specific capabilities.
+
+Generally, if the mobile provisioning profile is missing then the code signing
+step will fail and will print the bundle identifier of the bundle that could not
+be signed on the command line, e.g.:
+
+```shell
+$ ninja -C out/Debug-iphoneos ios_web_shell
+ninja: Entering directory `out/Debug-iphoneos'
+FAILED: ios_web_shell.app/ios_web_shell ios_web_shell.app/_CodeSignature/CodeResources ios_web_shell.app/embedded.mobileprovision
+python ../../build/config/ios/codesign.py code-sign-bundle -t=iphoneos -i=0123456789ABCDEF0123456789ABCDEF01234567 -e=../../build/config/ios/entitlements.plist -b=obj/ios/web/shell/ios_web_shell ios_web_shell.app
+Error: no mobile provisioning profile found for "org.chromium.ios-web-shell".
+ninja: build stopped: subcommand failed.
+```
+
+Here, the build is failing because there are no mobile provisioning profiles
+installed that could sign the `ios_web_shell.app` bundle with the identity
+`0123456789ABCDEF0123456789ABCDEF01234567`. To fix the build, you'll need to
+request such a mobile provisioning profile from Apple.
+
+You can inspect the file passed via the `-e` flag to the `codesign.py` script
+to check which capabilites are required for the mobile provisioning profile
+(e.g. `src/build/config/ios/entitlements.plist` for the above build error,
+remember that the paths are relative to the build directory, not to the source
+directory).
+
+If the required capabilities are not enabled on the mobile provisioning profile,
+then it will be impossible to install the application on a device (Xcode will
+display an error stating that "The application was signed with invalid
+entitlements").
+
+## Running apps from the commandline
+
+Any target that is built and runs on the bots (see [below](#Troubleshooting))
+should run successfully in a local build. To run in the simulator from the
+command line, you can use `iossim`. For example, to run a debug build of
+`Chromium`:
+
+```shell
+$ out/Debug-iphonesimulator/iossim out/Debug-iphonesimulator/Chromium.app
+```
+
+## Update your checkout
+
+To update an existing checkout, you can run
+
+```shell
+$ git rebase-update
+$ gclient sync
+```
+
+The first command updates the primary Chromium source repository and rebases
+any of your local branches on top of tip-of-tree (aka the Git branch
+`origin/master`). If you don't want to use this script, you can also just use
+`git pull` or other common Git commands to update the repo.
+
+The second command syncs dependencies to the appropriate versions and re-runs
+hooks as needed.
+
+## Tips, tricks, and troubleshooting
+
+If you have problems building, join us in `#chromium` on `irc.freenode.net` and
+ask there. As mentioned above, be sure that the
+[waterfall](https://build.chromium.org/buildbot/waterfall/) is green and the tree
+is open before checking out. This will increase your chances of success.
+
+### Improving performance of `git status`
+
+`git status` is used frequently to determine the status of your checkout.  Due
+to the large number of files in Chromium's checkout, `git status` performance
+can be quite variable.  Increasing the system's vnode cache appears to help.
+By default, this command:
+
+```shell
+$ sysctl -a | egrep kern\..*vnodes
+```
+
+Outputs `kern.maxvnodes: 263168` (263168 is 257 * 1024).  To increase this
+setting:
+
+```shell
+$ sudo sysctl kern.maxvnodes=$((512*1024))
+```
+
+Higher values may be appropriate if you routinely move between different
+Chromium checkouts.  This setting will reset on reboot, the startup setting can
+be set in `/etc/sysctl.conf`:
+
+```shell
+$ echo kern.maxvnodes=$((512*1024)) | sudo tee -a /etc/sysctl.conf
+```
+
+Or edit the file directly.
+
+If `git --version` reports 2.6 or higher, the following may also improve
+performance of `git status`:
+
+```shell
+$ git update-index --untracked-cache
+```
+
+### Xcode license agreement
+
+If you're getting the error
+
+> Agreeing to the Xcode/iOS license requires admin privileges, please re-run as
+> root via sudo.
+
+the Xcode license hasn't been accepted yet which (contrary to the message) any
+user can do by running:
+
+```shell
+$ xcodebuild -license
+```
+
+Only accepting for all users of the machine requires root:
+
+```shell
+$ sudo xcodebuild -license
+```
diff --git a/chromium/docs/ios/infra.md b/chromium/docs/ios/infra.md
new file mode 100644
index 00000000000..80a1303dc4c
--- /dev/null
+++ b/chromium/docs/ios/infra.md
@@ -0,0 +1,367 @@
+# Continuous build and test infrastructure for Chromium for iOS
+
+See the [instructions] for how to check out and build Chromium for iOS.
+
+The Chromium projects use buildbot for continuous integration. This doc starts
+with an overview of the system, then gives detailed explanations about each
+part.
+
+[TOC]
+
+## Overview
+
+Commits are made using the [commit queue], which triggers a series of try jobs
+to compile and test the proposed patch against Chromium tip of tree before
+actually making the commit. If the try jobs succeed the patch is committed. A
+newly committed change triggers the builders (or "bots") to compile and test
+the change again.
+
+## Bots
+
+Bots are slaves attached to a buildbot master (or "waterfall"). A buildbot
+master is a server which polls for commits to a repository and triggers workers
+to compile and test new commits whenever they are detected. [chromium.mac] is
+the main waterfall for Mac desktop and iOS. [tryserver.chromium.mac] serves
+as the try server for Mac desktop and iOS.
+
+The bots know how to check out a given revision of Chromium, compile, and test.
+
+### Code location
+
+#### Master configs
+
+The masters are configured in [tools/build], a separate repository which
+contains various infra-related scripts.
+
+#### Pollers
+
+[chromium.mac] uses a `GitilesPoller` which polls the Chromium repository for
+new commits using the [gitiles] interface. When a new commit is detected, the
+bots are triggered.
+
+#### Recipes
+
+The bots run [recipes], which are scripts that specify their sequence of steps
+located in [tools/build]. An iOS-specific [recipe module] contains common
+functionality that the various [iOS recipes] use.
+
+#### Configs
+
+Because the recipes live in another repository, changes to the recipes don't
+go through the Chromium [commit queue] and aren't tested on the [try server].
+In order to allow bot changes to be tested by the commit queue, the recipes
+for iOS are generic instead of bot-specific, and rely on configuration files
+which live in master-specific JSON config files located in [src/ios/build/bots].
+These configs define the `gn_args` to use during compilation as well as the
+tests to run.
+
+#### Scripts
+
+The [test runner] is the script which installs and runs the tests, interprets
+the results, and collects any files emitted by the test ("test data"). It can
+be found in [src/ios/build/bots/scripts], which means changes to the test runner
+can be tested on the [try server].
+
+### Compiling with goma
+
+Goma is the distributed build system used by Chromium. It reduces compilation
+time by avoiding recompilation of objects which have already been compiled
+elsewhere.
+
+### Testing with swarming
+
+Tests run on [swarming], a distributed test system used by Chromium. After
+compilation, configured tests will be zipped up along with their necessary
+dependencies ("isolated") and sent to the [swarming server] for execution. The
+server issues tasks to its attached workers for execution. The bots themselves
+don't run any tests, they trigger tests to be run remotely on the swarming
+server, then wait and display the results. This allows multiple tests to be
+executed in parallel.
+
+## Try bots
+
+Try bots are bots which test proposed patches which are not yet committed.
+
+Request [try job access] in order to trigger try jobs against your patch. The
+relevant try bots for an iOS patch are `ios-device`, `ios-device-xcode-clang`,
+`ios-simulator`, and `ios-simulator-xcode-clang`. These bots can be found on
+the Mac-specific [try server]. A try job is said to succeed when the build
+passes (i.e. when the bot successfully compiles and tests the patch).
+
+`ios-device` and `ios-device-xcode-clang` both compile for the iOS device
+architecture (ARM), and neither run any tests. A build is considered successful
+so long as compilation is successful.
+
+`ios-simulator` and `ios-simulator-xcode-clang` both compile for the iOS
+simulator architecture (x86), and run tests in the iOS [simulator]. A build is
+considered successful when both compilation and all configured test succeed.
+
+`ios-device` and `ios-simulator` both compile using the version of [clang]
+defined by the `CLANG_REVISION` in the Chromium tree.
+
+`ios-device-xcode-clang` and `ios-simulator-xcode-clang` both compile using the
+version of clang that ships with Xcode.
+
+### Scheduling try jobs using buildbucket
+
+Triggering a try job and collecting its results is accomplished using
+[buildbucket]. The service allows for build requests to be put into buckets. A
+request in this context is a set of properties indicating things such as where
+to get the patch. The try bots are set up to poll a particular bucket for build
+requests which they execute and post the results of.
+
+### Compiling with the analyzer
+
+In addition to goma, the try bots use another time-saving mechanism called the
+[analyzer] to determine the subset of compilation targets affected by the patch
+that need to be compiled in order to run the affected tests. If a patch is
+determined not to affect a certain test target, compilation and execution of the
+test target will be skipped.
+
+## Configuring the bots
+
+See the [configs code location](#Configs) for where to find the config files for
+the bots. The config files are JSON which describe how the bot should compile
+and which tests it should run. The config files are located in the configs
+directory. The configs directory contains a named directory for each master. For
+example:
+```shell
+$ ls ios/build/bots
+OWNERS  scripts  tests  chromium.fyi  chromium.mac
+```
+In this case, configs are defined for iOS bots on [chromium.fyi] and
+[chromium.mac]. Inside each master-specific directory are JSON config files
+named after each bot. For example:
+```shell
+$ ls ios/build/bots/chromium.mac
+ios-device.json ios-simulator.json
+```
+The `ios-device` bot on [chromium.mac] will read its configuration from
+`chromium.mac/ios-device.json` in the configs directory.
+
+### Example
+
+```json
+{
+  "comments": [
+    "Sample config for a bot."
+  ],
+  "gn_args": [
+    "is_debug=true",
+    "target_cpu=\"x64\""
+  ],
+  "tests": [
+    {
+      "app": "ios_chrome_unittests",
+      "device type": "iPhone 5s",
+      "os": "10.0",
+      "xcode version": "8.0"
+    }
+  ]
+}
+```
+The `comments` key is optional and defines a list of strings which can be used
+to annotate the config. You may want to explain why the bot exists and what it's
+doing, particularly if there are extensive and atypical `gn_args`.
+
+The `gn_args` key is a required list of arguments to pass to [GN] to generate
+the build files. Two GN args are required, `is_debug` and `target_cpu`. Use
+`is_debug` to define whether to compile for Debug or Release, and `target_cpu`
+to define whether to compile for x86, x64, arm, or arm64. The iOS bots typically
+perform Debug builds for x86 and x64, and Release builds for arm and arm64. An
+x86/x64 build can only be tested on the [iOS simulator], while an arm/arm64
+build can only be tested on a physical device.
+
+Since Chromium for iOS is shipped as a [universal binary], it's also fairly
+common to set `additional_target_cpus`. For simulator builds, we typically set:
+```json
+"gn_args": [
+  "additional_target_cpus=[\"x86\"]",
+  "is_debug=true",
+  "target_cpu=\"x64\""
+]
+```
+This builds universal binaries which run in 32-bit mode on 32-bit simulators and
+64-bit mode on 64-bit simulators. For device builds we typically set:
+```json
+"gn_args": [
+  "additional_target_cpus=[\"arm\"]",
+  "is_debug=false",
+  "target_cpu=\"arm64\""
+]
+```
+In order to build universal binaries which run in 32-bit mode on 32-bit devices
+and 64-bit mode on 64-bit devices.
+
+The `tests` key is an optional list of dictionaries defining tests to run. There
+are two types of test dictionary, `app` and `include`. An `app` dict defines a
+specific compiled app to run, for example:
+```json
+"tests": [
+  {
+    "app": "ios_chrome_unittests",
+    "device type": "iPhone 5s",
+    "os": "10.0",
+    "xcode version": "8.0"
+  }
+]
+```
+This dict says to run `ios_chrome_unittests` on an `iPhone 5s` running iOS
+`10.0` using Xcode `8.0`. A test dict may optionally define a list of `test
+args`, which are arguments to pass directly to the test on the command line,
+and it may define a boolean value `xctest` to indicate whether the test is an
+[xctest] \(default if unspecified is `false`\). For example:
+```json
+"tests": [
+  {
+    "app": "ios_chrome_unittests",
+    "device type": "iPhone 5s",
+    "os": "10.0",
+    "test args": [
+      "--foo",
+      "--bar"
+    ],
+    "xcode version": "8.0"
+  },
+  {
+    "app": "ios_chrome_integration_egtests",
+    "device type": "iPhone 5s",
+    "os": "10.0",
+    "xcode version": "8.0",
+    "xctest": true
+  }
+]
+```
+This defines two tests to run, first `ios_chrome_unittests` will be run with
+`--foo` and `--bar` passed directly to the test on the command line. Next,
+`ios_chrome_integration_egtests` will be run as an xctest. `"xctest": true`
+must be specified for all xctests, it is an error to try and launch an xctest as
+a regular test.
+
+An `include` dict defines a list of tests to import from the `tests`
+subdirectory in the configs directory. For example:
+```json
+"tests": [
+  {
+    "include": "common_tests.json",
+    "device type": "iPhone 5s",
+    "os": "10.0",
+    "xcode version": "8.0"
+  }
+]
+```
+This dict says to import the list of tests from the `tests` subdirectory and run
+each one on an `iPhone 5s` running iOS `10.0` using Xcode `8.0`. Here's what
+`common_tests.json` might look like:
+```json
+"tests": [
+  {
+    "app": "ios_chrome_unittests"
+  },
+  {
+    "app": "ios_net_unittests"
+  },
+  {
+    "app": "ios_web_unittests"
+  },
+]
+```
+Includes may contain other keys besides `app` which can then be omitted in the
+bot config. For example if `common_tests.json` specifies:
+```json
+"tests": [
+  {
+    "app": "ios_chrome_integration_egtests",
+    "xctest": true,
+    "xcode version": "8.0"
+  }
+]
+```
+Then the bot config may omit the `xctest` or `xcode version` keys, for example:
+```json
+{
+  "comments": [
+    "Sample config for a bot."
+  ],
+  "gn_args": [
+    "is_debug=true",
+    "target_cpu=\"x64\""
+  ],
+  "tests": [
+    {
+      "include": "common_tests.json",
+      "device type": "iPhone 5s",
+      "os": "10.0"
+    }
+  ]
+}
+```
+Includes are not recursive, so `common_tests.json` may not itself include any
+`include` dicts.
+
+### Uploading compiled artifacts from a bot
+
+A bot may be configured to upload compiled artifacts. This is defined by the
+`upload` key. For example:
+```json
+{
+  "comments": [
+    "Sample config for a bot which uploads artifacts."
+  ],
+  "gn_args": [
+    "is_debug=true",
+    "target_cpu=\"x64\""
+  ],
+  "upload": [
+    {
+      "artifact": "Chromium.breakpad",
+      "bucket": "my-gcs-bucket",
+    },
+    {
+      "artifact": "Chromium.app",
+      "bucket": "my-gcs-bucket",
+      "compress": true,
+    },
+    {
+      "artifact": "Chromium.breakpad",
+      "symupload": true,
+    }
+  ]
+}
+```
+After compilation, the bot will upload three artifacts. First the
+`Chromium.breakpad` symbols will be uploaded to
+`gs://my-gcs-bucket/<buildername>/<buildnumber>/Chromium.breakpad`. Next
+`Chromium.app` will be tarred, gzipped, and uploaded to
+`gs://my-gcs-bucket/<buildername>/<buildnumber>/Chromium.tar.gz`. Finally
+the `Chromium.breakpad` symbols will be uploaded to the [breakpad] crash
+reporting server where they can be used to symbolicate stack traces.
+
+If `artifact` is a directory, you must specify `"compress": true`.
+
+[analyzer]: ../../tools/mb
+[breakpad]: https://chromium.googlesource.com/breakpad/breakpad
+[buildbucket]: https://cr-buildbucket.appspot.com
+[chromium.fyi]: https://build.chromium.org/p/chromium.fyi/waterfall
+[chromium.mac]: https://build.chromium.org/p/chromium.mac
+[clang]: ../../tools/clang
+[commit queue]: https://dev.chromium.org/developers/testing/commit-queue
+[gitiles]: https://gerrit.googlesource.com/gitiles
+[GN]: ../../tools/gn
+[instructions]: ./build_instructions.md
+[iOS recipes]: https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipes/ios
+[iOS simulator]: ../../testing/iossim
+[recipe module]: https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/ios
+[recipes]: https://chromium.googlesource.com/infra/infra/+/HEAD/doc/users/recipes.md
+[simulator]: https://developer.apple.com/library/content/documentation/IDEs/Conceptual/iOS_Simulator_Guide/Introduction/Introduction.html
+[src/ios/build/bots]: ../../ios/build/bots
+[src/ios/build/bots/scripts]: ../../ios/build/bots/scripts
+[swarming]: https://github.com/luci/luci-py/tree/master/appengine/swarming
+[swarming server]: https://chromium-swarm.appspot.com
+[test runner]: ../../ios/build/bots/scripts/test_runner.py
+[tools/build]: https://chromium.googlesource.com/chromium/tools/build
+[try job access]: https://www.chromium.org/getting-involved/become-a-committer#TOC-Try-job-access
+[try server]: https://build.chromium.org/p/tryserver.chromium.mac/waterfall
+[tryserver.chromium.mac]: https://build.chromium.org/p/tryserver.chromium.mac/waterfall
+[universal binary]: https://en.wikipedia.org/wiki/Universal_binary
+[xctest]: https://developer.apple.com/reference/xctest
diff --git a/chromium/docs/ios/opening_links.md b/chromium/docs/ios/opening_links.md
new file mode 100644
index 00000000000..329f2996438
--- /dev/null
+++ b/chromium/docs/ios/opening_links.md
@@ -0,0 +1,95 @@
+# Opening links in Chrome for iOS
+
+The easiest way to have your iOS app open links in Chrome is to use the
+[OpenInChromeController](https://github.com/GoogleChrome/OpenInChrome) class.
+This API is described here along with the URI schemes it supports.
+
+## Using OpenInChromeController to open links
+
+The **OpenInChromeController** class provides methods that
+encapsulate the URI schemes and the scheme replacement process also described
+in this document. Use this class to check if Chrome is installed or to specify
+the URL to open.
+
+### Methods
+
+* `isChromeInstalled`: returns YES if Chrome is installed
+* `openInChrome`: opens a given URL in Chrome
+
+For example, use the OpenInChromeController class as follows:
+
+```
+if ([openInController_ isChromeInstalled]) {
+    [openInController_ openInChrome:urlToOpen];
+}
+```
+
+## Downloading the class file
+
+The OpenInChromeController class file is available
+[here](https://github.com/GoogleChrome/OpenInChrome). Copy it into
+your Xcode installation.
+
+The rest of this document describes the underpinnings of this API.
+
+## URI schemes
+
+Chrome for iOS handles the following URI Schemes:
+
+* `googlechrome` for http
+* `googlechromes` for https
+
+To check if Chrome is installed, an app can simply check if either of these URI schemes is available:
+
+```
+[[UIApplication sharedApplication] canOpenURL:
+    [NSURL URLWithString:@"googlechrome://"]];
+```
+
+This step is useful in case an app would like to change the UI depending
+on if Chrome is installed or not. For instance the app could add an
+option to open URLs in Chrome in a share menu or action sheet.
+
+To actually open a URL in Chrome, the URI scheme provided in the URL
+must be changed from `http` or `https` to the Google Chrome equivalent of
+`googlechrome` or `googlechromes` respectively.
+The following sample code opens a URL in Chrome:
+
+```
+NSURL *inputURL = <the URL to open>;
+NSString *scheme = inputURL.scheme;
+
+// Replace the URL Scheme with the Chrome equivalent.
+NSString *chromeScheme = nil;
+if ([scheme isEqualToString:@"http"]) {
+  chromeScheme = @"googlechrome";
+} else if ([scheme isEqualToString:@"https"]) {
+  chromeScheme = @"googlechromes";
+}
+
+// Proceed only if a valid Google Chrome URI Scheme is available.
+if (chromeScheme) {
+  NSString *absoluteString = [inputURL absoluteString];
+  NSRange rangeForScheme = [absoluteString rangeOfString:@":"];
+  NSString *urlNoScheme =
+      [absoluteString substringFromIndex:rangeForScheme.location];
+  NSString *chromeURLString =
+      [chromeScheme stringByAppendingString:urlNoScheme];
+  NSURL *chromeURL = [NSURL URLWithString:chromeURLString];
+
+  // Open the URL with Chrome.
+  [[UIApplication sharedApplication] openURL:chromeURL];
+}
+```
+
+If Chrome is installed, the above code converts the URI scheme found in
+the URL to the Google Chrome equivalent. When Google Chrome opens, the
+URL passed as a parameter will be opened in a new tab.
+
+If Chrome is not installed the user can be prompted to download it from the App Store.
+If the user agrees, the app can open the App Store download page using the following:
+
+```
+[[UIApplication sharedApplication] openURL:[NSURL URLWithString:
+    @"itms-apps://itunes.apple.com/us/app/chrome/id535886823"]];
+```
diff --git a/chromium/docs/ios/user_agent.md b/chromium/docs/ios/user_agent.md
new file mode 100644
index 00000000000..1ad1be1e3bb
--- /dev/null
+++ b/chromium/docs/ios/user_agent.md
@@ -0,0 +1,30 @@
+# User Agent in Chrome for iOS
+
+The User Agent (UA) in Chrome for iOS is the same as the Mobile Safari
+user agent, with `CriOS/<ChromeRevision>` instead of
+`Version/<VersionNum>`.
+
+Here’s an example of the **Chrome** UA on iPhone:
+
+```
+Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X)
+AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/56.0.2924.75
+Mobile/14E5239e Safari/602.1
+```
+
+For comparison, the **Mobile Safari** UA:
+
+```
+Mozilla/5.0 (iPhone; CPU iPhone OS 10_3 like Mac OS X)
+AppleWebKit/603.1.23 (KHTML, like Gecko) Version/10.0
+Mobile/14E5239e Safari/602.1
+```
+
+When the Request Desktop Site feature is enabled, the **Desktop Safari** UA is
+sent:
+
+```
+Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4)
+AppleWebKit/600.7.12 (KHTML, like Gecko) Version/8.0.7
+Safari/600.7.12
+```
diff --git a/chromium/docs/ios/voiceover.md b/chromium/docs/ios/voiceover.md
new file mode 100644
index 00000000000..3f8a5cdf798
--- /dev/null
+++ b/chromium/docs/ios/voiceover.md
@@ -0,0 +1,48 @@
+# VoiceOver
+
+VoiceOver is an Accessibility feature available on Apple platforms. It provides
+an interface between your app and your blind or low-vision users. In short, it's
+a screen reader.
+
+## Overview
+
+[Activating VoiceOver](#Activate-VoiceOver) fundamentally changes the touch
+interface of an iOS device, so when you activate it, you need to know these
+basic commands to navigate:
+
+-   VoiceOver focuses an item on the screen and speaks it to the user.
+-   To navigate between items, you can either flick left/right to go to the
+    previous/next item, or you can drag your finger around the screen.
+-   Double tapping anywhere on the screen activates the item (no need to double
+    tap exactly on the item on the screen).
+-   Items have a label (describing the item) and can have among others:
+    -   traits (describing the item: a header, a button, selection state, etc.);
+    -   a hint (describing how to interact with the item).
+
+The following video is a great summary. The content is succinct, high quality
+and up-to-date, even though the video quality is low and the demo is on an
+iPhone 3GS.
+
+[![Video screenshot]][Video link]
+
+## Activate VoiceOver
+
+Go to `Settings > General > Accessibility > VoiceOver` and toggle the top
+switch.
+
+Alternatively, if you are activating/deactivating VoiceOver often, I'd advise
+to set it as the Accessibility Shortcut. When enabled, a triple tap on the Home
+button will toggle VoiceOver ON and OFF from anywhere.
+```
+Settings > General > Accessibility > Accessibility Shortcut
+```
+
+## Additional Resources
+
+-   [Apple presentation of VoiceOver]
+-   [AppleVis intro to VoiceOver]
+
+[Apple presentation of VoiceOver]: http://www.apple.com/accessibility/osx/voiceover/
+[AppleVis intro to VoiceOver]: http://www.applevis.com/guides/ios-miscellaneous-voiceover/intro-ios-accessibility-blind-and-low-vision-users
+[Video screenshot]: https://img.youtube.com/vi/WxQ2qKShvmc/0.jpg
+[Video link]: https://www.youtube.com/watch?v=WxQ2qKShvmc "iPhone VoiceOver Function For People With Disabilities"
diff --git a/chromium/docs/ios_build_instructions.md b/chromium/docs/ios_build_instructions.md
index 2d7a013236f..71a9e4c314c 100644
--- a/chromium/docs/ios_build_instructions.md
+++ b/chromium/docs/ios_build_instructions.md
@@ -1,315 +1,5 @@
-# Checking out and building Chromium for iOS
+# This document has moved
 
-There are instructions for other platforms linked from the
-[get the code](get_the_code.md) page.
+NOTE: Please update your link to this file!
 
-## Instructions for Google Employees
-
-Are you a Google employee? See
-[go/building-chrome](https://goto.google.com/building-chrome) instead.
-
-[TOC]
-
-## System requirements
-
-* A 64-bit Mac running 10.11+.
-* [Xcode](https://developer.apple.com/xcode) 8.0+.
-* The OS X 10.10 SDK. Run
-
-    ```shell
-    $ ls `xcode-select -p`/Platforms/MacOSX.platform/Developer/SDKs
-    ```
-
-  to check whether you have it.  Building with the 10.11 SDK works too, but
-  the releases currently use the 10.10 SDK.
-* The current version of the JDK (required for the Closure compiler).
-
-## Install `depot_tools`
-
-Clone the `depot_tools` repository:
-
-```shell
-$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
-```
-
-Add `depot_tools` to the end of your PATH (you will probably want to put this
-in your `~/.bashrc` or `~/.zshrc`). Assuming you cloned `depot_tools` to
-`/path/to/depot_tools`:
-
-```shell
-$ export PATH="$PATH:/path/to/depot_tools"
-```
-
-## Get the code
-
-Create a `chromium` directory for the checkout and change to it (you can call
-this whatever you like and put it wherever you like, as
-long as the full path has no spaces):
-
-```shell
-$ mkdir chromium && cd chromium
-```
-
-Run the `fetch` tool from `depot_tools` to check out the code and its
-dependencies.
-
-```shell
-$ fetch ios
-```
-
-If you don't want the full repo history, you can save a lot of time by
-adding the `--no-history` flag to `fetch`.
-
-Expect the command to take 30 minutes on even a fast connection, and many
-hours on slower ones.
-
-When `fetch` completes, it will have created a hidden `.gclient` file and a
-directory called `src` in the working directory. The remaining instructions
-assume you have switched to the `src` directory:
-
-```shell
-$ cd src
-```
-
-*Optional*: You can also [install API
-keys](https://www.chromium.org/developers/how-tos/api-keys) if you want your
-build to talk to some Google services, but this is not necessary for most
-development and testing purposes.
-
-## Setting up the build
-
-Since the iOS build is a bit more complicated than a desktop build, we provide
-`ios/build/tools/setup-gn.py`, which will create four appropriately configured
-build directories under `out` for Release and Debug device and simulator
-builds, and generates an appropriate Xcode workspace as well.
-
-This script is run automatically by fetch (as part of `gclient runhooks`).
-
-You can customize the build by editing the file `$HOME/.setup-gn` (create it if
-it does not exist).  Look at `src/ios/build/tools/setup-gn.config` for
-available configuration options.
-
-From this point, you can either build from Xcode or from the command line using
-`ninja`. `setup-gn.py` creates sub-directories named
-`out/${configuration}-${platform}`, so for a `Debug` build for simulator use:
-
-```shell
-$ ninja -C out/Debug-iphonesimulator gn_all
-```
-
-Note: you need to run `setup-gn.py` script every time one of the `BUILD.gn`
-file is updated (either by you or after rebasing). If you forget to run it,
-the list of targets and files in the Xcode solution may be stale.
-
-You can also follow the manual instructions on the
-[Mac page](mac_build_instructions.md), but make sure you set the
-GN arg `target_os="ios"`.
-
-## Building for device
-
-To be able to build and run Chromium and the tests for devices, you need to
-have an Apple developer account (a free one will work) and the appropriate
-provisioning profiles, then configure the build to use them.
-
-### Code signing identity
-
-Please refer to the Apple documentation on how to get a code signing identity
-and certificates. You can check that you have a code signing identity correctly
-installed by running the following command.
-
-```shell
-$ xcrun security find-identity -v -p codesigning
-  1) 0123456789ABCDEF0123456789ABCDEF01234567 "iPhone Developer: someone@example.com (XXXXXXXXXX)"
-     1 valid identities found
-```
-
-If the command output says you have zero valid identities, then you do not
-have a code signing identity installed and need to get one from Apple. If
-you have more than one identity, the build system may select the wrong one
-automatically, and you can use the `ios_code_signing_identity` gn variable
-to control which one to use by setting it to the identity hash, e.g. to
-`"0123456789ABCDEF0123456789ABCDEF01234567"`.
-
-### Mobile provisioning profiles
-
-Once you have the code signing identity, you need to decide on a prefix
-for the application bundle identifier. This is controlled by the gn variable
-`ios_app_bundle_id_prefix` and usually corresponds to a reversed domain name
-(the default value is `"org.chromium"`).
-
-You then need to request provisioning profiles from Apple for your devices
-for the following bundle identifiers to build and run Chromium with these
-application extensions:
-
--   `${prefix}.chrome.ios.herebedragons`
--   `${prefix}.chrome.ios.herebedragons.ShareExtension`
--   `${prefix}.chrome.ios.herebedragons.TodayExtension`
-
-All these certificates need to have the "App Groups"
-(`com.apple.security.application-groups`) capability enabled for
-the following groups:
-
--   `group.${prefix}.chrome`
--   `group.${prefix}.common`
-
-The `group.${prefix}.chrome` is only shared by Chromium and its extensions
-to share files and configurations while the `group.${prefix}.common` is shared
-with Chromium and other applications from the same organisation and can be used
-to send commands to Chromium.
-
-### Mobile provisioning profiles for tests
-
-In addition to that, you need provisioning profiles for the individual test
-suites that you want to run. Their bundle identifier depends on whether the
-gn variable `ios_automatically_manage_certs` is set to true (the default)
-or false.
-
-If set to true, then you just need a provisioning profile for the bundle
-identifier `${prefix}.gtest.generic-unit-test` but you can only have a
-single test application installed on the device (all the test application
-will share the same bundle identifier).
-
-If set to false, then you need a different provisioning profile for each
-test application. Those provisioning profile will have a bundle identifier
-matching the following pattern `${prefix}.gtest.${test-suite-name}` where
-`${test-suite-name}` is the name of the test suite with underscores changed
-to dashes (e.g. `base_unittests` app will use `${prefix}.gest.base-unittests`
-as bundle identifier).
-
-To be able to run the EarlGrey tests on a device, you'll need two provisioning
-profiles for EarlGrey and OCHamcrest frameworks:
-
--   `${prefix}.test.OCHamcrest`
--   `${prefix}.test.EarlGrey`
-
-In addition to that, then you'll need one additional provisioning profile for
-the XCTest module too. This module bundle identifier depends on whether the
-gn variable `ios_automatically_manage_certs` is set to true or false. If set
-to true, then `${prefix}.test.gtest.generic-unit-test.generic-unit-test-module`
-will be used, otherwise it will match the following pattern:
-`${prefix}.test.${test-suite-name}.${test-suite-name}-module`.
-
-### Other applications
-
-Other applications like `ios_web_shell` usually will require mobile provisioning
-profiles with bundle identifiers that may usually match the following pattern
-`${prefix}.${application-name}` and may require specific capabilities.
-
-Generally, if the mobile provisioning profile is missing then the code signing
-step will fail and will print the bundle identifier of the bundle that could not
-be signed on the command line, e.g.:
-
-```shell
-$ ninja -C out/Debug-iphoneos ios_web_shell
-ninja: Entering directory `out/Debug-iphoneos'
-FAILED: ios_web_shell.app/ios_web_shell ios_web_shell.app/_CodeSignature/CodeResources ios_web_shell.app/embedded.mobileprovision
-python ../../build/config/ios/codesign.py code-sign-bundle -t=iphoneos -i=0123456789ABCDEF0123456789ABCDEF01234567 -e=../../build/config/ios/entitlements.plist -b=obj/ios/web/shell/ios_web_shell ios_web_shell.app
-Error: no mobile provisioning profile found for "org.chromium.ios-web-shell".
-ninja: build stopped: subcommand failed.
-```
-
-Here, the build is failing because there are no mobile provisioning profiles
-installed that could sign the `ios_web_shell.app` bundle with the identity
-`0123456789ABCDEF0123456789ABCDEF01234567`. To fix the build, you'll need to
-request such a mobile provisioning profile from Apple.
-
-You can inspect the file passed via the `-e` flag to the `codesign.py` script
-to check which capabilites are required for the mobile provisioning profile
-(e.g. `src/build/config/ios/entitlements.plist` for the above build error,
-remember that the paths are relative to the build directory, not to the source
-directory).
-
-If the required capabilities are not enabled on the mobile provisioning profile,
-then it will be impossible to install the application on a device (Xcode will
-display an error stating that "The application was signed with invalid
-entitlements").
-
-## Running apps from the commandline
-
-Any target that is built and runs on the bots (see [below](#Troubleshooting))
-should run successfully in a local build. To run in the simulator from the
-command line, you can use `iossim`. For example, to run a debug build of
-`Chromium`:
-
-```shell
-$ out/Debug-iphonesimulator/iossim out/Debug-iphonesimulator/Chromium.app
-```
-
-## Update your checkout
-
-To update an existing checkout, you can run
-
-```shell
-$ git rebase-update
-$ gclient sync
-```
-
-The first command updates the primary Chromium source repository and rebases
-any of your local branches on top of tip-of-tree (aka the Git branch
-`origin/master`). If you don't want to use this script, you can also just use
-`git pull` or other common Git commands to update the repo.
-
-The second command syncs dependencies to the appropriate versions and re-runs
-hooks as needed.
-
-## Tips, tricks, and troubleshooting
-
-If you have problems building, join us in `#chromium` on `irc.freenode.net` and
-ask there. As mentioned above, be sure that the
-[waterfall](https://build.chromium.org/buildbot/waterfall/) is green and the tree
-is open before checking out. This will increase your chances of success.
-
-### Improving performance of `git status`
-
-`git status` is used frequently to determine the status of your checkout.  Due
-to the large number of files in Chromium's checkout, `git status` performance
-can be quite variable.  Increasing the system's vnode cache appears to help.
-By default, this command:
-
-```shell
-$ sysctl -a | egrep kern\..*vnodes
-```
-
-Outputs `kern.maxvnodes: 263168` (263168 is 257 * 1024).  To increase this
-setting:
-
-```shell
-$ sudo sysctl kern.maxvnodes=$((512*1024))
-```
-
-Higher values may be appropriate if you routinely move between different
-Chromium checkouts.  This setting will reset on reboot, the startup setting can
-be set in `/etc/sysctl.conf`:
-
-```shell
-$ echo kern.maxvnodes=$((512*1024)) | sudo tee -a /etc/sysctl.conf
-```
-
-Or edit the file directly.
-
-If `git --version` reports 2.6 or higher, the following may also improve
-performance of `git status`:
-
-```shell
-$ git update-index --untracked-cache
-```
-
-### Xcode license agreement
-
-If you're getting the error
-
-> Agreeing to the Xcode/iOS license requires admin privileges, please re-run as
-> root via sudo.
-
-the Xcode license hasn't been accepted yet which (contrary to the message) any
-user can do by running:
-
-```shell
-$ xcodebuild -license
-```
-
-Only accepting for all users of the machine requires root:
-
-```shell
-$ sudo xcodebuild -license
-```
+The new file location is [//docs/ios/build_instructions.md](ios/build_instructions.md)
\ No newline at end of file
diff --git a/chromium/docs/ios_infra.md b/chromium/docs/ios_infra.md
index 3ab0d7f299c..7fdef0d8c95 100644
--- a/chromium/docs/ios_infra.md
+++ b/chromium/docs/ios_infra.md
@@ -1,367 +1,5 @@
-# Continuous build and test infrastructure for Chromium for iOS
+# This document has moved
 
-See the [instructions] for how to check out and build Chromium for iOS.
+NOTE: Please update your link to this file!
 
-The Chromium projects use buildbot for continuous integration. This doc starts
-with an overview of the system, then gives detailed explanations about each
-part.
-
-[TOC]
-
-## Overview
-
-Commits are made using the [commit queue], which triggers a series of try jobs
-to compile and test the proposed patch against Chromium tip of tree before
-actually making the commit. If the try jobs succeed the patch is committed. A
-newly committed change triggers the builders (or "bots") to compile and test
-the change again.
-
-## Bots
-
-Bots are slaves attached to a buildbot master (or "waterfall"). A buildbot
-master is a server which polls for commits to a repository and triggers workers
-to compile and test new commits whenever they are detected. [chromium.mac] is
-the main waterfall for Mac desktop and iOS. [tryserver.chromium.mac] serves
-as the try server for Mac desktop and iOS.
-
-The bots know how to check out a given revision of Chromium, compile, and test.
-
-### Code location
-
-#### Master configs
-
-The masters are configured in [tools/build], a separate repository which
-contains various infra-related scripts.
-
-#### Pollers
-
-[chromium.mac] uses a `GitilesPoller` which polls the Chromium repository for
-new commits using the [gitiles] interface. When a new commit is detected, the
-bots are triggered.
-
-#### Recipes
-
-The bots run [recipes], which are scripts that specify their sequence of steps
-located in [tools/build]. An iOS-specific [recipe module] contains common
-functionality that the various [iOS recipes] use.
-
-#### Configs
-
-Because the recipes live in another repository, changes to the recipes don't
-go through the Chromium [commit queue] and aren't tested on the [try server].
-In order to allow bot changes to be tested by the commit queue, the recipes
-for iOS are generic instead of bot-specific, and rely on configuration files
-which live in master-specific JSON config files located in [src/ios/build/bots].
-These configs define the `gn_args` to use during compilation as well as the
-tests to run.
-
-#### Scripts
-
-The [test runner] is the script which installs and runs the tests, interprets
-the results, and collects any files emitted by the test ("test data"). It can
-be found in [src/ios/build/bots/scripts], which means changes to the test runner
-can be tested on the [try server].
-
-### Compiling with goma
-
-Goma is the distributed build system used by Chromium. It reduces compilation
-time by avoiding recompilation of objects which have already been compiled
-elsewhere.
-
-### Testing with swarming
-
-Tests run on [swarming], a distributed test system used by Chromium. After
-compilation, configured tests will be zipped up along with their necessary
-dependencies ("isolated") and sent to the [swarming server] for execution. The
-server issues tasks to its attached workers for execution. The bots themselves
-don't run any tests, they trigger tests to be run remotely on the swarming
-server, then wait and display the results. This allows multiple tests to be
-executed in parallel.
-
-## Try bots
-
-Try bots are bots which test proposed patches which are not yet committed.
-
-Request [try job access] in order to trigger try jobs against your patch. The
-relevant try bots for an iOS patch are `ios-device`, `ios-device-xcode-clang`,
-`ios-simulator`, and `ios-simulator-xcode-clang`. These bots can be found on
-the Mac-specific [try server]. A try job is said to succeed when the build
-passes (i.e. when the bot successfully compiles and tests the patch).
-
-`ios-device` and `ios-device-xcode-clang` both compile for the iOS device
-architecture (ARM), and neither run any tests. A build is considered successful
-so long as compilation is successful.
-
-`ios-simulator` and `ios-simulator-xcode-clang` both compile for the iOS
-simulator architecture (x86), and run tests in the iOS [simulator]. A build is
-considered successful when both compilation and all configured test succeed.
-
-`ios-device` and `ios-simulator` both compile using the version of [clang]
-defined by the `CLANG_REVISION` in the Chromium tree.
-
-`ios-device-xcode-clang` and `ios-simulator-xcode-clang` both compile using the
-version of clang that ships with Xcode.
-
-### Scheduling try jobs using buildbucket
-
-Triggering a try job and collecting its results is accomplished using
-[buildbucket]. The service allows for build requests to be put into buckets. A
-request in this context is a set of properties indicating things such as where
-to get the patch. The try bots are set up to poll a particular bucket for build
-requests which they execute and post the results of.
-
-### Compiling with the analyzer
-
-In addition to goma, the try bots use another time-saving mechanism called the
-[analyzer] to determine the subset of compilation targets affected by the patch
-that need to be compiled in order to run the affected tests. If a patch is
-determined not to affect a certain test target, compilation and execution of the
-test target will be skipped.
-
-## Configuring the bots
-
-See the [configs code location](#Configs) for where to find the config files for
-the bots. The config files are JSON which describe how the bot should compile
-and which tests it should run. The config files are located in the configs
-directory. The configs directory contains a named directory for each master. For
-example:
-```shell
-$ ls ios/build/bots
-OWNERS  scripts  tests  chromium.fyi  chromium.mac
-```
-In this case, configs are defined for iOS bots on [chromium.fyi] and
-[chromium.mac]. Inside each master-specific directory are JSON config files
-named after each bot. For example:
-```shell
-$ ls ios/build/bots/chromium.mac
-ios-device.json ios-simulator.json
-```
-The `ios-device` bot on [chromium.mac] will read its configuration from
-`chromium.mac/ios-device.json` in the configs directory.
-
-### Example
-
-```json
-{
-  "comments": [
-    "Sample config for a bot."
-  ],
-  "gn_args": [
-    "is_debug=true",
-    "target_cpu=\"x64\""
-  ],
-  "tests": [
-    {
-      "app": "ios_chrome_unittests",
-      "device type": "iPhone 5s",
-      "os": "10.0",
-      "xcode version": "8.0"
-    }
-  ]
-}
-```
-The `comments` key is optional and defines a list of strings which can be used
-to annotate the config. You may want to explain why the bot exists and what it's
-doing, particularly if there are extensive and atypical `gn_args`.
-
-The `gn_args` key is a required list of arguments to pass to [GN] to generate
-the build files. Two GN args are required, `is_debug` and `target_cpu`. Use
-`is_debug` to define whether to compile for Debug or Release, and `target_cpu`
-to define whether to compile for x86, x64, arm, or arm64. The iOS bots typically
-perform Debug builds for x86 and x64, and Release builds for arm and arm64. An
-x86/x64 build can only be tested on the [iOS simulator], while an arm/arm64
-build can only be tested on a physical device.
-
-Since Chromium for iOS is shipped as a [universal binary], it's also fairly
-common to set `additional_target_cpus`. For simulator builds, we typically set:
-```json
-"gn_args": [
-  "additional_target_cpus=[\"x86\"]",
-  "is_debug=true",
-  "target_cpu=\"x64\""
-]
-```
-This builds universal binaries which run in 32-bit mode on 32-bit simulators and
-64-bit mode on 64-bit simulators. For device builds we typically set:
-```json
-"gn_args": [
-  "additional_target_cpus=[\"arm\"]",
-  "is_debug=false",
-  "target_cpu=\"arm64\""
-]
-```
-In order to build universal binaries which run in 32-bit mode on 32-bit devices
-and 64-bit mode on 64-bit devices.
-
-The `tests` key is an optional list of dictionaries defining tests to run. There
-are two types of test dictionary, `app` and `include`. An `app` dict defines a
-specific compiled app to run, for example:
-```json
-"tests": [
-  {
-    "app": "ios_chrome_unittests",
-    "device type": "iPhone 5s",
-    "os": "10.0",
-    "xcode version": "8.0"
-  }
-]
-```
-This dict says to run `ios_chrome_unittests` on an `iPhone 5s` running iOS
-`10.0` using Xcode `8.0`. A test dict may optionally define a list of `test
-args`, which are arguments to pass directly to the test on the command line,
-and it may define a boolean value `xctest` to indicate whether the test is an
-[xctest] \(default if unspecified is `false`\). For example:
-```json
-"tests": [
-  {
-    "app": "ios_chrome_unittests",
-    "device type": "iPhone 5s",
-    "os": "10.0",
-    "test args": [
-      "--foo",
-      "--bar"
-    ],
-    "xcode version": "8.0"
-  },
-  {
-    "app": "ios_chrome_integration_egtests",
-    "device type": "iPhone 5s",
-    "os": "10.0",
-    "xcode version": "8.0",
-    "xctest": true
-  }
-]
-```
-This defines two tests to run, first `ios_chrome_unittests` will be run with
-`--foo` and `--bar` passed directly to the test on the command line. Next,
-`ios_chrome_integration_egtests` will be run as an xctest. `"xctest": true`
-must be specified for all xctests, it is an error to try and launch an xctest as
-a regular test.
-
-An `include` dict defines a list of tests to import from the `tests`
-subdirectory in the configs directory. For example:
-```json
-"tests": [
-  {
-    "include": "common_tests.json",
-    "device type": "iPhone 5s",
-    "os": "10.0",
-    "xcode version": "8.0"
-  }
-]
-```
-This dict says to import the list of tests from the `tests` subdirectory and run
-each one on an `iPhone 5s` running iOS `10.0` using Xcode `8.0`. Here's what
-`common_tests.json` might look like:
-```json
-"tests": [
-  {
-    "app": "ios_chrome_unittests"
-  },
-  {
-    "app": "ios_net_unittests"
-  },
-  {
-    "app": "ios_web_unittests"
-  },
-]
-```
-Includes may contain other keys besides `app` which can then be omitted in the
-bot config. For example if `common_tests.json` specifies:
-```json
-"tests": [
-  {
-    "app": "ios_chrome_integration_egtests",
-    "xctest": true,
-    "xcode version": "8.0"
-  }
-]
-```
-Then the bot config may omit the `xctest` or `xcode version` keys, for example:
-```json
-{
-  "comments": [
-    "Sample config for a bot."
-  ],
-  "gn_args": [
-    "is_debug=true",
-    "target_cpu=\"x64\""
-  ],
-  "tests": [
-    {
-      "include": "common_tests.json",
-      "device type": "iPhone 5s",
-      "os": "10.0"
-    }
-  ]
-}
-```
-Includes are not recursive, so `common_tests.json` may not itself include any
-`include` dicts.
-
-### Uploading compiled artifacts from a bot
-
-A bot may be configured to upload compiled artifacts. This is defined by the
-`upload` key. For example:
-```json
-{
-  "comments": [
-    "Sample config for a bot which uploads artifacts."
-  ],
-  "gn_args": [
-    "is_debug=true",
-    "target_cpu=\"x64\""
-  ],
-  "upload": [
-    {
-      "artifact": "Chromium.breakpad",
-      "bucket": "my-gcs-bucket",
-    },
-    {
-      "artifact": "Chromium.app",
-      "bucket": "my-gcs-bucket",
-      "compress": true,
-    },
-    {
-      "artifact": "Chromium.breakpad",
-      "symupload": true,
-    }
-  ]
-}
-```
-After compilation, the bot will upload three artifacts. First the
-`Chromium.breakpad` symbols will be uploaded to
-`gs://my-gcs-bucket/<buildername>/<buildnumber>/Chromium.breakpad`. Next
-`Chromium.app` will be tarred, gzipped, and uploaded to
-`gs://my-gcs-bucket/<buildername>/<buildnumber>/Chromium.tar.gz`. Finally
-the `Chromium.breakpad` symbols will be uploaded to the [breakpad] crash
-reporting server where they can be used to symbolicate stack traces.
-
-If `artifact` is a directory, you must specify `"compress": true`.
-
-[analyzer]: ../tools/mb
-[breakpad]: https://chromium.googlesource.com/breakpad/breakpad
-[buildbucket]: https://cr-buildbucket.appspot.com
-[chromium.fyi]: https://build.chromium.org/p/chromium.fyi/waterfall
-[chromium.mac]: https://build.chromium.org/p/chromium.mac
-[clang]: ../tools/clang
-[commit queue]: https://dev.chromium.org/developers/testing/commit-queue
-[gitiles]: https://gerrit.googlesource.com/gitiles
-[GN]: ../tools/gn
-[instructions]: ./ios_build_instructions.md
-[iOS recipes]: https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipes/ios
-[iOS simulator]: ../testing/iossim
-[recipe module]: https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/ios
-[recipes]: https://chromium.googlesource.com/infra/infra/+/HEAD/doc/users/recipes.md
-[simulator]: https://developer.apple.com/library/content/documentation/IDEs/Conceptual/iOS_Simulator_Guide/Introduction/Introduction.html
-[src/ios/build/bots]: ../ios/build/bots
-[src/ios/build/bots/scripts]: ../ios/build/bots/scripts
-[swarming]: https://github.com/luci/luci-py/tree/master/appengine/swarming
-[swarming server]: https://chromium-swarm.appspot.com
-[test runner]: ../ios/build/bots/scripts/test_runner.py
-[tools/build]: https://chromium.googlesource.com/chromium/tools/build
-[try job access]: https://www.chromium.org/getting-involved/become-a-committer#TOC-Try-job-access
-[try server]: https://build.chromium.org/p/tryserver.chromium.mac/waterfall
-[tryserver.chromium.mac]: https://build.chromium.org/p/tryserver.chromium.mac/waterfall
-[universal binary]: https://en.wikipedia.org/wiki/Universal_binary
-[xctest]: https://developer.apple.com/reference/xctest
+The new file location is [//docs/ios/infra.md](ios/infra.md)
\ No newline at end of file
diff --git a/chromium/docs/ios_voiceover.md b/chromium/docs/ios_voiceover.md
index 3f8a5cdf798..a217457554e 100644
--- a/chromium/docs/ios_voiceover.md
+++ b/chromium/docs/ios_voiceover.md
@@ -1,48 +1,5 @@
-# VoiceOver
+# This document has moved
 
-VoiceOver is an Accessibility feature available on Apple platforms. It provides
-an interface between your app and your blind or low-vision users. In short, it's
-a screen reader.
+NOTE: Please update your link to this file!
 
-## Overview
-
-[Activating VoiceOver](#Activate-VoiceOver) fundamentally changes the touch
-interface of an iOS device, so when you activate it, you need to know these
-basic commands to navigate:
-
--   VoiceOver focuses an item on the screen and speaks it to the user.
--   To navigate between items, you can either flick left/right to go to the
-    previous/next item, or you can drag your finger around the screen.
--   Double tapping anywhere on the screen activates the item (no need to double
-    tap exactly on the item on the screen).
--   Items have a label (describing the item) and can have among others:
-    -   traits (describing the item: a header, a button, selection state, etc.);
-    -   a hint (describing how to interact with the item).
-
-The following video is a great summary. The content is succinct, high quality
-and up-to-date, even though the video quality is low and the demo is on an
-iPhone 3GS.
-
-[![Video screenshot]][Video link]
-
-## Activate VoiceOver
-
-Go to `Settings > General > Accessibility > VoiceOver` and toggle the top
-switch.
-
-Alternatively, if you are activating/deactivating VoiceOver often, I'd advise
-to set it as the Accessibility Shortcut. When enabled, a triple tap on the Home
-button will toggle VoiceOver ON and OFF from anywhere.
-```
-Settings > General > Accessibility > Accessibility Shortcut
-```
-
-## Additional Resources
-
--   [Apple presentation of VoiceOver]
--   [AppleVis intro to VoiceOver]
-
-[Apple presentation of VoiceOver]: http://www.apple.com/accessibility/osx/voiceover/
-[AppleVis intro to VoiceOver]: http://www.applevis.com/guides/ios-miscellaneous-voiceover/intro-ios-accessibility-blind-and-low-vision-users
-[Video screenshot]: https://img.youtube.com/vi/WxQ2qKShvmc/0.jpg
-[Video link]: https://www.youtube.com/watch?v=WxQ2qKShvmc "iPhone VoiceOver Function For People With Disabilities"
+[The new file location is //docs/ios/voiceover.md](ios/voiceover.md)
\ No newline at end of file
diff --git a/chromium/docs/linux_cast_build_instructions.md b/chromium/docs/linux_cast_build_instructions.md
new file mode 100644
index 00000000000..9b38baa905a
--- /dev/null
+++ b/chromium/docs/linux_cast_build_instructions.md
@@ -0,0 +1,164 @@
+# Checking out and building Cast on Linux
+
+**Note**: it is **not possible** to build a binary functionally
+equivalent to a Chromecast. This is to build a single-page content
+embedder with similar functionality to Cast products.
+
+## Instructions for Google Employees
+
+Are you a Google employee? See
+[go/building-linux-cast](https://goto.google.com/building-linux-cast) instead.
+
+[TOC]
+
+## System requirements
+
+*   A 64-bit Intel machine with at least 8GB of RAM. More than 16GB is highly
+    recommended.
+*   At least 100GB of free disk space.
+*   You must have Git and Python installed already.
+
+Most development is done on Ubuntu (currently 14.04, Trusty Tahr). There are
+some instructions for other distros below, but they are mostly unsupported.
+
+## Install `depot_tools`
+
+Clone the `depot_tools` repository:
+
+```shell
+$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
+```
+
+Add `depot_tools` to the end of your PATH (you will probably want to put this
+in your `~/.bashrc` or `~/.zshrc`). Assuming you cloned `depot_tools` to
+`/path/to/depot_tools`:
+
+```shell
+$ export PATH="$PATH:/path/to/depot_tools"
+```
+
+## Get the code
+
+Create a `chromium` directory for the checkout and change to it (you can call
+this whatever you like and put it wherever you like, as long as the full path
+has no spaces):
+
+```shell
+$ mkdir ~/chromium && cd ~/chromium
+```
+
+Run the `fetch` tool from depot_tools to check out the code and its
+dependencies.
+
+```shell
+$ fetch --nohooks chromium
+```
+
+If you don't want the full repo history, you can save a lot of time by
+adding the `--no-history` flag to `fetch`.
+
+Expect the command to take 30 minutes on even a fast connection, and many
+hours on slower ones.
+
+If you've already installed the build dependencies on the machine (from another
+checkout, for example), you can omit the `--nohooks` flag and `fetch`
+will automatically execute `gclient runhooks` at the end.
+
+When `fetch` completes, it will have created a hidden `.gclient` file and a
+directory called `src` in the working directory. The remaining instructions
+assume you have switched to the `src` directory:
+
+```shell
+$ cd src
+```
+
+### Install additional build dependencies
+
+Once you have checked out the code, and assuming you're using Ubuntu, run
+[build/install-build-deps.sh](/build/install-build-deps.sh)
+
+You may need to adjust the build dependencies for other distros. There are
+some [notes](#notes) at the end of this document, but we make no guarantees
+for their accuracy.
+
+### Run the hooks
+
+Once you've run `install-build-deps` at least once, you can now run the
+Chromium-specific hooks, which will download additional binaries and other
+things you might need:
+
+```shell
+$ gclient runhooks
+```
+
+*Optional*: You can also [install API
+keys](https://www.chromium.org/developers/how-tos/api-keys) if you want your
+build to talk to some Google services, but this is not necessary for most
+development and testing purposes.
+
+## Setting up the build
+
+Chromium uses [Ninja](https://ninja-build.org) as its main build tool along
+with a tool called [GN](../tools/gn/docs/quick_start.md) to generate `.ninja`
+files. You can create any number of *build directories* with different
+configurations. To create a build directory, run:
+
+```shell
+$ gn gen out/Default --args='is_chromecast=true'
+```
+
+* You only have to run this once for each new build directory, Ninja will
+  update the build files as needed.
+* You can replace `Default` with another name, but
+  it should be a subdirectory of `out`.
+* For other build arguments, including release settings, see [GN build
+  configuration](https://www.chromium.org/developers/gn-build-configuration).
+  The default will be a debug component build matching the current host
+  operating system and CPU.
+* For more info on GN, run `gn help` on the command line or read the
+  [quick start guide](../tools/gn/docs/quick_start.md).
+
+### <a name="faster-builds"></a>Faster builds
+
+You might try some of the suggestions on the
+[Linux build setup](linux_build_instructions.md#faster-builds).
+
+## Build cast\_shell
+
+Build cast\_shell with Ninja using the command:
+
+```shell
+$ ninja -C out/Default cast_shell
+```
+
+## Run cast\_shell
+
+Once it is built, you can simply run it:
+
+```shell
+$ out/Default/cast_shell --ozone-platform=x11 http://google.com
+```
+
+## Update your checkout
+
+To update an existing checkout, you can run
+
+```shell
+$ git rebase-update
+$ gclient sync
+```
+
+The first command updates the primary Chromium source repository and rebases
+any of your local branches on top of tip-of-tree (aka the Git branch
+`origin/master`). If you don't want to use this script, you can also just use
+`git pull` or other common Git commands to update the repo.
+
+The second command syncs dependencies to the appropriate versions and re-runs
+hooks as needed.
+
+## Tips, tricks, and troubleshooting
+
+### More links
+
+*   Want to use Eclipse as your IDE? See
+    [LinuxEclipseDev](linux_eclipse_dev.md).
diff --git a/chromium/docs/linux_chromium_arm.md b/chromium/docs/linux_chromium_arm.md
index d69b9233712..180a4970dfe 100644
--- a/chromium/docs/linux_chromium_arm.md
+++ b/chromium/docs/linux_chromium_arm.md
@@ -28,8 +28,7 @@ automatically be installed by gclient runhooks installed if you have
 
 To install the sysroot manually you can run:
 
-    ./chrome/installer/linux/sysroot_scripts/install-debian.wheezy.sysroot.py \
-        --arch=arm
+    ./build/linux/sysroot_scripts/install-sysroot.py --arch=arm
 
 ### Building
 
diff --git a/chromium/docs/audio_focus.md b/chromium/docs/media/audio_focus.md
index 5b47fd16524..5b47fd16524 100644
--- a/chromium/docs/audio_focus.md
+++ b/chromium/docs/media/audio_focus.md
diff --git a/chromium/docs/media/autoplay.md b/chromium/docs/media/autoplay.md
new file mode 100644
index 00000000000..0312713f9ca
--- /dev/null
+++ b/chromium/docs/media/autoplay.md
@@ -0,0 +1,49 @@
+# Autoplay of HTMLMediaElements
+
+Autoplay is the concept of playing media elements without user gesture. On
+desktop, autoplay is always allowed. On mobile, only muted video elements are
+allowed to autoplay. The autoplay logic follows
+the
+[HTML spec](https://html.spec.whatwg.org/multipage/embedded-content.html#media-elements).
+
+There are two ways of initiating autoplay:
+
+* Autoplay by attribute: Setting the `autoplay` attribute on the media element.
+  The element will try to autoplay when the `readyState` changes to
+  HAVE_ENOUGH_DATA.
+* Autoplay by `play()` method: Explicitly calling the `play()` method without
+  user gesture.
+
+## User gesture lock
+
+Each media element has a user gesture lock. If the element is allowed to
+autoplay, the lock is initialized as `false`, otherwise it's `true`.
+
+When the element is trying to initate autoplay, we check the gesture lock. If
+the lock is `false`, it will be allowed. Otherwise autoplay will be blocked. An
+exception is that if the element is a muted video element, the gesture lock
+check will be bypassed.
+
+To unlock the gesture lock (make it `false`). The page needs to call play() or
+load() on the element when responding to a user gesture.
+
+## Autoplay flowchart
+
+The treatments of autoplay by different methods are different. For autoplay by
+attribute, it is:
+
+![Autoplay by attribute](autoplay_by_attribute.png)
+
+This means if autoplay is initiated by attribute, it enters the autoplaying
+phase, we play it as long as the video is visible. When the page explicitly
+calls `play()`, `pause()`, we leave the autoplaying phase. When the page tries
+to unmute the video, we check the gesture lock and pause the video if it is
+still `true`.
+
+For autoplay by `play()` method, it is:
+
+![Autoplay by play() method](autoplay_by_play_method.png)
+
+This means if autoplay is initiated by `play()` method, we continue playing the
+video as normal `play()`. However if the page tries to unmute the video, we check
+the gesture lock and pause the video if it is still `true`.
diff --git a/chromium/docs/media/autoplay_by_attribute.png b/chromium/docs/media/autoplay_by_attribute.png
new file mode 100644
index 00000000000..2ac7b228609
--- /dev/null
+++ b/chromium/docs/media/autoplay_by_attribute.png
diff --git a/chromium/docs/media/autoplay_by_play_method.png b/chromium/docs/media/autoplay_by_play_method.png
new file mode 100644
index 00000000000..f57d68d1b3e
--- /dev/null
+++ b/chromium/docs/media/autoplay_by_play_method.png
diff --git a/chromium/docs/memory-infra/probe-cc.md b/chromium/docs/memory-infra/probe-cc.md
index d02066fd997..ebe653533d3 100644
--- a/chromium/docs/memory-infra/probe-cc.md
+++ b/chromium/docs/memory-infra/probe-cc.md
@@ -43,12 +43,14 @@ like tile_memory, in that they are shared with cc/resource_memory.
 Note that depending on the path being used, CC memory may be either shared
 memory or GPU memory:
 
+```
 Path         | Tile Memory Type     | Staging Memory Type
 -------------|-------------------------------------------
 Bitmap       | Shared Memory        | N/A
 One Copy     | GPU Memory           | Shared Memory
 Zero Copy    | GPU or Shared Memory | N/A
 GPU          | GPU Memory           | N/A
+```
 
 Note that these values can be determined from a memory-infra dump. For a given
 resource, hover over the small green arrow next to it's "size". This will show
diff --git a/chromium/docs/old_cast_build_instructions.md b/chromium/docs/old_cast_build_instructions.md
deleted file mode 100644
index 734f41fd8e1..00000000000
--- a/chromium/docs/old_cast_build_instructions.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Cast Build Instructions
-
-**Note**: it is **not possible** to build a binary functionally
-equivalent to a Chromecast. This is to build a single-page content
-embedder with similar functionality to Cast products.
-
-## Prerequisites
-
-*   See the [Linux build prerequisites](https://chromium.googlesource.com/chromium/src/+/master/docs/linux_build_instructions_prerequisites.md)
-
-## Setting Up
-
-*   Cast Linux build only: [Linux build
-    setup](https://chromium.googlesource.com/chromium/src/+/master/docs/linux_build_instructions.md)
-    is sufficient.
-*   Cast Linux and Android builds: follow the [Android build
-    setup](https://www.chromium.org/developers/how-tos/android-build-instructions)
-    instructions.
-
-## Building/running cast\_shell (Linux)
-
-```shell
-gn gen out/Debug --args='is_chromecast=true is_debug=true'
-ninja -C out/Debug cast_shell
-```
-
-```shell
-out/Debug/cast_shell --ozone-platform=x11 http://google.com
-```
-
-## Building/running cast\_shell\_apk (Android)
-
-```shell
-gn gen out/Debug --args='is_chromecast=true target_os="android" is_debug=true'
-ninja -C out/Debug cast_shell_apk
-```
-
-```shell
-adb install out/Debug/apks/CastShell.apk
-adb shell am start -d "http://google.com" org.chromium.chromecast.shell/.CastShellActivity
-```
\ No newline at end of file
diff --git a/chromium/docs/optional.md b/chromium/docs/optional.md
index dd028f16783..70c9efb8d15 100644
--- a/chromium/docs/optional.md
+++ b/chromium/docs/optional.md
@@ -63,10 +63,10 @@ opt_1 == 1; // true
 opt_1 == base::nullopt_t; // false
 ```
 
-`base::Optional<T>` has a helper function `make_optional<T&&>`:
+`base::Optional<T>` has a helper function `base::make_optional<T&&>`:
 
 ```C++
-base::Optional<int> opt = make_optional<int>(GetMagicNumber());
+base::Optional<int> opt = base::make_optional<int>(GetMagicNumber());
 ```
 
 Finally, `base::Optional<T>` is integrated with `std::hash`, using
diff --git a/chromium/docs/ozone_overview.md b/chromium/docs/ozone_overview.md
index 2ba7f29f388..a0e3292bc3c 100644
--- a/chromium/docs/ozone_overview.md
+++ b/chromium/docs/ozone_overview.md
@@ -154,9 +154,11 @@ Then to run for example the headless platform:
 
 ### Linux Desktop - ([waterfall](https://build.chromium.org/p/chromium.fyi/builders/Ozone%20Linux/))
 
-**Warning: Experimental support for Linux Desktop is available since m57
-but this is still [in development](https://crbug.com/295089) and currently has
-many bugs.**
+**Warning: Experimental support for Linux Desktop is available since m57 but
+  upstream support has always been a bit fragile. For now, development
+  continues on the
+  [ozone-wayland-dev](https://github.com/Igalia/chromium/tree/ozone-wayland-dev)
+  branch.**
 
 To build `chrome`, do this from the `src` directory:
 
@@ -167,9 +169,7 @@ ninja -C out/OzoneLinuxDesktop chrome
 Then to run for example the X11 platform:
 
 ``` shell
-./out/OzoneLinuxDesktop/chrome --ozone-platform=x11 \
-                               --mash \
-                               --window-manager=simple_wm
+./out/OzoneLinuxDesktop/chrome --ozone-platform=x11 --mus
 ```
 
 ### GN Configuration notes
@@ -245,7 +245,9 @@ This platform provides support for the
 initially developed by Intel as
 [a fork of chromium](https://github.com/01org/ozone-wayland)
 and then partially upstreamed.
-It is still actively being developed in the chromium tree, feel free to discuss
+It is still actively being developed on the
+[ozone-wayland-dev](https://github.com/Igalia/chromium/tree/ozone-wayland-dev)
+branch, feel free to discuss
 with us on freenode.net, `#ozone-wayland` channel or on `ozone-dev`.
 
 Below are some quick build & run instructions. It is assumed that you are
@@ -255,9 +257,7 @@ following commands:
 ``` shell
 gn args out/OzoneWayland --args="use_ozone=true enable_package_mash_services=true"
 ninja -C out/OzoneWayland chrome
-./out/OzoneWayland/chrome --ozone-platform=wayland \
-                          --mash \
-                          --window-manager=simple_wm
+./out/OzoneWayland/chrome --ozone-platform=wayland --mus
 ```
 
 ### Caca
diff --git a/chromium/docs/qtcreator.md b/chromium/docs/qtcreator.md
index 932cc093c3f..38c0aa060b4 100644
--- a/chromium/docs/qtcreator.md
+++ b/chromium/docs/qtcreator.md
@@ -12,7 +12,8 @@ not require project configuration.
 
 ### Workflow
 
-1. `ctrl+k` Activate Locator, you can open file(not support sublime-like-search) or type `. ` go to symbol.
+1. `ctrl+k` Activate Locator, you can open file(not support sublime-like-search)
+   or type `. ` go to symbol.
 2. `ctrl+r` Build and Run, `F5` Debug.
 3. `F4` switch between header file and cpp file.
 4. `ctrl+shift+r` rename symbol under cursor.
@@ -30,8 +31,9 @@ block you while parsing.
 #### Code Style
 
 1. Help - About Plugins enable Beautifier.
-2. Tools - Options - Beautifier - Clang Format, select use predefined style: 
-chromium. You can also set a keyboard shortcut for it.
+2. Tools - Options - Beautifier - Clang Format, 
+   change Clang format command: `$depot_tools_dir/clang-format`, select use 
+   predefined style: file. You can also set a keyboard shortcut for it.
 3. Tools - Options - Code Style import this xml file
 
 ```
@@ -98,10 +100,6 @@ standalone GDB frontend. **
 
 ### Tips, tricks, and troubleshooting
 
-#### Make GDB start fast
-
-Add `gdb_index = true` to `gn args`.
-
 #### Debugger shows start then finish
 
 ```
diff --git a/chromium/docs/sync/model_api.md b/chromium/docs/sync/model_api.md
index eebf34d8a09..67ff6e3c936 100644
--- a/chromium/docs/sync/model_api.md
+++ b/chromium/docs/sync/model_api.md
@@ -261,6 +261,8 @@ be started again from scratch on the next client restart.
     [`ProfileSyncComponentsFactoryImpl::RegisterDataTypes`][RegisterDataTypes].
 *   Tell sync how to access your `ModelTypeSyncBridge` in
     [`ChromeSyncClient::GetSyncBridgeForModelType`][GetSyncBridge].
+*   Add your KeyedService dependency to
+    [`ProfileSyncServiceFactory`][ProfileSyncServiceFactory].
 *   Add to the [start order list][kStartOrder].
 *   Add an field for encrypted data to [`NigoriSpecifics`][NigoriSpecifics].
 *   Add to two encrypted types translation functions in
@@ -279,6 +281,7 @@ be started again from scratch on the next client restart.
 [ModelTypeController]: https://cs.chromium.org/chromium/src/components/sync/driver/model_type_controller.h
 [RegisterDataTypes]: https://cs.chromium.org/search/?q="ProfileSyncComponentsFactoryImpl::RegisterDataTypes"
 [GetSyncBridge]: https://cs.chromium.org/search/?q=GetSyncBridgeForModelType+file:chrome_sync_client.cc
+[ProfileSyncServiceFactory]: https://cs.chromium.org/search/?q=:ProfileSyncServiceFactory%5C(%5C)
 [kStartOrder]: https://cs.chromium.org/search/?q="kStartOrder[]"
 [NigoriSpecifics]: https://cs.chromium.org/chromium/src/components/sync/protocol/nigori_specifics.proto
 [nigori_util]: https://cs.chromium.org/chromium/src/components/sync/syncable/nigori_util.cc
diff --git a/chromium/docs/testing/web_platform_tests.md b/chromium/docs/testing/web_platform_tests.md
index 063ca3e368c..eec59f43200 100644
--- a/chromium/docs/testing/web_platform_tests.md
+++ b/chromium/docs/testing/web_platform_tests.md
@@ -6,12 +6,9 @@ mission of improving the web. We believe that leveraging and contributing to a
 shared test suite is one of the most important tools in achieving
 interoperability between browsers. The [web-platform-tests
 repository](https://github.com/w3c/web-platform-tests) is the primary shared
-test suite where all browser engines are collaborating. There's also a
-[csswg-test repository](https://github.com/w3c/csswg-test) for CSS tests, but
-that will [soon be merged into
-web-platform-tests](https://github.com/w3c/csswg-test/issues/1102).
+test suite where all browser engines are collaborating.
 
-Chromium has 2-way import/export process with the upstream web-platform-tests
+Chromium has a 2-way import/export process with the upstream web-platform-tests
 repository, where tests are imported into
 [LayoutTests/external/wpt](../../third_party/WebKit/LayoutTests/external/wpt)
 and any changes to the imported tests are also exported to web-platform-tests.
@@ -23,13 +20,13 @@ web-platform-tests, including tips for writing and reviewing tests.
 
 ## Importing tests
 
-Chromium has mirrors
-([web-platform-tests](https://chromium.googlesource.com/external/w3c/web-platform-tests/),
-[csswg-test](https://chromium.googlesource.com/external/w3c/csswg-test/)) of the
+Chromium has a mirror
+([web-platform-tests](https://chromium.googlesource.com/external/w3c/web-platform-tests/)
+of the
 GitHub repos, and periodically imports a subset of the tests so that they are
 run as part of the regular Blink layout test testing process.
 
-The goal of this process are to be able to run web-platform-tests unmodified
+The goals of this process are to be able to run web-platform-tests unmodified
 locally just as easily as we can run the Blink tests, and ensure that we are
 tracking tip-of-tree in the web-platform-tests repository as closely as
 possible, and running as many of the tests as possible.
@@ -37,18 +34,35 @@ possible, and running as many of the tests as possible.
 ### Automatic import process
 
 There is an automatic process for updating the Chromium copy of
-web-platform-tests. The import is done by the builder [w3c-test-autoroller
-builder](https://build.chromium.org/p/chromium.infra.cron/builders/w3c-test-autoroller).
+web-platform-tests. The import is done by the builder [wpt-importer
+builder](https://build.chromium.org/p/chromium.infra.cron/builders/wpt-importer).
 
 The easiest way to check the status of recent imports is to look at:
 
--   Recent logs on Buildbot for [w3c-test-autoroller
-    builder](https://build.chromium.org/p/chromium.infra.cron/builders/w3c-test-autoroller)
+-   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).
 
 Automatic imports are intended to run at least once every 24 hours.
 
+### 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.
+
 ### Skipped tests
 
 We control which tests are imported via a file called
@@ -58,8 +72,8 @@ which has a list of directories to skip while importing.
 In addition to the directories and tests explicitly skipped there, tests may
 also be skipped for a couple other reasons, e.g. if the file path is too long
 for Windows. To check what files are skipped in import, check the recent logs
-for [w3c-test-autoroller
-builder](https://build.chromium.org/p/chromium.infra.cron/builders/w3c-test-autoroller).
+for [wpt-importer
+builder](https://build.chromium.org/p/chromium.infra.cron/builders/wpt-importer).
 
 ### Manual import
 
diff --git a/chromium/docs/ui/views/macviews_release.md b/chromium/docs/ui/views/macviews_release.md
index ac5dd380b73..825376c4bd3 100644
--- a/chromium/docs/ui/views/macviews_release.md
+++ b/chromium/docs/ui/views/macviews_release.md
@@ -35,7 +35,7 @@ dialogs are:
 5. One-click signin
 6. Site permissions bubble
 7. "Card unmask prompt" (TODO(ellyjones): what is this?)
-8. Website settings dialog
+8. Page info dialog
 
 Once all of these dialogs are converted and tested behind the feature, we can
 ship to canary and dev channels and watch for any performance or crash rate
diff --git a/chromium/docs/vscode.md b/chromium/docs/vscode.md
index 474de314aa2..7418aa02eab 100644
--- a/chromium/docs/vscode.md
+++ b/chromium/docs/vscode.md
@@ -1,87 +1,483 @@
-# Use Visual Studio Code on Chromium code base
+# Visual Studio Code Dev
+
+Visual Studio Code is a free, lightweight and powerful code editor for Windows,
+Mac and Linux, based on Electron/Chromium. It has built-in support for
+JavaScript, TypeScript and Node.js and a rich extension ecosystem that adds
+intellisense, debugging, syntax highlighting etc. for many languages (C++,
+Python, Go). It works without too much setup. Get started
+[here](https://code.visualstudio.com/docs).
+
+It is NOT a full-fledged IDE like Visual Studio. The two are completely
+separate products. The only commonality with Visual Studio is that both are
+from Microsoft.
+
+Here's what works well:
+
+*   Editing code works well especially when you get used to the [keyboard
+    shortcuts](https://code.visualstudio.com/docs/customization/keybindings).
+    VS Code is very responsive and can handle even big code bases like Chromium.
+*   Git integration is a blast. Built-in side-by-side view, local commit and
+    even extensions for
+    [history](https://marketplace.visualstudio.com/items?itemName=donjayamanne.githistory)
+    and
+    [blame view](https://marketplace.visualstudio.com/items?itemName=ryu1kn.annotator).
+*   [Debugging](https://code.visualstudio.com/Docs/editor/debugging) works
+    well, even though startup times can be fairly high (~40 seconds with
+    gdb on Linux, much lower on Windows). You can step through code, inspect
+    variables, view call stacks for multiple threads etc.
+*   Opening files and searching solution-wide works well now after having
+    problems in earlier versions.
+*   Building works well. Build tools are easy to integrate. Warnings and errors
+    are displayed on a separate page and you can click to jump to the
+    corresponding line of code.
 
 [TOC]
 
-[Visual Studio Code](http://code.visualstudio.com/)
-([Wikipedia](https://en.wikipedia.org/wiki/Visual_Studio_Code)) is a
-multi-platform code editor that is itself based on Electron which is based on 
-Chromium. Visual Studio Code has a growing community and base of installable 
-extensions and themes. It works without too much setup.
+## Updating This Page
+
+Please keep this doc up-to-date. VS Code is still in active development and
+subject to changes. This doc is checked into the Chromium git repo, so if you
+make changes, read the [documentation
+guidelines](https://chromium.googlesource.com/chromium/src/+/lkgr/docs/documentation_guidelines.md)
+and [submit a change list](https://www.chromium.org/developers/contributing-code).
+
+All file paths and commands have been tested on Linux. Windows and Mac might
+require a slightly different setup (e.g. `Ctrl` -> `Cmd`). Please update this
+page accordingly.
+
+## Setup
+
+### Installation
+
+Follow the steps on https://code.visualstudio.com/docs/setup/setup-overview. To
+run it on Linux, just navigate to `chromium/src` folder and type `code .` in a
+terminal. The argument to `code` is the base directory of the workspace. VS
+Code does not require project or solution files. However, it does store
+workspace settings in a `.vscode` folder in your base directory.
+
+### Useful Extensions
+
+Up to now, you have a basic version of VS Code without much language support.
+Next, we will install some useful extensions. Jump to the extensions window
+(`Ctrl+Shift+X`) and install these extensions, you will most likely use them
+every day:
+
+*   ***C/C++*** -
+    Intellisense, code formatting, debugging.
+*   ***Python*** -
+    Linting, intellisense, code formatting, refactoring, debugging, snippets.
+*   ***Toggle Header/Source*** -
+    Toggles between .cc and .h with `F4`. The C/C++ extension supports this as
+    well through `Alt+O`. Last time I checked this was very laggy, but they
+    might have improved it since, so this extension might not be necessary.
+*   ***Protobuf support*** -
+    Syntax highlighting for .proto files.
+*   ***you-complete-me*** -
+    YouCompleteMe code completion for VS Code. It works fairly well in Chromium.
+*   ***Rewrap*** -
+    Wrap lines at 80 characters with `Alt+Q`.
+
+To install You-Complete-Me, enter these commands in a terminal:
+
+```
+$ git clone https://github.com/Valloric/ycmd.git ~/.ycmd
+$ cd ~/.ycmd
+$ ./build.py --clang-completer
+```
+
+The following extensions might be useful for you as well:
 
-## Install extensions
+*   ***Annotator*** -
+    Git blame view.
+*   ***Git History (git log)*** -
+    Git history view.
+*   ***chromium-codesearch*** -
+    Code search (CS) integration, see [Chromium Code
+    Search](https://cs.chromium.org/), in particular *open current line in CS*,
+    *show references* and *go to definition*. Very useful for existing code. By
+    design, won't work for code not checked in yet. Overrides default C/C++
+    functionality. Had some issues last time I tried (extensions stopped
+    working), so use with care.
+*   ***change-case*** -
+    Quickly change the case of the current selection or current word.
+*   ***Instant Markdown*** -
+    Instant markdown (.md) preview in your browser as you type. This document
+    was written with this extension!
+*   ***Clang-Format*** -
+    Format your code using clang-format. The C/C++ extension already supports
+    format-on-save (see `C_Cpp.clang_format_formatOnSave` setting). This
+    extension adds the ability to format a document or the current selection on
+    demand.
 
-`ctrl+p` paste `ext install cpptools you-complete-me clang-format` then enter. 
-For more extensions: https://marketplace.visualstudio.com/search?target=vscode
+Also be sure to take a look at the
+[VS Code marketplace](https://marketplace.visualstudio.com/VSCode) to check out other
+useful extensions.
 
-Highly recommend you also install your favorite keymap. 
+### Color Scheme
+Press `Ctrl+Shift+P, color, Enter` to pick a color scheme for the editor. There
+are also tons of [color schemes available for download on the
+marketplace](https://marketplace.visualstudio.com/search?target=VSCode&category=Themes&sortBy=Downloads).
 
-An Example to install eclipse keymaps `ext install vscode-eclipse-keybindings`. 
-You can search keymaps here. 
-https://marketplace.visualstudio.com/search?target=vscode&category=Keymaps
+### Usage Tips
+*   `Ctrl+P` opens a search box to find and open a file.
+*   `F1` or `Ctrl+Shift+P` opens a search box to find a command (e.g. Tasks: Run
+    Task).
+*   `Ctrl+K, Ctrl+S` opens the key bindings editor.
+*   ``Ctrl+` `` toggles the built-in terminal.
+*   `Ctrl+Shift+M` toggles the problems view (linter warnings, compile errors
+    and warnings). You'll swicth a lot between terminal and problem view during
+    compilation.
+*   `Alt+O` switches between the source/header file.
+*   `Ctrl+G` jumps to a line.
+*   `F12` jumps to the definition of the symbol at the cursor (also available on
+    right-click context menu).
+*   `Shift+F12` or `F1, CodeSearchReferences, Return` shows all references of
+    the symbol at the cursor.
+*   `F1, CodeSearchOpen, Return` opens the current file in Code Search.
+*   `Ctrl+D` selects the word at the cursor. Pressing it multiple times
+    multi-selects the next occurrences, so typing in one types in all of them,
+    and `Ctrl+U` deselects the last occurrence.
+*   `Ctrl+K, Z` enters Zen Mode, a fullscreen editing mode with nothing but the
+    current editor visible.
+*   `Ctrl+X` without anything selected cuts the current line. `Ctrl+V` pastes
+    the line.
 
+## Setup For Chromium
 
-## Settings
+VS Code is configured via JSON files. This paragraph contains JSON configuration
+files that are useful for Chromium development, in particular. See [VS Code
+documentation](https://code.visualstudio.com/docs/customization/overview) for an
+introduction to VS Code customization.
 
-Open Settings `File/Code - Preferences - Settings` and add the following 
-settings.
+### Workspace Settings
+Open the file chromium/src/.vscode/settings.json and add the following settings.
+Remember to replace `<full_path_to_your_home>`!
 
 ```
 {
+  // Default tab size of 2.
   "editor.tabSize": 2,
+  // Do not figure out tab size from opening a file.
+  "editor.detectIndentation": false,
+  // Add a line at 80 characters.
   "editor.rulers": [80],
-  // Exclude
+  // Optional: Highlight current line at the left of the editor.
+  "editor.renderLineHighlight": "gutter",
+  // Optional: Don't automatically add closing brackets. It gets in the way.
+  "editor.autoClosingBrackets": false,
+  // Optional: Enable a tiny 30k feet view of your doc.
+  "editor.minimap.enabled": true,
+  "editor.minimap.maxColumn": 80,
+  "editor.minimap.renderCharacters": false,
+  // Trim tailing whitespace on save.
+  "files.trimTrailingWhitespace": true,
+  // Optional: Do not open files in 'preview' mode. Opening a new file in can
+  //           replace an existing one in preview mode, which can be confusing.
+  "workbench.editor.enablePreview": false,
+  // Optional: Same for files opened from quick open (Ctrl+P).
+  "workbench.editor.enablePreviewFromQuickOpen": false,
+
+  "files.associations": {
+    // Adds xml syntax highlighting for grd files.
+    "*.grd" : "xml",
+    // Optional: .gn and .gni are not JavaScript, but at least it gives some
+    // approximate syntax highlighting. Ignore the linter warnings!
+    "*.gni" : "javascript",
+    "*.gn" : "javascript"
+  },
+
   "files.exclude": {
-    "**/.git": true,
-    "**/.svn": true,
-    "**/.hg": true,
-    "**/.DS_Store": true,
-    "**/out": true
+    // Ignore build output folders.
+    "out*/**": true
   },
-  // YCM
-  "ycmd.path": "<your_ycmd_path>",
-  "ycmd.global_extra_config": 
-      "<your_chromium_path>/src/tools/vim/chromium.ycm_extra_conf.py",
+
+  // Wider author column for annotator extension.
+  "annotator.annotationColumnWidth": "24em",
+
+  // C++ clang format settings.
+  "C_Cpp.clang_format_path": "<full_path_to_your_home>/depot_tools/clang-format",
+  "C_Cpp.clang_format_sortIncludes": true,
+  "C_Cpp.clang_format_formatOnSave": true,
+
+  // YouCompleteMe
+  "ycmd.path": "<full_path_to_your_home>/.vim/bundle/YouCompleteMe/third_party/ycmd",
+  "ycmd.global_extra_config": "<full_path_to_your_home>/chromium/src/tools/vim/.ycm_extra_conf.py",
   "ycmd.confirm_extra_conf": false,
-  "ycmd.use_imprecise_get_type": true,
-  // clang-format
-  "clang-format.style": "Chromium",
-  "editor.formatOnSave": true
 }
 ```
 
-### Install auto-completion engine(ycmd)
+### Tasks
+Next, we'll tell VS Code how to compile our code and how to read warnings and
+errors from the build output. Copy the code below to
+chromium/src/.vscode/tasks.json. This will provide 5 tasks to do basic things.
+You might have to adjust the commands to your situation and needs.
 
 ```
-$ git clone https://github.com/Valloric/ycmd.git ~/.ycmd
-$ cd ~/.ycmd
-$ ./build.py --clang-completer
+{
+  "version": "0.1.0",
+  "_runner": "terminal",
+  "showOutput": "always",
+  "echoCommand": true,
+  "tasks": [
+  {
+    "taskName": "1-build_chrome_debug",
+    "command": "ninja -C out/Debug -j 2000 chrome",
+    "isShellCommand": true,
+    "isTestCommand": true,
+    "problemMatcher": {
+      "owner": "cpp",
+      "fileLocation": ["relative", "${workspaceRoot}"],
+      "pattern": {
+        "regexp": "^../../(.*):(\\d+):(\\d+):\\s+(warning|\\w*\\s?error):\\s+(.*)$",
+        "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5
+      }
+    }
+  },
+  {
+    "taskName": "2-build_chrome_release",
+    "command": "ninja -C out/Release -j 2000 chrome",
+    "isShellCommand": true,
+    "isBuildCommand": true,
+    "problemMatcher": {
+      "owner": "cpp",
+      "fileLocation": ["relative", "${workspaceRoot}"],
+      "pattern": {
+        "regexp": "^../../(.*):(\\d+):(\\d+):\\s+(warning|\\w*\\s?error):\\s+(.*)$",
+        "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5
+      }
+    }
+  },
+  {
+    "taskName": "3-build_all_debug",
+    "command": "ninja -C out/Debug -j 2000",
+    "isShellCommand": true,
+    "problemMatcher": {
+      "owner": "cpp",
+      "fileLocation": ["relative", "${workspaceRoot}"],
+      "pattern": {
+        "regexp": "^../../(.*):(\\d+):(\\d+):\\s+(warning|\\w*\\s?error):\\s+(.*)$",
+        "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5
+      }
+    }
+  },
+  {
+    "taskName": "4-build_all_release",
+    "command": "ninja -C out/Release -j 2000",
+    "isShellCommand": true,
+    "problemMatcher": {
+      "owner": "cpp",
+      "fileLocation": ["relative", "${workspaceRoot}"],
+      "pattern": {
+        "regexp": "^../../(.*):(\\d+):(\\d+):\\s+(warning|\\w*\\s?error):\\s+(.*)$",
+        "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5
+      }
+    }
+  },
+  {
+    "taskName": "5-build_test_debug",
+    "command": "ninja -C out/Debug -j 2000 unit_tests components_unittests browser_tests",
+    "isShellCommand": true,
+    "problemMatcher": {
+      "owner": "cpp",
+      "fileLocation": ["relative", "${workspaceRoot}"],
+      "pattern": {
+        "regexp": "^../../(.*):(\\d+):(\\d+):\\s+(warning|\\w*\\s?error):\\s+(.*)$",
+        "file": 1, "line": 2, "column": 3, "severity": 4, "message": 5
+      }
+    }
+  }]
+}
+```
+
+### Launch Commands
+Launch commands are the equivalent of `F5` in Visual Studio: They launch some
+program or a debugger. Optionally, they can run some task defined in
+`tasks.json`. Launch commands can be run from the debug view (`Ctrl+Shift+D`).
+Copy the code below to chromium/src/.vscode/launch.json and adjust them to
+your situation and needs.
+```
+{
+  "version": "0.2.0",
+  "configurations": [
+  {
+    "name": "Chrome Debug",
+    "type": "cppdbg",
+    "request": "launch",
+    "targetArchitecture": "x64",
+    "program": "${workspaceRoot}/out/Debug/chrome",
+    "args": [],  // Optional command line args
+    "preLaunchTask": "1-build_chrome_debug",
+    "stopAtEntry": false,
+    "cwd": "${workspaceRoot}",
+    "environment": [],
+    "externalConsole": true
+  },
+  {
+    "name": "Chrome Release",
+    "type": "cppdbg",
+    "request": "launch",
+    "targetArchitecture": "x64",
+    "program": "${workspaceRoot}/out/Release/chrome",
+    "args": [],  // Optional command line args
+    "preLaunchTask": "2-build_chrome_release",
+    "stopAtEntry": false,
+    "cwd": "${workspaceRoot}",
+    "environment": [],
+    "externalConsole": true
+  },
+  {
+    "name": "Custom Test Debug",
+    "type": "cppdbg",
+    "request": "launch",
+    "targetArchitecture": "x64",
+    "program": "${workspaceRoot}/out/Debug/unit_tests",
+    "args": ["--gtest_filter=*",
+              "--single_process",
+              "--ui-test-action-max-timeout=1000000",
+              "--test-launcher-timeout=1000000"],
+    "preLaunchTask": "5-build_test_debug",
+    "stopAtEntry": false,
+    "cwd": "${workspaceRoot}",
+    "environment": [],
+    "externalConsole": true
+  },
+  {
+    "name": "Attach Debug",
+    "type": "cppdbg",
+    "request": "launch",
+    "targetArchitecture": "x64",
+    "program": "${workspaceRoot}/out/Debug/chrome",
+    "args": ["--remote-debugging-port=2224"],
+    "stopAtEntry": false,
+    "cwd": "${workspaceRoot}",
+    "environment": [],
+    "externalConsole": false
+  }]
+}
 ```
 
-## Work flow
+### Key Bindings
+To edit key bindings, press `Ctrl+K, Ctrl+S`. You'll see the defaults on the
+left and your overrides on the right stored in the file `keybindings.json`. To
+change a key binding, copy the corresponding key binding to the right. It's
+fairly self-explanatory.
+
+You can bind any command to a key, even commands specified by extensions like
+`CodeSearchOpen`. For instance, to bind `CodeSearchOpen` to `F2` to , simply add
+`{ "key": "F2", "command": "cs.open" },`.
+Note that the command title `CodeSearchOpen` won't work. You have to get the
+actual command name from the [package.json
+file](https://github.com/chaopeng/vscode-chromium-codesearch/blob/master/package.json)
+of the extension.
 
-1. `ctrl+p` open file.
-2. `ctrl+o` goto symbol. `ctrl+l` goto line.
-3. <code>ctrl+`</code> toggle terminal.
+If you are used to other editors, you can also install your favorite keymap.
+For instance, to install eclipse keymaps, install the
+`vscode-eclipse-keybindings` extension. More keymaps can be found
+[in the marketplace](https://marketplace.visualstudio.com/search?target=vscode&category=Keymaps).
 
-## Tips
+Here are some key bindings that are likely to be useful for you:
 
-### On laptop
+```
+// Place your key bindings in this file to overwrite the defaults
+[
+// Run the task marked as "isTestCommand": true, see tasks.json.
+{ "key": "ctrl+shift+t",       "command": "workbench.action.tasks.test" },
+// Jump to the previous change in the built-in diff tool.
+{ "key": "ctrl+up",            "command": "workbench.action.compareEditor.previousChange" },
+// Jump to the next change in the built-in diff tool.
+{ "key": "ctrl+down",          "command": "workbench.action.compareEditor.nextChange" },
+// Jump to previous location in the editor (useful to get back from viewing a symbol definition).
+{ "key": "alt+left",           "command": "workbench.action.navigateBack" },
+// Jump to next location in the editor.
+{ "key": "alt+right",          "command": "workbench.action.navigateForward" },
+// Get a blame view of the current file. Requires the annotator extension.
+{ "key": "ctrl+alt+a",         "command": "annotator.annotate" },
+// Toggle header/source with the Toggle Header/Source extension (overrides the
+// key binding from the C/C++ extension as I found it to be slow).
+{ "key": "alt+o",              "command": "togglehs.toggleHS" },
+// Quickly run a task, see tasks.json. Since we named them 1-, 2- etc., it is
+// suffucient to press the corresponding number.
+{ "key": "ctrl+r",             "command": "workbench.action.tasks.runTask",
+                                  "when": "!inDebugMode" },
+// The following keybindings are useful on laptops with small keyboards such as
+// Chromebooks that don't provide all keys.
+{ "key": "shift+alt+down",     "command": "cursorColumnSelectDown",
+                                  "when": "editorTextFocus" },
+{ "key": "shift+alt+left",     "command": "cursorColumnSelectLeft",
+                                  "when": "editorTextFocus" },
+{ "key": "shift+alt+pagedown", "command": "cursorColumnSelectPageDown",
+                                  "when": "editorTextFocus" },
+{ "key": "shift+alt+pageup",   "command": "cursorColumnSelectPageUp",
+                                  "when": "editorTextFocus" },
+{ "key": "shift+alt+right",    "command": "cursorColumnSelectRight",
+                                  "when": "editorTextFocus" },
+{ "key": "shift+alt+up",       "command": "cursorColumnSelectUp",
+                                  "when": "editorTextFocus" },
+{ "key": "alt+down",           "command": "scrollPageDown",
+                                  "when": "editorTextFocus" },
+{ "key": "alt+up",             "command": "scrollPageUp",
+                                  "when": "editorTextFocus" },
+{ "key": "alt+backspace",      "command": "deleteRight",
+                                  "when": "editorTextFocus && !editorReadonly" },
+{ "key": "ctrl+right",         "command": "cursorEnd",
+                                  "when": "editorTextFocus" },
+{ "key": "ctrl+shift+right",   "command": "cursorEndSelect",
+                                  "when": "editorTextFocus" },
+{ "key": "ctrl+left",          "command": "cursorHome",
+                                  "when": "editorTextFocus" },
+{ "key": "ctrl+shift+left",    "command": "cursorHomeSelect",
+                                  "when": "editorTextFocus" },
+]
+```
 
-Because we use ycmd to enable auto completion. We can disable CPP autocomplete 
-and index to save battery. 
+### Tips
 
+#### The `out` folder
+Automatically generated code is put into a subfolder of out/, which means that
+these files are ignored by VS Code (see files.exclude above) and cannot be
+opened e.g. from quick-open (`Ctrl+P`). On Linux, you can create a symlink as a
+work-around:
 ```
-"C_Cpp.autocomplete": "Disabled",
-"C_Cpp.addWorkspaceRootToIncludePath": false
+  cd ~/chromium/src
+  mkdir _out
+  ln -s ../out/Debug/gen _out/gen
+```
+We picked _out since it is already in .gitignore, so it won't show up in git
+status.
+
+Note: As of version 1.9, VS Code does not support negated glob commands, but
+once it does, you can use
+```
+"!out/Debug/gen/**": true
 ```
+in files.exclude instead of the symlink.
+
+#### Using VS Code as git editor
+Add `[core] editor = "code --wait"` to your `~/.gitconfig` file in order to use
+VS Code as editor for git commit messages etc. Note that the editor starts up
+significantly slower than nano or vim. To use VS Code as merge tool, add
+`[merge] tool = code`.
+
+#### Task Names
+Note that we named the tasks `1-build_chrome_debug`, `2-build_chrome_release`
+etc. This allows you to quickly execute tasks by pressing their number:
+Press `Ctrl+P` and enter `task <n>`, where `<n>` is the number of the task. You
+can also create a keyboard shortcut for running a task. `File > Preferences >
+Keyboard Shortcuts` and add `{ "key": "ctrl+r", "command":
+"workbench.action.tasks.runTask", "when": "!inDebugMode" }`. Then it's
+sufficient to press `Ctrl+R` and enter `<n>`.
 
-### Enable Sublime-like minimap
+#### Working on Laptop
+Because autocomplete is provided by the You-Complete-Me extension, consider
+disabling C/C++ autocomplete and indexing to save battery. In addition, you
+might want to disable git status autorefresh as well.
 
 ```
-"editor.minimap.enabled": true,
-"editor.minimap.renderCharacters": false
+"git.autorefresh": false,
+"C_Cpp.autocomplete": "Disabled",
+"C_Cpp.addWorkspaceRootToIncludePath": false
 ```
 
 ### More
-
-https://github.com/Microsoft/vscode-tips-and-tricks/blob/master/README.md
\ No newline at end of file
+More tips and tricks can be found
+[here](https://github.com/Microsoft/vscode-tips-and-tricks/blob/master/README.md).
\ No newline at end of file
diff --git a/chromium/docs/windows_build_instructions.md b/chromium/docs/windows_build_instructions.md
index beadbba2271..f13f63d1c60 100644
--- a/chromium/docs/windows_build_instructions.md
+++ b/chromium/docs/windows_build_instructions.md
@@ -38,7 +38,8 @@ You must have the 14393 SDK installed or else you will hit compile errors such
 as undefined or redefined macros.
 
 Install the Windows SDK 10, and choose Debugging Tools For Windows when you
-install this in order to get windbg.
+install this in order to get windbg and cdb. The latter is required for the
+build to succeed as some tests use it for symbolizing crash dumps.
 
 ## Install `depot_tools`