BASELINE: Update Chromium to 88.0.4324.208

Change-Id: I3ae87d23e4eff4b4a469685658740a213600c667
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>

140 files changed, 3880 insertions, 594 deletions

diff --git a/chromium/docs/DIR_METADATA b/chromium/docs/DIR_METADATA
new file mode 100644
index 00000000000..57fb45a786d
--- /dev/null
+++ b/chromium/docs/DIR_METADATA
@@ -0,0 +1,14 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+# build@ isn't really the right component for this, but it'll
+# do until we create a component for documentation.
+monorail {
+  component: "Build"
+}
+team_email: "build@chromium.org"
\ No newline at end of file
diff --git a/chromium/docs/OWNERS b/chromium/docs/OWNERS
index f75e5460ad5..f59ec20aabf 100644
--- a/chromium/docs/OWNERS
+++ b/chromium/docs/OWNERS
@@ -1,7 +1 @@
-*
-
-# build@ isn't really the right component for this, but it'll
-# do until we create a component for documentation.
-
-# TEAM: build@chromium.org
-# COMPONENT: Build
+*
\ No newline at end of file
diff --git a/chromium/docs/README.md b/chromium/docs/README.md
index effb7d8b842..133d37e36cc 100644
--- a/chromium/docs/README.md
+++ b/chromium/docs/README.md
@@ -253,6 +253,11 @@ used when committed.
     on top of DirectX
 *   [Windows Split DLLs](windows_split_dll.md) - Splitting `chrome.dll` into
     multiple dlls to work around toolchain limitations on Windows.
+*   [Windows Native Window Occlusion Tracking](windows_native_window_occlusion_tracking.md)
+*   [Windows PWA Integration](windows_pwa_integration.md) - Integration with 
+    Progressive Web Apps on Windows
+*   [Windows Shortcut and Taskbar Handling](windows_shortcut_and_taskbar_handling.md)
+*   [Windows Virtual Desktop Integration](windows_virtual_desktop_handling.md)
 
 ### Misc Android-Specific Docs
 *   [Google Play Services in Chrome for Android](google_play_services.md)
diff --git a/chromium/docs/accessibility/DIR_METADATA b/chromium/docs/accessibility/DIR_METADATA
new file mode 100644
index 00000000000..35eb41cc533
--- /dev/null
+++ b/chromium/docs/accessibility/DIR_METADATA
@@ -0,0 +1,12 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Internals>Accessibility"
+}
+team_email: "chromium-accessibility@chromium.org"
\ No newline at end of file
diff --git a/chromium/docs/accessibility/OWNERS b/chromium/docs/accessibility/OWNERS
deleted file mode 100644
index df8b5d5260f..00000000000
--- a/chromium/docs/accessibility/OWNERS
+++ /dev/null
@@ -1,2 +0,0 @@
-# COMPONENT: Internals>Accessibility
-# TEAM: chromium-accessibility@chromium.org
diff --git a/chromium/docs/accessibility/chromevox_on_desktop_linux.md b/chromium/docs/accessibility/chromevox_on_desktop_linux.md
index 13710905569..07ef8344cbc 100644
--- a/chromium/docs/accessibility/chromevox_on_desktop_linux.md
+++ b/chromium/docs/accessibility/chromevox_on_desktop_linux.md
@@ -79,37 +79,26 @@ If you want speech, you just need to copy the speech synthesis data files to
 /usr/share like it would be on a Chrome OS device:
 
 ```
-gsutil ls gs://chromeos-localmirror/distfiles/googletts*
+gsutil ls gs://chromeos-localmirror/distfiles/espeak*
 ```
 
 Pick the latest version and
 
 ```
-gsutil cp gs://chromeos-localmirror/distfiles/googletts-13.1.tar.xz /usr/share/chromeos-assets/speech_synthesis/patts/
-tar xvf /usr/share/chromeos-assets/speech_synthesis/patts/googletts-13.1.tar.xz
-rm /usr/share/chromeos-assets/speech_synthesis/patts/googletts-13.1.tar.xz
+gsutil cp gs://chromeos-localmirror/distfiles/espeak-ng-20180801.tar.gz /usr/share/chromeos-assets/speech_synthesis/espeak-ng/
+tar xvf /usr/share/chromeos-assets/speech_synthesis/espeak-ng/espeak-ng-20180801.tar.gz
+rm /usr/share/chromeos-assets/speech_synthesis/espeak-ng/espeak-ng-20180801.tar.gz
 ```
 
 **Be sure to check permissions of /usr/share/chromeos-assets, some users report
 they need to chmod or chown too, it really depends on your system.**
 
+**Note that the default Google tts engine is now only available on an actual
+Chrome OS device. **
+
 After you do that, just run "chrome" as above (e.g. out/cros/chrome) and press
 Ctrl+Alt+Z, and you should hear it speak! If not, check the logs.
 
-### eSpeak
-
-To get [eSpeak](espeak.md) on Chrome OS on Desktop Linux, copy the eSpeak
-extension (chrome branch) to the same place:
-
-```
-cd ~
-git clone https://chromium.googlesource.com/chromiumos/third_party/espeak-ng
-cd espeak-ng
-git checkout chrome
-sudo mkdir -p /usr/share/chromeos-assets/speech_synthesis/espeak-ng
-sudo cp -r chrome-extension/* /usr/share/chromeos-assets/speech_synthesis/espeak-ng
-```
-
 ## Braille
 
 ChromeVox uses extension APIs to deliver braille to Brltty through libbrlapi
diff --git a/chromium/docs/accessibility/ia2_to_uia.md b/chromium/docs/accessibility/ia2_to_uia.md
new file mode 100644
index 00000000000..5dffbad8e29
--- /dev/null
+++ b/chromium/docs/accessibility/ia2_to_uia.md
@@ -0,0 +1,139 @@
+# Runtime two way IAccessible2 to UI Automation elements look up via unique id
+Assistive technologies (ATs) who currently rely on IAccessible2 (IA2) that want
+to take advantage of the UI Automation (UIA) features at runtime can convert an
+IA2 element to an UIA element via a unique id and directly access UIA's API.
+This enables ATs who want to gradually transition from IA2 to UIA to experiment
+with individual UIA elements at runtime without switching entirely to UIA.
+
+
+To look up an UIA element through a unique id, an AT can utilize
+`IUIAutomationItemContainerPattern::FindItemByProperty()` with the custom UIA
+unique id property and the element's unique id as parameters.
+To look up an IA2 element from an UIA element, an AT can simply
+utilize IUIAutomationLegacyIAccessiblePattern::GetIAccessible() and
+then query for IAccessible2 interface. The unique id is not needed to
+look up the IA2 element from UIA element.
+
+## Convert an IA2 element to UIA element via unique id
+An IA2 element can be converted to an UIA element at runtime via a unique id
+that is shared between the two APIs.
+
+*Note: For the purpose of brevity and clarity, the code snippets below do not
+include clean-up of COM references neither does it have error handling.*
+
+~~~c++
+  #include <uiautomation.h>
+  #include <uiautomationclient.h>
+
+  // Consider the following HTML:
+  // <html>
+  //  <button>button</button>
+  // </html>
+
+  // Register custom UIA property for retrieving the unique id of IA2 object.
+  // {cc7eeb32-4b62-4f4c-aff6-1c2e5752ad8e}
+  GUID UiaPropertyUniqueIdGuid = {
+      0xcc7eeb32,
+      0x4b62,
+      0x4f4c,
+      {0xaf, 0xf6, 0x1c, 0x2e, 0x57, 0x52, 0xad, 0x8e}};
+
+  // Create the registrar object and get the IUIAutomationRegistrar
+  // interface pointer.
+  IUIAutomationRegistrar* registrar;
+  CoCreateInstance(CLSID_CUIAutomationRegistrar, nullptr, CLSCTX_INPROC_SERVER,
+                   IID_PPV_ARGS(&registrar));
+
+  // Custom UIA property id used to retrieve the unique id between UIA/IA2.
+  PROPERTYID uia_unique_id_property_id;
+
+  // Register the custom UIA property that represents the unique id of an UIA
+  // element which also matches its corresponding IA2 element's unique id.
+  // Custom property registration only needs to be done once per process
+  // lifetime.
+  UIAutomationPropertyInfo unique_id_property_info = {
+      UiaPropertyUniqueIdGuid, L"UniqueId", UIAutomationType_String};
+  registrar->RegisterProperty(&unique_id_property_info,
+                              &uia_unique_id_property_id);
+
+  // Assume we are given the IAccessible2 element for button, and we want to
+  // retrieve its corresponding UIA element for the final result.
+  IAccessible2* button_ia2; /* Initialized */
+
+  // Retrieve button IA2 element's unique id, which will be used to look up the
+  // corresponding UIA element later.
+  LONG unique_id_long;
+  button_ia2->get_uniqueID(&unique_id_long);
+
+  // Assume we are given the Window Handle hwnd for the root.
+  UIA_HWND hwnd; /* Initialized */
+
+  // Instantiating an IUIAutomation object.
+  IUIAutomation* ui_automation;
+  CoCreateInstance(CLSID_CUIAutomation, NULL, CLSCTX_INPROC_SERVER,
+                   IID_PPV_ARGS(&ui_automation));
+
+  // Retrieve the root element from the window handle.
+  IUIAutomationElement* root_element;
+  ui_automation->ElementFromHandle(hwnd, &root_element);
+
+  // Retrieve the ItemContainerPattern of the root element.
+  IUIAutomationItemContainerPattern* item_container_pattern;
+  root_element->GetCurrentPatternAs(UIA_ItemContainerPatternId,
+                                    IID_PPV_ARGS(&item_container_pattern));
+
+  // We also need to convert the retrieved IA2 element unique id from long to
+  // VARIANT.VT_BSTR to be consumed by UIA. For demo purpose, I utilize
+  // std::string here as an intermediary step to convert to VARIANT.VT_BSTR.
+  std::string unique_id_str = std::to_string(unique_id_long);
+
+  VARIANT unique_id_variant;
+  unique_id_variant.vt = VT_BSTR;
+  unique_id_variant.bstrVal = SysAllocString(unique_id_str.c_str());
+
+  // Retrieving the corresponding UIAutomation element from the unique id of IA2
+  // object.
+  IUIAutomationElement* button_uia;
+  item_container_pattern->FindItemByProperty(nullptr, uia_unique_id_property_id,
+                                             unique_id_variant,
+                                             &button_uia /* final result */);
+~~~
+
+## Convert an UIA element to IA2 element.
+Converting an UIA element to an IA2 element is a lot more straightforward and
+does not require the shared unique id. Consider the same example above.
+~~~c++
+  #include <uiautomationclient.h>
+
+  // Assume we are given the UIAutomation element for button, and we want to
+  // retrieve its corresponding IAccessible2 element for the final result.
+  IUIAutomationElement* button_uia; /* Initialized */
+
+  // Retrieve the LegacyIAccessiblePattern of the button UIA element.
+  IUIAutomationLegacyIAccessiblePattern* legacy_iaccessible_pattern;
+  legacy_iaccessible_pattern->GetCurrentPatternAs(
+      UIA_LegacyIAccessiblePatternId,
+      IID_PPV_ARGS(&legacy_iaccessible_pattern));
+
+  // Retrieve the IAccessible element from button UIA element.
+  IAccessible* button_iaccessible;
+  legacy_iaccessible_pattern->GetIAccessible(&iaccessible);
+
+  // Use QueryService to retrieve button's IAccessible2 element from IAccessible
+  // element.
+  IServiceProvider* service_provider;
+  IAccessible2* button_ia2;
+  if (SUCCEEDED(button_iaccessible->QueryInterface(
+          IID_PPV_ARGS(&service_provider)))) {
+    service_provider->QueryService(
+        IID_PPV_ARGS(&button_ia2 /* final result */));
+  }
+~~~
+
+## Docs & References:
+[Custom UIA Property and Pattern registration in Chromium](https://chromium.googlesource.com/chromium/src/+/master/ui/accessibility/platform/uia_registrar_win.h)
+
+[UI Automation IItemContainerPattern. It is used to look up IAccessible2 element
+via a unique id](https://docs.microsoft.com/en-us/windows/win32/api/uiautomationclient/nn-uiautomationclient-iuiautomationitemcontainerpattern)
+
+[UI Automation Client](https://docs.microsoft.com/en-us/windows/win32/api/uiautomationclient/)
diff --git a/chromium/docs/accessibility/switch_access.md b/chromium/docs/accessibility/switch_access.md
new file mode 100644
index 00000000000..8b1fe092ca6
--- /dev/null
+++ b/chromium/docs/accessibility/switch_access.md
@@ -0,0 +1,397 @@
+# Switch Access (for developers)
+
+Switch Access is a Chrome OS feature to control the computer with 1 or 2
+**switches**, or button-like inputs. It is targeted at supporting users with
+motor or mobility impairments, for whom other methods of controlling the device
+are not feasible.
+
+
+## Using Switch Access
+
+Go to Chrome OS settings > Accessibility settings > "Manage accessibility
+features" > Enable "Switch Access". You can assign switches to actions and
+enable or disable automatic scanning on the Switch Access settings subpage.
+For most development purposes, buttons on either the built-in keyboard or an
+external keyboard can be used as switches, rather than needing a dedicated
+switch device.
+
+With this feature enabled, you can navigate to and interact with **actionable**
+elements (or **nodes**) onscreen. Because there are so many nodes onscreen at
+any given moment, they are organized into a nested system of **groups** based on
+proximity and other semantic information.
+
+
+### Navigation
+
+Switch Access supports two methods of navigation between nodes: manual scanning
+and automatic scanning (or **auto-scan**). Manual scanning means the user
+navigates from one element to the next by pressing one of their switches.
+Automatic scanning means that Switch Access moves from one element to the next
+after a set period of time (the **scanning speed**).
+
+The user can identify which element is currently focused because it is
+surrounded by a **focus ring**, which is two concentric rounded rectangles of
+contrasting colors (currently fixed at light blue and black) that surround the
+element. Sometimes, a second focus ring will appear onscreen, which has dashed
+rather than solid lines. This dashed focus ring provides a preview of which node
+will be focused, if the user selects the current node. It also provides a hint
+that the current node is a navigational node, and is not directly actionable.
+
+There are two types of navigational nodes: nodes that group other nodes
+together, and the **back button**. The back button allows a user to exit the
+current group, and move outwards towards the top-level node.
+
+
+### Selection
+
+All users have one switch dedicated to selecting elements. For some users, this
+is the only input they have (they rely on auto-scan to advance to the next
+node). So a user needs to be able to perform any action based on some series of
+select actions. To support this, when multiple actions are available for a
+single actionable node, we open the **action menu**, which displays the
+available actions for the given node. The user can then navigate to the action
+they wish to perform, and when they select an action the action is performed,
+and in most cases the menu is closed.
+
+Sometimes there is only one action available for a given node. In this case, the
+action menu does not open. Instead, the available action is performed
+automatically when the user presses *select*.
+
+
+## Reporting bugs
+
+Use bugs.chromium.org, filing bugs under the component
+[OS>Accessibility>SwitchAccess](https://bugs.chromium.org/p/chromium/issues/list?sort=-opened&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&q=component%3AOS%3EAccessibility%3ESwitchAccess%20&can=2).
+
+## Developing
+
+### Code location
+
+Switch Access code lives mainly in four places:
+
+- A component extension to do the bulk of the logic and processing,
+`chrome/browser/resources/chromeos/accessibility/switch_access/`
+
+- In the `AccessibilityEventRewriter`,
+`ash/events/accessibility_event_rewriter.h`
+
+- The Switch Access menu and back button code, in `ash/system/accessibility/`
+
+- The Switch Access settings page,
+`chrome/browser/resources/settings/chromeos/os_a11y_page/switch_access_subpage.*`
+
+
+### Tests
+
+Tests are in `unit_tests`, `ash_unittests`, and `browser_tests`:
+
+```
+out/Release/unit_tests --gtest_filter="*SwitchAccess*"
+out/Release/ash_unittests --gtest_filter="*SwitchAccess*"
+out/Release/browser_tests --gtest_filter="*SwitchAccess*"
+```
+
+
+### Debugging
+
+Developers can add log lines to any of the C++ files and see output in the
+console. To debug the Switch Access extension, the easiest way is from an
+external browser. Start Chrome OS on Linux with this command-line flag:
+
+```
+out/Release/chrome --remote-debugging-port=9222
+```
+
+Now open http://localhost:9222 in a separate browser, and debug the Switch
+Access extension background page from there.
+
+
+## How it works
+
+Like [Chromevox](chromevox.md) and [Select to Speak](select_to_speak.md),
+Switch Access is implemented mainly as a component Chrome extension which
+is always loaded and running in the background when enabled, and unloaded
+when disabled. Unlike Chromevox and Select to Speak, the settings for
+Switch Access are not located within the component extension. Instead,
+they are found with the other settings in the Settings app.
+
+There are a handful of tasks which, for various reasons, are handled in
+C++ code. These are:
+
+- Event forwarding. In order to capture the events before other system
+functions, we use an Event Rewriter (shared with Chromevox).
+
+- Rendering the menu. To allow the menu UI to match other system UI, the process
+of creating the menu UI is done in C++.
+
+The Switch Access extension does the following, at a high level:
+
+1. Listens for SwitchAccessCommands, which are the user-initiated commands like
+"select" or "next" that the user performs by pressing their switch.
+
+2. Maps those commands to the appropriate behavior:
+
+    - If it is a navigation command, the focused node is changed and focus rings
+    are updated.
+
+    - If it is a select command, the available actions are determined.
+
+If there is only one, it is performed (Note that for navigational nodes, this
+means entering or exiting a group). If more than one action is available, the
+menu is opened and focus jumps into the menu.
+
+3. Listens for focus events, and moves Switch Access focus to follow system
+focus.
+
+4. Listens for location changes and other tree changes that affect the current
+node or its parent or siblings, and update the focused node and focus rings when
+necessary.
+
+
+## Switch Access extension structure
+
+### Managers
+
+Switch Access divides tasks by function, each being handled by a manager class.
+This section details what those managers are, their guiding principle, and what
+tasks they are responsible for.
+
+#### ActionManager
+
+The ActionManager is responsible for what happens after a user presses their
+*Select* switch. This includes determining what actions are available,
+performing actions, and specifying what actions to display in and where to show
+the action menu and sub-menus when needed.
+
+The specifics of opening and closing the menu are not handled here, but are
+encapsulated in the MenuManager. However, all calls to open or close the menu
+should be made on the ActionManager, rather than the MenuManager directly,
+because the ActionManager maintains state about sub-menus and similar, which
+needs to remain in sync with the menu displayed.
+
+#### AutoScanManager
+
+The AutoScanManager handles the process of automatically scanning from one
+element to the next. If the user has enabled auto-scan, it sets an interval
+to call `NavigationManager.moveForward()` periodically. It also resets the
+interval each time a command is received, or a focus event causes the focused
+node to change.
+
+#### FocusRingManager
+
+The FocusRingManager determines what focus rings should be drawn and where to
+show them, and calls the `accessibilityPrivate` API.
+
+#### MenuManager
+
+The MenuManager handles the details of displaying the action menu, given a
+list of actions and a location. It also waits for the menu to load, and jumps
+Switch Access focus to the menu when it is ready.
+
+Calls to open or close a menu should be handled by the ActionManager, rather
+than by the MenuManager directly, to keep state in sync.
+
+#### NavigationManager
+
+The NavigationManager handles tracking and changing the current Switch Access
+focus. This includes handling moving forward or backward from a user command,
+moving forward from auto-scan, jumping to a UI element when opened (such as the
+keyboard or action menu), and following system focus. It also handles entering
+and exiting groups when navigational nodes are selected.
+
+The NavigationManager also has a method `getTreeForDebugging()` which can be
+used to print either the current group or the entire tree to the console, to
+help with debugging.
+
+#### PreferenceManager
+
+The PreferenceManager handles accessing user preferences, and updating
+Switch Access' behavior accordingly. It also verifies whether the user has
+a configuration that allows for full navigation.
+
+#### TextNavigationManager
+
+The TextNavigationManager handles tasks surrounding navigating through text.
+Currently only text within editable text fields is supported, and only behind
+the flag `enable-experimental-accessibility-switch-access-text`.
+
+
+### Nodes
+
+In addition to dividing the tasks by function, Switch Access delegates many
+tasks to the nodes themselves. This allows specific behaviors to be changed
+by changing what nodes are created based on the circumstances, and keeps the
+ActionManager and NavigationManager from getting bloated with special cases,
+and all the permutations of those special cases.
+
+All of the nodes used by Switch Access have some relation to an **automation
+node**, the underlying tree structure shared by all accessibility component
+extensions. Most have a one-to-one association (one automation node for each
+Switch Access node), but sometimes there are multiple Switch Access nodes for
+the same automation node (such as when breaking a long list into smaller
+groups).
+
+#### SAChildNode and SARootNode
+
+These are the two base types. They define the functions available on nodes
+when they are functioning as either a selectable node, or the current group.
+
+SAChildNode is an abstract class, but SARootNode can be used directly to
+represent a group that does not have an underlying automation node.
+
+#### BasicNode and BasicRootNode
+
+These types implement a default behavior for nodes that have a one-to-one
+association with an automation node. Information is derived directly from
+the automation node to implement the interface provided by SAChildNode and
+SARootNode.
+
+#### BackButtonNode
+
+The BackButtonNode is special because it is part of Switch Access' UI, and
+it is shown for each group. Therefore, it automatically finds the automation
+node corresponding to the back button by searching the tree, and instead
+takes the SARootNode for its group in its constructor. It uses this to
+determine where to show the back button, and what to do if it is selected.
+
+#### ComboBoxNode
+
+ComboBoxNode extends BasicNode, and only overrides a small number of functions
+where combo boxes have special behavior. Specifically, combo boxes require some
+special logic around moving focus into the dropdown when it opens.
+
+#### DesktopNode
+
+Represents the largest group possible, the entire computer desktop. Behaves
+mostly like a SARootNode, but does not have a back button.
+
+#### EditableTextNode
+
+Editable text nodes have a very different set of actions. Currently supported
+are opening the keyboard and using dictation, but many more actions (such as
+selection and copy/paste) are available with the flag
+`enable-experimental-accessibility-switch-access-text`.
+
+#### GroupNode
+
+A GroupNode represents a subset of the children of a single automation node,
+used to break a single node with many children into intermediate nodes for
+easier navigation.
+
+Currently the only place this is used is to break the keyboard into rows, but
+ideally this should be done for any group with more than some number of
+children.
+
+#### KeyboardNode and KeyboardRootNode
+
+A KeyboardNode represents a button within the virtual keyboard. Because the
+keys do not support actions through the automation API, the KeyboardNode
+simulate a mouse press at the center of the button.
+
+The KeyboardRootNode represents the keyboard as a whole. It handles finding
+the buttons from the keyboard and grouping them into rows, as well as
+finding the automation node representing the virtual keyboard and monitoring
+the visibility of the keyboard, so if the user opens/closes the keyboard
+other than via Switch Access we still detect it.
+
+#### ModalDialogRootNode
+
+Currently used when a menu is opened, it behaves exactly like a BasicRootNode
+except that when the user exits, it fires an ESC key event to close the menu
+or modal dialog.
+
+#### SliderNode
+
+Adds support for custom sliders by sending left/right arrow key events to
+decrement/increment.
+
+#### TabNode and ActionableTabNode
+
+These two classes are primarily to allow the close button to both be
+accessible via Switch Access while clearly displaying visually how to select
+the tab. This is done by having TabNode be a group (when it contains a button),
+and create an ActionableTabNode as a child whose location is just the portion of
+the tab that doesn't overlap with the close button.
+
+#### WindowRootNode
+
+The WindowRootNode focuses a window when it is entered. Otherwise it behaves
+exactly like a BasicRootNode.
+
+
+### Other
+
+There are some other classes that support Switch Access without being a manager
+or node type directly.
+
+#### background.js
+
+This file is the first one run. Its primary job is to create an instance of
+SwitchAccess, although it als overifies that there is not more than one instance
+of Switch Access running simultaneously (this would normally happen on the sign
+in page).
+
+#### Commands
+
+Commands translates a SwitchAccessCommand from the user into a call to the
+appropriate function.
+
+#### History
+
+History helps store and recover state about what the current node and group are.
+When a group is exited, the history provides the previous position to return to
+(after verifying that it is still valid). It also builds a new history when
+focus moves, capturing how the user would have gotten to that same node.
+
+#### Metrics
+
+A utility for recording metrics.
+
+#### SACache
+
+Implements a dynamic programming strategy for when walking the automation tree to
+find interesting nodes. A cache is created for a single query, and should not be
+used in nonconsecutive function calls, as the underlying data can change and the
+SACache does not account for this.
+
+#### SAConstants
+
+This file contains most or all of the constants used throughout Switch Access.
+
+#### SwitchAccess
+
+Primarily, this class creates the managers that need to be explicitly initialized,
+as well as the Commands object. It also handles creating errors (so we can track
+metrics on how often different errors happen), and has a function to find a node
+matching a predicate (or wait for it to be created).
+
+#### SwitchAccessPredicate
+
+Has a variety of predicates determining things about automation nodes, all
+generally specific to Switch Access. Many of these functions utilize SACache.
+It also creates the restrictions that can be passed to AutomationTreeWalker to
+find the appropriate children for a given group node.
+
+
+## For Googlers
+
+For more, Googlers could check out the Switch Access feature design docs for
+more details on design as well as UMA.
+
+- Overall product design, [go/cros-switch](go/cros-switch)
+
+- The navigation strategy, [go/cros-switch-navigation](go/cros-switch-navigation)
+
+- The action menu, [go/cros-switch-menu](go/cros-switch-menu)
+
+- The "preview" dashed focus ring, [go/cros-switch-dashed-focus](go/cros-switch-dashed-focus)
+
+- The UX description slideshow, [go/cros-switch-access-ux](go/cros-switch-access-ux)
+
+- The UI specification, [go/cros-switch-spec](go/cros-switch-spec)
+
+- Testing, [go/cros-switch-testing](go/cros-switch-testing)
+
+- Improved Text Input (still experimental), [go/cros-switch-text-input](go/cros-switch-text-input)
+
+- Point Scanning (still under development), [go/cros-switch-point-scanning](go/cros-switch-point-scanning)
diff --git a/chromium/docs/android_accessing_cpp_enums_in_java.md b/chromium/docs/android_accessing_cpp_enums_in_java.md
index 8743ca6811d..3879fa9c058 100644
--- a/chromium/docs/android_accessing_cpp_enums_in_java.md
+++ b/chromium/docs/android_accessing_cpp_enums_in_java.md
@@ -146,6 +146,10 @@ class
     }
     ```
 
+## See also
+* [Accessing C++ Switches In Java](android_accessing_cpp_switches_in_java.md)
+* [Accessing C++ Features In Java](android_accessing_cpp_features_in_java.md)
+
 ## Code
 * [Generator
 code](https://cs.chromium.org/chromium/src/build/android/gyp/java_cpp_enum.py?dr=C&sq=package:chromium)
diff --git a/chromium/docs/android_accessing_cpp_features_in_java.md b/chromium/docs/android_accessing_cpp_features_in_java.md
new file mode 100644
index 00000000000..a606196ba8c
--- /dev/null
+++ b/chromium/docs/android_accessing_cpp_features_in_java.md
@@ -0,0 +1,172 @@
+# Accessing C++ Features In Java
+
+[TOC]
+
+## Introduction
+
+Accessing C++ `base::Features` in Java is implemented via a Python script which
+analyzes the `*_features.cc` file and generates the corresponding Java class,
+based on a template file. The template file must be specified in the GN target.
+This outputs Java String constants which represent the name of the
+`base::Feature`.
+
+## Usage
+
+1. Create a template file (ex. `FooFeatures.java.tmpl`). Change "Copyright
+   2020" to be whatever the year is at the time of writing (as you would for any
+   other file).
+   ```java
+    // Copyright 2020 The Chromium Authors. All rights reserved.
+    // Use of this source code is governed by a BSD-style license that can be
+    // found in the LICENSE file.
+
+    package org.chromium.foo;
+
+    // Be sure to escape any curly braces in your template by doubling as
+    // follows.
+    /**
+     * Contains features that are specific to the foo project.
+     */
+    public final class FooFeatures {{
+
+    {NATIVE_FEATURES}
+
+        // Prevents instantiation.
+        private FooFeatures() {{}}
+    }}
+   ```
+
+2. Add a new build target and add it to the `srcjar_deps` of an
+   `android_library` target:
+
+    ```gn
+    if (is_android) {
+      import("//build/config/android/rules.gni")
+    }
+
+    if (is_android) {
+      java_cpp_features("java_features_srcjar") {
+        # External code should depend on ":foo_java" instead.
+        visibility = [ ":*" ]
+        sources = [
+          "//base/android/foo_features.cc",
+        ]
+        template = "//base/android/java_templates/FooFeatures.java.tmpl"
+      }
+
+      # If there's already an android_library target, you can add
+      # java_features_srcjar to that target's srcjar_deps. Otherwise, the best
+      # practice is to create a new android_library just for this target.
+      android_library("foo_java") {
+        srcjar_deps = [ ":java_features_srcjar" ]
+      }
+    }
+    ```
+
+3. The generated file `out/Default/gen/.../org/chromium/foo/FooFeatures.java`
+   would contain:
+
+    ```java
+    // Copyright $YEAR The Chromium Authors. All rights reserved.
+    // Use of this source code is governed by a BSD-style license that can be
+    // found in the LICENSE file.
+
+    package org.chromium.foo;
+
+    // Be sure to escape any curly braces in your template by doubling as
+    // follows.
+    /**
+     * Contains features that are specific to the foo project.
+     */
+    public final class FooFeatures {
+
+        // This following string constants were inserted by
+        //     java_cpp_features.py
+        // From
+        //     ../../base/android/foo_features.cc
+        // Into
+        //     ../../base/android/java_templates/FooFeatures.java.tmpl
+
+        // Documentation for the C++ Feature is copied here.
+        public static final String SOME_FEATURE = "SomeFeature";
+
+        // ...snip...
+
+        // Prevents instantiation.
+        private FooFeatures() {}
+    }
+    ```
+
+### Troubleshooting
+
+The script only supports limited syntaxes for declaring C++ base::Features. You
+may see an error like the following during compilation:
+
+```
+...
+org/chromium/foo/FooFeatures.java:41: error: duplicate declaration of field: MY_FEATURE
+    public static final String MY_FEATURE = "MyFeature";
+```
+
+This can happen if you've re-declared a feature for mutually-exclsuive build
+configs (ex. the feature is enabled-by-default for one config, but
+disabled-by-default for another). Example:
+
+```c++
+#if defined(...)
+const base::Feature kMyFeature{
+    "MyFeature", base::FEATURE_ENABLED_BY_DEFAULT};
+#else
+const base::Feature kMyFeature{
+    "MyFeature", base::FEATURE_DISABLED_BY_DEFAULT};
+#endif
+```
+
+The `java_cpp_features` rule doesn't know how to evaluate C++ preprocessor
+directives, so it generates two identical Java fields (which is what the
+compilation error is complaining about). Fortunately, the workaround is fairly
+simple. Rewrite the definition to only use directives around the enabled state:
+
+```c++
+const base::Feature kMyFeature{
+    "MyFeature",
+#if defined(...)
+    base::FEATURE_ENABLED_BY_DEFAULT
+#else
+    base::FEATURE_DISABLED_BY_DEFAULT
+#endif
+};
+
+```
+
+## Checking if a Feature is enabled
+
+The standard pattern is to create a `FooFeatureList.java` class with an
+`isEnabled()` method (ex.
+[`ContentFeatureList`](/content/public/android/java/src/org/chromium/content_public/browser/ContentFeatureList.java)).
+This should call into C++ (ex.
+[`content_feature_list`](/content/browser/android/content_feature_list.cc)),
+where a subset of features are exposed via the `kFeaturesExposedToJava` array.
+You can either add your `base::Feature` to an existing `feature_list` or create
+a new `FeatureList` class if no existing one is suitable. Then you can check the
+enabled state like so:
+
+```java
+// It's OK if ContentFeatureList checks FooFeatures.*, so long as
+// content_feature_list.cc exposes `kMyFeature`.
+if (ContentFeatureList.isEnabled(FooFeatures.MY_FEATURE)) {
+    // ...
+}
+```
+
+At the moment, `base::Features` must be explicitly exposed to Java this way, in
+whichever layer needs to access their state. See https://crbug.com/1060097.
+
+## See also
+* [Accessing C++ Enums In Java](android_accessing_cpp_enums_in_java.md)
+* [Accessing C++ Switches In Java](android_accessing_cpp_switches_in_java.md)
+
+## Code
+* [Generator code](/build/android/gyp/java_cpp_features.py) and
+  [Tests](/build/android/gyp/java_cpp_features_tests.py)
+* [GN template](/build/config/android/rules.gni)
diff --git a/chromium/docs/android_accessing_cpp_switches_in_java.md b/chromium/docs/android_accessing_cpp_switches_in_java.md
index 8333f7e5a18..a15904aba20 100644
--- a/chromium/docs/android_accessing_cpp_switches_in_java.md
+++ b/chromium/docs/android_accessing_cpp_switches_in_java.md
@@ -10,9 +10,11 @@ template file. The template file must be specified in the GN target.
 
 ## Usage
 
-1. Create a template file (ex. `FooSwitches.java.tmpl`)
+1. Create a template file (ex. `FooSwitches.java.tmpl`). Change "Copyright
+   2020" to be whatever the year is at the time of writing (as you would for any
+   other file).
    ```java
-    // Copyright $YEAR The Chromium Authors. All rights reserved.
+    // Copyright 2020 The Chromium Authors. All rights reserved.
     // Use of this source code is governed by a BSD-style license that can be
     // found in the LICENSE file.
 
@@ -93,6 +95,10 @@ template file. The template file must be specified in the GN target.
     }
     ```
 
+## See also
+* [Accessing C++ Enums In Java](android_accessing_cpp_enums_in_java.md)
+* [Accessing C++ Features In Java](android_accessing_cpp_features_in_java.md)
+
 ## Code
 * [Generator
 code](https://cs.chromium.org/chromium/src/build/android/gyp/java_cpp_strings.py?dr=C&sq=package:chromium)
diff --git a/chromium/docs/android_emulator.md b/chromium/docs/android_emulator.md
index a2e9e10c664..d858297918d 100644
--- a/chromium/docs/android_emulator.md
+++ b/chromium/docs/android_emulator.md
@@ -20,12 +20,36 @@ currently stored in `//tools/android/avd/proto`.
 
 | File | Builder |
 |:----:|:-------:|
+| `tools/android/avd/proto/generic_android23.textpb` | [android-marshmallow-x86-rel][android-marshmallow-x86-rel] |
 | `tools/android/avd/proto/generic_android28.textpb` | [android-pie-x86-rel][android-pie-x86-rel] |
+| `tools/android/avd/proto/generic_playstore_android28.textpb` | [android-pie-x86-rel][android-pie-x86-rel] |
 
 You can use these configuration files to run the same emulator images locally.
 
+[android-marshmallow-x86-rel]: https://ci.chromium.org/p/chromium/builders/ci/android-marshmallow-x86-rel
 [android-pie-x86-rel]: https://ci.chromium.org/p/chromium/builders/ci/android-pie-x86-rel
 
+#### Prerequisite
+
+ * Make sure KVM (Kernel-based Virtual Machine) is enabled.
+   See this
+   [link](https://developer.android.com/studio/run/emulator-acceleration#vm-linux)
+   from android studio for more details and instructions.
+
+ * You need to have the permissions to use KVM.
+   Use the following command to see if you are in group `kvm`:
+
+   ```
+     $ grep kvm /etc/group
+   ```
+
+   If your username is not shown in the group, add yourself to the group:
+
+   ```
+     $ sudo adduser $USER kvm
+     $ newgrp kvm
+   ```
+
 #### Running via the test runner
 
 The android test runner can run emulator instances on its own. In doing so, it
@@ -70,33 +94,14 @@ down. This is how builders run the emulator.
 The test runner will set up and tear down the emulator on each invocation.
 To manage emulator lifetime independently, use `tools/android/avd/avd.py`.
 
-##### Prerequisite
-
- * Make sure KVM (Kernel-based Virtual Machine) is enabled.
-   See this
-   [link](https://developer.android.com/studio/run/emulator-acceleration#vm-linux)
-   from android studio for more details and instructions.
-
- * You need to have the permissions to use KVM.
-   Use the following command to see if you are in group `kvm`:
-
-   ```
-     $ grep kvm /etc/group
-   ```
-
-   If your username is not shown in the group, add yourself to the group:
-
-   ```
-     $ sudo adduser $USER kvm
-     $ newgrp kvm
-   ```
-
- * Install the emulator configuration you intend to use.
-
-    ```
-      $ tools/android/avd/avd.py install \
-          --avd-config tools/android/avd/proto/generic_android28.textpb
-    ```
+> Note: Before calling `avd.py start`, use `avd.py install` to install the
+> emulator configuration you intend to use. Otherwise the emulator won't start
+> correctly.
+>
+> ```
+>   $ tools/android/avd/avd.py install \
+>       --avd-config tools/android/avd/proto/generic_android28.textpb
+> ```
 
 ##### Options
 
@@ -134,6 +139,18 @@ To manage emulator lifetime independently, use `tools/android/avd/avd.py`.
           --no-read-only
     ```
 
+ * `--debug-tags`
+
+    `avd.py` disables the emulator log by default. When this option is used,
+    emulator log will be enabled. It is useful when the emulator cannot be
+    launched correctly. See `emulator -help-debug-tags` for a full list of tags.
+
+    ```
+      $ tools/android/avd/avd.py start \
+          --avd-config tools/android/avd/proto/generic_android28.textpb \
+          --debug-tags init,snapshot
+    ```
+
 ### Using Your Own Emulator Image
 
 By far the easiest way to set up emulator images is to use Android Studio.
diff --git a/chromium/docs/autofill/DIR_METADATA b/chromium/docs/autofill/DIR_METADATA
new file mode 100644
index 00000000000..326295f0326
--- /dev/null
+++ b/chromium/docs/autofill/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "UI>Browser>Autofill"
+}
\ No newline at end of file
diff --git a/chromium/docs/autofill/OWNERS b/chromium/docs/autofill/OWNERS
deleted file mode 100644
index 29ec06f7f24..00000000000
--- a/chromium/docs/autofill/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: UI>Browser>Autofill
diff --git a/chromium/docs/callback.md b/chromium/docs/callback.md
index f8c6361d7fb..412242c3ad5 100644
--- a/chromium/docs/callback.md
+++ b/chromium/docs/callback.md
@@ -84,6 +84,154 @@ moved-from `base::{Once,Repeating}Callback` becomes null, as if its `Reset()`
 method had been called. Afterward, its `is_null()` method will return true and
 its `operator bool()` will return false.
 
+### Chaining callbacks
+
+When you have 2 callbacks that you wish to run in sequence, they can be joined
+together into a single callback through the use of `Then()`.
+
+Calling `Then()` on a `base::OnceCallback` joins a second callback that will be
+run together with, but after, the first callback. The return value from the
+first callback is passed along to the second, and the return value from the
+second callback is returned at the end. More concretely, calling `a.Then(b)`
+produces a new `base::OnceCallback` that will run `b(a());`, returning the
+result from `b`.
+
+This example uses `Then()` to join 2 `base::OnceCallback`s together:
+```cpp
+int Floor(float f) { return std::floor(f); }
+std::string IntToString(int i) { return base::NumberToString(i); }
+
+base::OnceCallback<int(float)> first = base::BindOnce(&Floor);
+base::OnceCallback<std::string(int)> second = base::BindOnce(&IntToString);
+
+// This will run |first|, run and pass the result to |second|, then return
+// the result from |second|.
+std::string r = std::move(first).Then(std::move(second)).Run(3.5f);
+// |r| will be "3". |first| and |second| are now both null, as they were
+// consumed to perform the join operation.
+```
+
+Similarly, `Then()` also works with `base::RepeatingCallback`; however, the
+joined callback must also be a `base::RepeatingCallback` to ensure the resulting
+callback can be invoked multiple times.
+
+This example uses `Then()` to join 2 `base::RepeatingCallback`s together:
+```cpp
+int Floor(float f) { return std::floor(f); }
+std::string IntToString(int i) { return base::NumberToString(i); }
+
+base::RepeatingCallback<int(float)> first = base::BindRepeating(&Floor);
+base::RepeatingCallback<std::string(int)> second = base::BindRepeating(&IntToString);
+
+// This creates a RepeatingCallback that will run |first|, run and pass the
+// result to |second|, then return the result from |second|.
+base::RepeatingCallback<std::string(float)> joined =
+    std::move(first).Then(std::move(second));
+// |first| and |second| are now both null, as they were consumed to perform
+// the join operation.
+
+// This runs the functor that was originally bound to |first|, then |second|.
+std::string r = joined.Run(3.5);
+// |r| will be "3".
+
+// It's valid to call it multiple times since all callbacks involved are
+// base::RepeatingCallbacks.
+r = joined.Run(2.5);
+// |r| is set to "2".
+```
+
+In the above example, casting the `base::RepeatingCallback` to an r-value with
+`std::move()` causes `Then()` to destroy the original callback, in the same way
+that occurs for joining `base::OnceCallback`s. However since a
+`base::RepeatingCallback` can be run multiple times, it can be joined
+non-destructively as well.
+```cpp
+int Floor(float f) { return std::floor(f); }
+std::string IntToString(int i) { return base::NumberToString(i); }
+
+base::RepeatingCallback<int(float)> first = base::BindRepeating(&Floor);
+base::RepeatingCallback<std::string(int)> second = base::BindRepeating(&IntToString);
+
+// This creates a RepeatingCallback that will run |first|, run and pass the
+// result to |second|, then return the result from |second|.
+std::string r = first.Then(second).Run(3.5f);
+// |r| will be 3, and |first| and |second| are still valid to use.
+
+// Runs Floor().
+int i = first.Run(5.5);
+// Runs IntToString().
+std::string s = second.Run(9);
+```
+
+If the second callback does not want to receive a value from the first callback,
+you may use `base::IgnoreResult` to drop the return value in between running the
+two.
+
+```cpp
+// Returns an integer.
+base::RepeatingCallback<int()> first = base::BindRepeating([](){ return 5; });
+// Does not want to receive an integer.
+base::RepeatingClosure second = base::BindRepeating([](){});
+
+// This will not compile, because |second| can not receive the return value from
+// |first|.
+//   first.Then(second).Run();
+
+// We can drop the result from |first| before running second.
+base::BindRepeating(base::IgnoreResult(first)).Then(second).Run();
+// This will effectively create a callback that when Run() will call
+// `first(); second();` instead of `second(first());`.
+```
+
+Note that the return value from |first| will be lost in the above example, and
+would be destroyed before |second| is run. If you want the return value from
+|first| to be preserved and ultimately returned after running both |first| and
+|second|, then you would need a primitive such as the  `base::PassThrough<T>()`
+helper in the [base::PassThrough CL](https://chromium-review.googlesource.com/c/chromium/src/+/2493243).
+If this would be helpful for you, please let danakj@chromium.org know or ping
+the CL.
+
+### Chaining callbacks across different task runners
+
+```cpp
+// The task runner for a different thread.
+scoped_refptr<base::SequencedTaskRunner> other_task_runner = ...;
+
+// A function to compute some interesting result, except it can only be run
+// safely from `other_task_runner` and not the current thread.
+int ComputeResult();
+
+base::OnceCallback<int()> compute_result_cb = base::BindOnce(&ComputeResult);
+
+// Task runner for the current thread.
+scoped_refptr<base::SequencedTaskRunner> current_task_runner =
+    base::SequencedTaskRunnerHandle::Get();
+
+// A function to accept the result, except it can only be run safely from the
+// current thread.
+void ProvideResult(int result);
+
+base::OnceCallback<void(int)> provide_result_cb =
+    base::BindOnce(&ProvideResult);
+```
+
+Using `Then()` to join `compute_result_cb` and `provide_result_cb` directly
+would be inappropriate. `ComputeResult()` and `ProvideResult()` would run on the
+same thread which isn't safe. However, `base::BindPostTask()` can be used to
+ensure `provide_result_cb` will run on `current_task_runner`.
+
+```cpp
+// The following two statements post a task to `other_task_runner` to run
+// `task`. This will invoke ComputeResult() on a different thread to get the
+// result value then post a task back to `current_task_runner` to invoke
+// ProvideResult() with the result.
+OnceClosure task =
+    std::move(compute_result_cb)
+        .Then(base::BindPostTask(current_task_runner,
+                                 std::move(provide_result_cb)));
+other_task_runner->PostTask(FROM_HERE, std::move(task));
+```
+
 ## Quick reference for basic stuff
 
 ### Binding A Bare Function
@@ -125,7 +273,7 @@ When writing tests, it is often useful to capture arguments that need to be
 modified in a callback.
 
 ``` cpp
-#include "base/test/bind_test_util.h"
+#include "base/test/bind.h"
 
 int i = 2;
 base::Callback<void()> lambda_cb = base::BindLambdaForTesting([&]() { i++; });
@@ -418,8 +566,16 @@ doesn't expect a return value.
 
 ```cpp
 int DoSomething(int arg) { cout << arg << endl; }
-base::Callback<void(int)> cb =
-    base::Bind(IgnoreResult(&DoSomething));
+base::RepeatingCallback<void(int)> cb =
+    base::BindRepeating(IgnoreResult(&DoSomething));
+```
+
+Similarly, you may want to use an existing callback that returns a value in a
+place that expects a void return type.
+
+```cpp
+base::RepeatingCallback<int()> cb = base::BindRepeating([](){ return 5; });
+base::RepeatingClosure void_cb = base::BindRepeating(base::IgnoreResult(cb));
 ```
 
 ## Quick reference for binding parameters to Bind()
@@ -579,8 +735,8 @@ references. (Binding to non-const references is forbidden, see bind.h.)
 
 To change this behavior, we introduce a set of argument wrappers (e.g.,
 `base::Unretained()`).  These are simple container templates that are passed by
-value, and wrap a pointer to argument.  See the file-level comment in
-base/bind_helpers.h for more info.
+value, and wrap a pointer to argument.  Each helper has a comment describing it
+in base/bind.h.
 
 These types are passed to the `Unwrap()` functions to modify the behavior of
 `base::Bind()`.  The `Unwrap()` functions change behavior by doing partial
diff --git a/chromium/docs/clang_tidy.md b/chromium/docs/clang_tidy.md
index 834051989de..2cf7aabb522 100644
--- a/chromium/docs/clang_tidy.md
+++ b/chromium/docs/clang_tidy.md
@@ -75,7 +75,7 @@ clang-tidy across all of Chromium is a single command:
 
 ```
 $ cd ${chromium}/src
-$ ${chromium_build}/scripts/slave/recipe_modules/tricium_clang_tidy/resources/tricium_clang_tidy.py \
+$ ${chromium_build}/recipes/recipe_modules/tricium_clang_tidy/resources/tricium_clang_tidy.py \
     --base_path $PWD \
     --out_dir out/Linux \
     --findings_file all_findings.json \
@@ -212,7 +212,7 @@ gn gen . --export-compile-commands
 ```
 4.  Run clang-tidy.
 ```
-<PATH_TO_LLVM_SRC>/clang-tidy/tool/run-clang-tidy.py \
+<PATH_TO_LLVM_SRC>/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py \
     -p . \# Set the root project directory, where compile_commands.json is.
     # Set the clang-tidy binary path, if it's not in your $PATH.
     -clang-tidy-binary <PATH_TO_LLVM_BUILD>/bin/clang-tidy \
@@ -220,11 +220,11 @@ gn gen . --export-compile-commands
     # and you are using the `fix` behavior of clang-tidy.
     -clang-apply-replacements-binary \
         <PATH_TO_LLVM_BUILD>/bin/clang-apply-replacements \
-    # The checks to employ in the build. Use `-*` to omit default checks.
+    # The checks to employ in the build. Use `-*,...` to omit default checks.
     -checks=<CHECKS> \
     -header-filter=<FILTER> \# Optional, limit results to only certain files.
     -fix \# Optional, used if you want to have clang-tidy auto-fix errors.
-    chrome/browser # The path to the files you want to check.
+    'chrome/browser/.*' # A regex of the files you want to check.
 
 Copy-Paste Friendly (though you'll still need to stub in the variables):
 <PATH_TO_LLVM_SRC>/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py \
@@ -235,12 +235,12 @@ Copy-Paste Friendly (though you'll still need to stub in the variables):
     -checks=<CHECKS> \
     -header-filter=<FILTER> \
     -fix \
-    chrome/browser
+    'chrome/browser/.*'
 ```
 
-\*It's not clear which, if any, `gn` flags may cause issues for
-`clang-tidy`. I've had no problems building a component release build,
-both with and without goma. if you run into issues, let us know!
+Note that the source file regex must match how the build specified the file.
+This means that on Windows, you must use (escaped) backslashes even from a bash
+shell.
 
 ### Questions
 
diff --git a/chromium/docs/closure_compilation.md b/chromium/docs/closure_compilation.md
index 52031907e0e..1c7cb59424b 100644
--- a/chromium/docs/closure_compilation.md
+++ b/chromium/docs/closure_compilation.md
@@ -120,8 +120,11 @@ You can locally test that your code compiles on Linux or Mac.  This requires
 python, depot_tools). Note: on Ubuntu, you can probably just run `sudo apt-get
 install openjdk-7-jre`.
 
-After you set enable_js_type_check = true in your gn args, you should be able to
-run:
+First, add the following to your GN args:
+```
+enable_js_type_check = true
+```
+Then you should be able to run:
 
 ```shell
 ninja -C out/Default webui_closure_compile
diff --git a/chromium/docs/code_reviews.md b/chromium/docs/code_reviews.md
index a42add2663c..ecfe7495897 100644
--- a/chromium/docs/code_reviews.md
+++ b/chromium/docs/code_reviews.md
@@ -232,9 +232,7 @@ directories. If the updates to the callers is mechanical, you can:
      result of the `//base` change. This is often the same person from the
      previous step but could be somebody else.
 
-  3. TBR the owner of the lower-level code you're changing (in this example,
-     `//base`), after they've LGTM'ed the API change, to bypass owners review of
-     the API consumers incurring trivial side-effects.
+  3. TBR the owners of the calling code, after the API change is LGTM'ed.
 
 This process ensures that all code is reviewed prior to checkin and that the
 concept of the change is reviewed by a qualified person, without having to ping
@@ -267,4 +265,3 @@ comments inside functions.
 
   * Be sure to actually send out the email for the code review. If you get one,
     please actually read the changes.
-
diff --git a/chromium/docs/commit_checklist.md b/chromium/docs/commit_checklist.md
index 72875f55fde..6ddeef93046 100644
--- a/chromium/docs/commit_checklist.md
+++ b/chromium/docs/commit_checklist.md
@@ -78,6 +78,14 @@ changes to a test device. If you're testing Chrome for ChromeOS, follow the
 [Simple Chrome][simple-chrome] instructions to deploy your changes to a test
 device. Make sure you hit every code path you changed.
 
+Think about testing any edge cases that could break your code. Some common edge
+cases to consider:
+
+*   Guest mode
+*   Enterprise/EDU/Supervised users
+*   Accessibility
+*   Official Chrome-branded build (for Googlers)
+
 ## 6. Write unit or browser tests for any new code
 
 Consider automating any manual testing you did in the previous step.
@@ -104,7 +112,7 @@ to specifically `git add` the files you want to commit before calling
 
 Run `git commit`. Be sure to write a useful commit message. Here are some
 [tips for writing good commit messages][uploading-a-change-for-review]. A
-shortcut for combining steps the previous step and this one is `git commit -a -m
+shortcut for combining the previous step and this one is `git commit -a -m
 <commit_message>`.
 
 ## 11. Squash your commits
@@ -133,8 +141,11 @@ with that branch has been merged. In summary, `git rebase-update` cleans up your
 local branches.
 
 You may run into rebase conflicts. Fix them manually before proceeding with
-`git rebase --continue`. Note that rebasing has the potential to break your
-build, so you might want to try re-building afterwards.
+`git rebase --continue`.
+
+Note that rebasing has the potential to break your build, so you might want to
+try re-building afterwards. You need to run `gclient sync -D` before trying to
+build again after a rebase-update, to update third-party dependencies.
 
 ## 13. Upload the CL to Gerrit
 
@@ -204,6 +215,13 @@ Don't use `chrome/OWNERS` as a blanket stamp if your CL makes significant
 changes to subsystems. Click `Submit to CQ` to try your change in the commit
 queue (CQ), which will land it if successful.
 
+Just because your CL made it through the CQ doesn't mean you're in the clear
+yet. There might be internal non-public try job failures, or bugs that went
+unnoticed during the code review process. Consider monitoring the
+[Chromium tree][chromium-tree] for about a day after your CL lands. If
+the Sheriff or anyone else brings any failures to your attention, revert the CL
+first and ask questions later. Gerrit can automatically generate revert CLs.
+
 ## 19. Cleanup
 
 After your CL is landed, you can use `git rebase-update` or `git cl archive` to
@@ -212,6 +230,7 @@ branches. Mark the associated crbug as "fixed".
 
 [//]: # (the reference link section should be alphabetically sorted)
 [build-instructions]: https://chromium.googlesource.com/chromium/src.git/+/master/docs/#Checking-Out-and-Building
+[chromium-tree]: https://ci.chromium.org/p/chromium/g/main/console
 [contributing]: contributing.md
 [simple-chrome]: https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md
 [uploading-a-change-for-review]: contributing.md#Uploading-a-change-for-review
diff --git a/chromium/docs/contributing.md b/chromium/docs/contributing.md
index a3c2505080d..2246188a4ef 100644
--- a/chromium/docs/contributing.md
+++ b/chromium/docs/contributing.md
@@ -353,6 +353,14 @@ general rules of thumb can be helpful in navigating how to structure changes:
   that future changes will be less likely to regress functionality. Protect
   your code with tests!
 
+- **Stick to the current set of supported languages as described in the
+  [styleguide][cr-styleguide].** While there is likely always a slightly better
+  tool for any particular job, maintainability of the codebase is paramount.
+  Reducing the number of languages eases toolchain and infrastructure
+  requirements, and minimizes the learning hurdles for developers to be
+  successful contributing across the codebase. Additions of new languages must
+  be approved by [//ENG_REVIEW_OWNERS](../ENG_REVIEW_OWNERS).
+
 ## Tips
 
 ### Review etiquette
diff --git a/chromium/docs/design/DIR_METADATA b/chromium/docs/design/DIR_METADATA
new file mode 100644
index 00000000000..fb07a25cf9d
--- /dev/null
+++ b/chromium/docs/design/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Internals>Core"
+}
\ No newline at end of file
diff --git a/chromium/docs/design/OWNERS b/chromium/docs/design/OWNERS
deleted file mode 100644
index 3605f481f0c..00000000000
--- a/chromium/docs/design/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Internals>Core
diff --git a/chromium/docs/design/sandbox.md b/chromium/docs/design/sandbox.md
index a73501f8c00..d3a62823b76 100644
--- a/chromium/docs/design/sandbox.md
+++ b/chromium/docs/design/sandbox.md
@@ -362,6 +362,13 @@ policies on the target process for enforcing security characteristics.
 * Compiler/Linker opt-in, not a run-time policy opt-in.  See
 [MSDN](https://msdn.microsoft.com/en-us/library/windows/desktop/mt637065(v=vs.85).aspx).
 
+#### CET Shadow Stack:
+
+* Only in Insider Builds of Windows 10 yet.
+* It's being evaluated and not enabled for any processes.  See
+[ticket](https://bugs.chromium.org/p/chromium/issues/detail?id=1136224),
+[MSDN](https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=vs-2019).
+
 #### Disable Font Loading:
 
 * &gt;= Win10
diff --git a/chromium/docs/early-hints.md b/chromium/docs/early-hints.md
new file mode 100644
index 00000000000..0385e908ba1
--- /dev/null
+++ b/chromium/docs/early-hints.md
@@ -0,0 +1,78 @@
+# 103 Early Hints
+
+Contact: early-hints-experiment@chromium.org
+
+[103 Early Hints](https://httpwg.org/specs/rfc8297.html) is the new HTTP status
+code used for preloading subresources earlier. In general, browsers cannot
+preload subresources until the main response is served, as resources to be
+preloaded are listed on headers or `<meta>` in the main response. Early Hints
+will enable browsers to start preloading before the main response is served.
+In addition, this can be used with other
+[Resource Hints](https://w3c.github.io/resource-hints/) APIs like preconnect.
+
+As of version 87, Chrome doesn't support Early Hints yet, but is going to run an
+open experiment to evaluate the effectiveness of Early Hints. This does NOT give
+you the real benefit yet, but will help us and the community to quantify the
+potential benefit of the feature.
+
+## How To Contribute to the Measurement
+
+Chrome landed code to record the time between when the hints are received to
+when the real navigation responses are received as of version 85, and this will
+help us learn how much benefit this may bring.
+
+Note that this timing information will be recorded only for the users who
+opted-in to help Chrome gather usage statistics. See the
+[Google Chrome Privacy Whitepaper](https://www.google.com/chrome/privacy/whitepaper.html#usagestats)
+for details.
+
+In order to gather this data, we will need sites to start sending Early Hints
+status code (103), so that Chrome can record the timing information for the
+hints for the navigation.
+
+Note that not all browsers may handle Early Hints status code gracefully. We are
+collaborating with Fastly on the timing to run this measurement, and they
+collect breakage reports here: https://early-hints.fastlylabs.com/.
+
+Once enough data is collected, we plan to publish our conclusions and the
+learnings from the experiments with the aggregated stats publicly. Upon requests
+we may also share the per-site metrics with the sites who have participated.
+
+## Metrics
+
+This section is mainly written for Chromium developers.
+
+Chrome will record the following metrics. These intervals indicate how much
+earlier we could start preloading with Early Hints. For example, we could
+calculate the ratio of "the interval between request start and response start"
+to "the interval between request start and Early Hints" to see the ratio of
+speed-up.
+
+### UMA
+
+These are recorded under PageLoad.Experimental.EarlyHints UMA event.
+
+- **FirstRequestStartToEarlyHints**: The interval between when the first HTTP
+  request is sent and when the headers of the Early Hints response is received
+  in reply to the request for the main resource of a main frame navigation.
+- **FinalRequestStartToEarlyHints**: The interval between when the final HTTP
+  request is sent and when the headers of the Early Hints response is received
+  in reply to the request for the main resource of a main frame navigation.
+- **EarlyHintsToFinalResponseStart**: The interval between when the headers of
+  the Early Hints response is received in reply to the final HTTP request and
+  when the headers of the final HTTP response is received for the main resource
+  of a main frame navigation.
+
+### UKM
+
+These are recorded under the NavigationTiming UKM event.
+
+- **EarlyHintsForFirstRequest**: The time relative to navigation start that the
+  headers of the Early Hints response are received in reply to the first HTTP
+  request for the main resource of a main frame navigation.
+- **EarlyHintsForFinalRequest**: The time relative to navigation start that the
+  headers of the Early Hints response are received in reply to the final HTTP
+  request for the main resource of a main frame navigation.
+- **FinalResponseStart**: The time relative to navigation start that the headers
+  of the final HTTP response are received for the main resource of a main frame
+  navigation.
diff --git a/chromium/docs/enterprise/description_guidelines.md b/chromium/docs/enterprise/description_guidelines.md
index 8e14c0f829a..9dd5890bbe3 100644
--- a/chromium/docs/enterprise/description_guidelines.md
+++ b/chromium/docs/enterprise/description_guidelines.md
@@ -6,6 +6,7 @@ how various product names and the like should be referenced.
 * Chrome Browser Cloud Management: `<ph name="CHROME_BROWSER_CLOUSE_MANAGEMENT_NAME">Chrome Browser Cloud Management</ph>`
 * Linux: `<ph name="LINUX_OS_NAME">Linux</ph>`
 * Internet Explorer: `<ph name="IE_PRODUCT_NAME">Internet® Explorer®</ph>`
+* Google Admin console: `<ph name="GOOGLE_ADMIN_CONSOLE_PRODUCT_NAME">Google Admin console</ph>`
 * Google Cast: `<ph name="PRODUCT_NAME">Google Cast</ph>`
 * Google Drive: `<ph name="GOOGLE_DRIVE_NAME">Google Drive</ph>`
 * macOS: `<ph name="MAC_OS_NAME">macOS</ph>`
diff --git a/chromium/docs/fuchsia_build_instructions.md b/chromium/docs/fuchsia_build_instructions.md
index 542b7b28635..ba27e01372f 100644
--- a/chromium/docs/fuchsia_build_instructions.md
+++ b/chromium/docs/fuchsia_build_instructions.md
@@ -161,7 +161,7 @@ have any Debug build-bots, it may be more broken than Release.
 `use_goma=true` is fine to use also if you're a Googler.
 
 Architecture options are x64 (default) and arm64. This can be set with
-`target_cpu=arm64`.
+`target_cpu=\"arm64\"`.
 
 ## Build
 
diff --git a/chromium/docs/gpu/gpu_testing_bot_details.md b/chromium/docs/gpu/gpu_testing_bot_details.md
index 84f40dc0311..a5a4eff16cf 100644
--- a/chromium/docs/gpu/gpu_testing_bot_details.md
+++ b/chromium/docs/gpu/gpu_testing_bot_details.md
@@ -66,7 +66,7 @@ differences in behavior between the tryservers and waterfall bots. Since the
 tryservers mirror waterfall bots, if the waterfall bot is working, the
 tryserver must almost inherently be working as well.
 
-[chromium_trybot.py]: https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipes/chromium_trybot.py
+[chromium_trybot.py]: https://chromium.googlesource.com/chromium/tools/build/+/master/recipes/recipes/chromium_trybot.py
 
 There are some GPU configurations on the waterfall backed by only one machine,
 or a very small number of machines in the Swarming pool. A few examples are:
@@ -137,7 +137,7 @@ See [Adding new steps to the GPU bots] for details on this process.
 
 In the [`tools/build`][tools/build] workspace:
 
-*   `scripts/slave/recipe_modules/chromium_tests/`:
+*   `recipes/recipe_modules/chromium_tests/`:
     *   [`chromium_gpu.py`][chromium_gpu.py] and
         [`chromium_gpu_fyi.py`][chromium_gpu_fyi.py] define the following for
         each builder and tester:
@@ -177,9 +177,9 @@ In the [`tools/build`][tools/build] workspace:
                 specific hardware configuration.
 
 [tools/build]:         https://chromium.googlesource.com/chromium/tools/build/
-[chromium_gpu.py]:     https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/chromium_tests/chromium_gpu.py
-[chromium_gpu_fyi.py]: https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/chromium_tests/chromium_gpu_fyi.py
-[trybots.py]:          https://chromium.googlesource.com/chromium/tools/build/+/master/scripts/slave/recipe_modules/chromium_tests/trybots.py
+[chromium_gpu.py]:     https://chromium.googlesource.com/chromium/tools/build/+/master/recipes/recipe_modules/chromium_tests/builders/chromium_gpu.py
+[chromium_gpu_fyi.py]: https://chromium.googlesource.com/chromium/tools/build/+/master/recipes/recipe_modules/chromium_tests/builders/chromium_gpu_fyi.py
+[trybots.py]:          https://chromium.googlesource.com/chromium/tools/build/+/master/recipes/recipe_modules/chromium_tests/trybots.py
 
 In the [`chromium/src`][chromium/src] workspace:
 
@@ -208,9 +208,6 @@ In the [`chromium/src`][chromium/src] workspace:
         behavior in the GN build.
 *   [`src/tools/mb/mb_config.pyl`][mb_config.pyl]
     *   Defines the GN arguments for all of the bots.
-*   [`src/tools/mb/mb_config_buckets.pyl`][mb_config_buckets.pyl]
-    *   A new version of [`mb_config.pyl`][mb_config.pyl] that should supersede
-        it.
 *   [`src/infra/config`][src/infra/config]:
     *   Definitions of how bots are organized on the waterfall,
         how builds are triggered, which VMs or machines are used for the
@@ -226,7 +223,6 @@ In the [`chromium/src`][chromium/src] workspace:
 [chromium.gpu.fyi.json]:                https://chromium.googlesource.com/chromium/src/+/master/testing/buildbot/chromium.gpu.fyi.json
 [gn_isolate_map.pyl]:                   https://chromium.googlesource.com/chromium/src/+/master/testing/buildbot/gn_isolate_map.pyl
 [mb_config.pyl]:                        https://chromium.googlesource.com/chromium/src/+/master/tools/mb/mb_config.pyl
-[mb_config_buckets.pyl]:                https://chromium.googlesource.com/chromium/src/+/master/tools/mb/mb_config_buckets.pyl
 [generate_buildbot_json.py]:            https://chromium.googlesource.com/chromium/src/+/master/testing/buildbot/generate_buildbot_json.py
 [mixins.pyl]:                           https://chromium.googlesource.com/chromium/src/+/master/testing/buildbot/mixins.pyl
 [waterfalls.pyl]:                       https://chromium.googlesource.com/chromium/src/+/master/testing/buildbot/waterfalls.pyl
@@ -245,9 +241,6 @@ sorry):
         GPUs. New GPU hardware should be added to this pool.
     *   Also defines the GCEs, Mac VMs and Mac machines used for CI builders
         on GPU and GPU.FYI waterfalls and trybots.
-*   [`chromium.star`][chromium.star]
-    *   Defines Swarming pools of GCEs, shared with Chromium, which are used
-        for CI builders on GPU and GPU.FYI waterfalls and trybots.
 *   [`pools.cfg`][pools.cfg]
     *   Defines the Swarming pools for GCEs and Mac VMs used for manually
         triggered trybots.
@@ -302,17 +295,14 @@ The process is:
    to be added to the right Swarming pools in a CL in the
    [`infradata/config`][infradata/config] (Google internal) workspace.
     1. GCEs for Windows CI builders and builder/testers should be added to
-       `luci-chromium-ci-win10-8` group in [`chromium.star`][chromium.star].
-       [Example](https://chrome-internal-review.googlesource.com/c/infradata/config/+/2077803).
+       `luci-chromium-gpu-ci-win10-8` group in [`gpu.star`][gpu.star].
     1. GCEs for Linux and Android CI builders and builder/testers should be added to
-       one of `luci-chromium-ci-xenial-*-8` groups (but not `*ssd-8`) in
-       [`chromium.star`][chromium.star].
-       [Example](https://chrome-internal-review.googlesource.com/c/infradata/config/+/2077803).
+       `luci-chromium-gpu-ci-xenial-8` group in [`gpu.star`][gpu.star].
     1. VMs for Mac CI builders and builder/testers should be added to
-       `gpu_ci_bots` group in [`gpu.star`][gpu.star].
+       `builderfull_gpu_ci_bots` group in [`gpu.star`][gpu.star].
        [Example](https://chrome-internal-review.googlesource.com/c/infradata/config/+/1166889).
     1. GCEs for CI testers for all OSes should be added to
-       `luci-chromium-ci-xenial-2` group in [`chromium.star`][chromium.star].
+       `luci-chromium-gpu-ci-xenial-2` group in [`gpu.star`][gpu.star].
        [Example](https://chrome-internal-review.googlesource.com/c/infradata/config/+/2016410).
     1. GCEs and VMs for CQ and optional CQ GPU trybots for should be added to
        a corresponding `gpu_try_bots` group in [`gpu.star`][gpu.star].
@@ -347,7 +337,8 @@ The process is:
        longer be necessary per [crbug.com/942301](http://crbug.com/942301),
        but consult with the Chrome Infra team to find out which of the
        [zones](https://cloud.google.com/compute/docs/regions-zones/) has
-       available capacity.
+       available capacity. This also can be checked on viceroy
+       [dashboard](https://viceroy.corp.google.com/chrome_infra/Quota/chrome?duration=7d).
     1. Get this reviewed and landed. This step associates the VM or pool of VMs
        with the bot's name on the waterfall for "builderful" bots or increases
        swarmed pool capacity for "builderless" bots.  
@@ -440,8 +431,7 @@ Builder].
     1.  Run `main.star` in [`src/infra/config`][src/infra/config] to update the
         generated files. Double-check your work there.
     1.  If you were adding a new builder, you would need to also add the new
-        machine to [`src/tools/mb/mb_config.pyl`][mb_config.pyl] and
-        [`src/tools/mb/mb_config_buckets.pyl`][mb_config_buckets.pyl].
+        machine to [`src/tools/mb/mb_config.pyl`][mb_config.pyl].
 
 1. After the Chromium-side CL lands it will take some time for all of
    the configuration changes to be picked up by the system. The bot
@@ -454,7 +444,7 @@ Builder].
    following. Here's an [example
    CL](https://chromium-review.googlesource.com/1041145).
     1.  Adds the new bot to [`chromium_gpu_fyi.py`][chromium_gpu_fyi.py] in
-        `scripts/slave/recipe_modules/chromium_tests/`. Make sure to set the
+        `recipes/recipe_modules/chromium_tests/builders/`. Make sure to set the
         `serialize_tests` property to `True`. This is specified for waterfall
         bots, but not trybots, and helps avoid overloading the physical
         hardware. Double-check the `BUILD_CONFIG` and `parent_buildername`
@@ -464,7 +454,7 @@ Builder].
         the newly-deployed waterfall bot, so it knows which JSON file to load
         out of src/testing/buildbot and which entry to look at.
     1.  Sometimes it is necessary to retrain recipe expectations
-        (`scripts/slave/recipes.py test train`). This is usually needed only
+        (`recipes/recipes.py test train`). This is usually needed only
         if the bot adds untested code flow in a recipe, but it's something
         to watch out for if your CL fails presubmit for some reason.
 
@@ -502,8 +492,8 @@ writing only NVIDIA). To do this:
     before proceeding.
 1.  Create a CL in the [`tools/build`][tools/build] workspace, adding the new
     Release tester to `win10_chromium_x64_rel_ng`'s `bot_ids` list
-    in `scripts/slave/recipe_modules/chromium_tests/trybots.py`. Rerun
-    `scripts/slave/recipes.py test train`.
+    in `recipes/recipe_modules/chromium_tests/trybots.py`. Rerun
+    `recipes/recipes.py test train`.
 1.  Once the above CL lands, the commit queue will **immediately** start
     running tests on the CoolNewGPUType configuration. Be vigilant and make
     sure that tryjobs are green. If they are red for any reason, revert the CL
@@ -557,7 +547,7 @@ trybot for the Win7 NVIDIA GPUs in Release mode. We will call the new bot
    CL](https://chromium-review.googlesource.com/c/chromium/tools/build/+/1979113).
 
     1.  Adds the new trybot to a "Manually-triggered GPU trybots" section in
-        `scripts/slave/recipe_modules/chromium_tests/trybots.py`. Create this
+        `recipes/recipe_modules/chromium_tests/tests/trybots.py`. Create this
         section after the "Optional GPU bots" section for the appropriate
         tryserver (`tryserver.chromium.win`, `tryserver.chromium.mac`,
         `tryserver.chromium.linux`, `tryserver.chromium.android`). Have the bot
@@ -570,7 +560,7 @@ trybot for the Win7 NVIDIA GPUs in Release mode. We will call the new bot
         tests to run and on what physical hardware.
     1.  It may be necessary to retrain recipe expectations for
         [`tools/build`][tools/build] workspace CLs
-        (`scripts/slave/recipes.py test train`). This shouldn't be necessary
+        (`recipes/recipes.py test train`). This shouldn't be necessary
         for just adding a manually triggered trybot, but it's something to
         watch out for if your CL fails presubmit for some reason.
 
@@ -628,15 +618,14 @@ Win10 Release (CoolNewGPUType)".
         [`luci-scheduler.cfg`][luci-scheduler.cfg],
         [`cr-buildbucket.cfg`][cr-buildbucket.cfg]. Double-check your work
         there.
-    1.  Update [`src/tools/mb/mb_config.pyl`][mb_config.pyl] and
-        [`src/tools/mb/mb_config_buckets.pyl`][mb_config_buckets.pyl]
+    1.  Update [`src/tools/mb/mb_config.pyl`][mb_config.pyl]
         to include `win-myproject-rel`.
 1. *After* the Chromium-side CL lands and the bot is on the console, create a CL
     in the [`tools/build`][tools/build] workspace which does the
     following. Here's an [example CL](https://crrev.com/c/1554272).
     1.  Adds "MyProject GPU Win10 Release
         (CoolNewGPUType)" to [`chromium_gpu_fyi.py`][chromium_gpu_fyi.py] in
-        `scripts/slave/recipe_modules/chromium_tests/`. You can copy a similar
+        `recipes/recipe_modules/chromium_tests/builders/`. You can copy a similar
         step.
     1.  Adds `win-myproject-rel` to [`trybots.py`][trybots.py] in the same folder.
         This is where you associate "MyProject GPU Win10 Release
diff --git a/chromium/docs/gpu/webgl_bug_triage.md b/chromium/docs/gpu/webgl_bug_triage.md
index 5e71775c85d..fff3f34dd76 100644
--- a/chromium/docs/gpu/webgl_bug_triage.md
+++ b/chromium/docs/gpu/webgl_bug_triage.md
@@ -87,9 +87,10 @@ with the person next on the triage rotation.
 This is intended to be a lightweight rotation that shouldn't take too much of
 the triager's time. For this reason it's scheduled independently of other shifts
 like [pixel wrangling](pixel_wrangling.md), and may overlap. If any conflicts do
-arise, please reach out or [swap
-shifts](https://www.chromium.org/developers/tree-sheriffs#TOC-How-to-swap).
+arise, please reach out or swap shifts.
 
-The rotation is managed in [rota-ng](https://rota-ng.appspot.com/).
-The rotation members, as well as a few others, are owners under their
-@google.com addresses.
+The rotation is [managed
+here](https://rotations.corp.google.com/rotation/6257611988008960) via the
+Google-internal rotations tool. Shift swaps are managed via the tool. The
+calendar which can be subscribed to in order to see the oncall person is linked
+from the "Google Calendar Integration" heading under "Settings".
diff --git a/chromium/docs/images/DIR_METADATA b/chromium/docs/images/DIR_METADATA
new file mode 100644
index 00000000000..595fd00be1d
--- /dev/null
+++ b/chromium/docs/images/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Blink>Image"
+}
\ No newline at end of file
diff --git a/chromium/docs/images/OWNERS b/chromium/docs/images/OWNERS
deleted file mode 100644
index d1a8dbfcf99..00000000000
--- a/chromium/docs/images/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Blink>Image
diff --git a/chromium/docs/images/vscode_python_connection_dialog.png b/chromium/docs/images/vscode_python_connection_dialog.png
new file mode 100644
index 00000000000..48c0895342a
--- /dev/null
+++ b/chromium/docs/images/vscode_python_connection_dialog.png
diff --git a/chromium/docs/infra/DIR_METADATA b/chromium/docs/infra/DIR_METADATA
new file mode 100644
index 00000000000..6cffdc204e4
--- /dev/null
+++ b/chromium/docs/infra/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Infra>Client>Chrome"
+}
\ No newline at end of file
diff --git a/chromium/docs/infra/OWNERS b/chromium/docs/infra/OWNERS
deleted file mode 100644
index 3d2e6d86b96..00000000000
--- a/chromium/docs/infra/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Infra>Client>Chrome
diff --git a/chromium/docs/initialize_blink_features.md b/chromium/docs/initialize_blink_features.md
index 369740f1ed4..bb6ab5f977a 100644
--- a/chromium/docs/initialize_blink_features.md
+++ b/chromium/docs/initialize_blink_features.md
@@ -11,8 +11,8 @@ If you simply need to enable/disable the Blink feature you can simply use
 
 However, if there are side effects (e.g. you need to disable other features if
 this feature is also disabled), you should declare a custom enabler function in
-- [third_party/blink/public/platform/web_runtime_features.h][WebRuntimeFeatures.h]
-- [third_party/blink/public/platform/web_runtime_features.cc][WebRuntimeFeatures.cc]
+- [third_party/blink/public/platform/web_runtime_features.h][web_runtime_features.h]
+- [third_party/blink/renderer/platform/exported/web_runtime_features.cc][web_runtime_features.cc]
 
 ## Step 2: Determine how your feature is initialized.
 ### 1) Depends on OS-specific Macros:
@@ -94,9 +94,9 @@ command line switch. In this case, your custom logic should live here in
 [runtime_features]:<https://chromium.googlesource.com/chromium/src/+/HEAD/content/child/runtime_features.cc>
 [RuntimeEnabledFeatures]:
 <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md>
-[WebRuntimeFeatures.h]:
-<https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/exported/web_runtime_features.h>
-[WebRuntimeFeatures.cc]:
+[web_runtime_features.h]:
+<https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/public/platform/web_runtime_features.h>
+[web_runtime_features.cc]:
 <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/exported/web_runtime_features.cc>
 [EnableFeatureFromString]:<https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/public/platform/web_runtime_features.h#56>
 [SetRuntimeFeatureDefaultsForPlatform]:<https://chromium.googlesource.com/chromium/src/+/HEAD/content/child/runtime_features.cc#46>
diff --git a/chromium/docs/ios/build_instructions.md b/chromium/docs/ios/build_instructions.md
index 188fd0bdb2e..3b2fbeb1f44 100644
--- a/chromium/docs/ios/build_instructions.md
+++ b/chromium/docs/ios/build_instructions.md
@@ -328,6 +328,23 @@ 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.
 
+### Debugging
+
+To help with deterministic builds, and to work with Goma, the path to source
+files in debugging symbols are relative to source directory. To allow Xcode
+to find the source files, you need to ensure to have an `~/.lldbinit-Xcode`
+file with the following lines into it (substitute {SRC} for your actual path
+to the root of Chromium's sources):
+
+```
+script sys.path[:0] = ['{SRC}/tools/lldb']
+script import lldbinit
+```
+
+This will also allow you to see the content of some of Chromium types in the
+debugger like `base::string16`, ... If you want to use `lldb` directly, name
+the file `~/.lldbinit` instead of `~/.lldbinit-Xcode`.
+
 ### Improving performance of `git status`
 
 #### Increase the vnode cache size
diff --git a/chromium/docs/ios/testing.md b/chromium/docs/ios/testing.md
index eeab38b269c..e761bd928f3 100644
--- a/chromium/docs/ios/testing.md
+++ b/chromium/docs/ios/testing.md
@@ -11,7 +11,125 @@ target (ending in _unittest).
 
 ## Integration testing
 
-[EarlGrey] is the integration testing framework used by Chromium for iOS.
+[EarlGrey] (EG2) is the integration testing framework used by Chromium for iOS.
+
+### Writing EarlGrey tests
+
+#### Before you start
+
+* Just write a unit test if the purpose of your test does not involve UI.
+* Learn about EarlGrey test framework principles and APIs in [EarlGrey].
+* Learn about [Defining Test Cases and Test Methods] from Apple.
+
+#### Creating test files and writing EG2 tests
+
+1. EG2 test files are ended with _egtest.mm, and usually located within the same
+directory of the UI code you wish to test.
+2. Basic imports of a EG2 test file:
+
+    * You’ll have to include:
+    ```
+    #import "ios/chrome/test/earl_grey/chrome_test_case.h
+    ```
+    * You’ll most likely find util functions in these files helpful.
+    ```
+    #import "ios/chrome/test/earl_grey/chrome_earl_grey.h"
+    #import "ios/chrome/test/earl_grey/chrome_earl_grey_ui.h"
+    #import "ios/chrome/test/earl_grey/chrome_matchers.h"
+    ```
+    * Beside these, directly import an EG2 header for an EG2 API you are using.
+
+3. TestCase/testMethods definitions. Create `SomeGreatTestCase` as a subclass of
+`ChromeTestCase`. Create test methods, eg `-(void)testMyGreatUIFeature {...}`,
+and put UI actions within the test methods. 
+    * Put your setup and tear down code for the *TestCase* in 
+`+(void)setUpForTestCase` and `+tearDown`. These will run once before and
+after all tests for the test class.
+    * Put your setup and tear down code for each *test method* in `-(void)setUp`
+and `-(void)tearDown`. These will run before and after every
+`-(void)testMethod` in the file.
+4. Writing test contents. See the chrome helpers (imports in 2.) as well as
+[EarlGrey APIs] to write a UI action/assertion in your testMethod.
+
+#### Interacting with the app in a test
+
+##### Relaunch app with different flags
+
+In EG2 tests, the test process launches the host app process at the beginning,
+then runs UI actions/assertions in the app. To pass args or feature flags to the
+app at initial launching, or relaunch the app in the middle of your test, see
+[this AppLaunchManager API].
+
+##### Accessing app internals
+
+EG2 test targets are built with test-related code but without app code.
+
+To access anything from the app side, use an "app interface". App interface is
+implemented as a class that lives in the app process, but can be accessed in the
+test process through [eDO]. You can include the header in your test side code
+and call class methods of the interface class. The methods will execute code in
+the app process and can return basic Objective-C types. See this [Example of App
+ Interface].
+
+See `eg_test_support+eg2` (test side utilities) and `eg_app_support+eg2` (app
+side utilities) targets in `BUILD.gn` files to learn how test utilities are
+organized in targets. If you added an app side helper (app interface), you’ll
+also need to include your new `eg_app_support+eg2` target in
+`//ios/chrome/test/earl_grey/BUILD.gn`’s `eg_app_support+eg2` target. ([Example
+ CL adding App Interface]).
+
+Note that if you create an App interface, you can’t build the app interface
+class in your eg2_tests target, but you need to include and refer to it. If you
+see a “Undefined symbols for architecture… MyTestAppInterface”, add
+```
+#if defined(CHROME_EARL_GREY_2)
+// TODO(crbug.com/1015113) The EG2 macro is breaking indexing for some reason
+// without the trailing semicolon.  For now, disable the extra semi warning
+// so Xcode indexing works for the egtest.
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wc++98-compat-extra-semi"
+GREY_STUB_CLASS_IN_APP_MAIN_QUEUE(HandoffManagerAppInterface);
+#pragma clang diagnostic pop
+#endif  // defined(CHROME_EARL_GREY_2)
+```
+to the top of your foo_egtest.mm file. 
+
+#### Creating test targets and adding the target to test suites
+
+1. Create a test target. Add a target(`source_set`) named "eg2_tests" into the
+closest `BUILD.gn` file. Put the test file into the `sources` array and put the
+targets containing headers used in your test file into `deps` array. This is to
+organize test source files and dependencies so that the GN build system can
+correctly build the test module. The skeleton of the target:
+```
+source_set("eg2_tests") {
+  configs += [
+    "//build/config/compiler:enable_arc",
+    "//build/config/ios:xctest_config",
+  ]
+  testonly = true
+  sources = [
+    "some_egtest.mm"
+  ]
+  deps = [
+    "//ios/chrome/test/earl_grey:eg_test_support+eg2",
+    "//ios/testing/earl_grey:eg_test_support+eg2",
+    "//ios/third_party/earl_grey2:test_lib",
+  ]
+  libs = [ "UIKit.framework" ]
+}
+```
+2. Include your test target in the `deps` array of a suitable suite in
+`//src/ios/chrome/test/earl_grey2/BUILD.gn`.
+3. Optional: If you feel like your new test should be in a new suite, or you
+want to delete an existing suite to make tests better organized, you’ll need to
+change the suites in `//src/ios/chrome/test/earl_grey2/BUILD.gn` in the format
+of existing ones. (Do not forget to [config the bots] so the new suite can run
+in infra.)
+4. Ensure your dependencies are correct.
+```
+$ gn gen --check out/Debug-iphonesimulator
+```
 
 ### Running EarlGrey tests
 
@@ -19,27 +137,74 @@ EarlGrey tests are based on Apple's [XCUITest].
 
 #### Running tests from Xcode
 
-An entire suite of tests can be run from Xcode.
-1. Select the *egtest target you wish to run.
-2. ⌘+U to run all the tests. Note: ⌘+R, which is normally used to run an
-application, will simply launch the app under test, but will not run the
-XCTests.
-
-A subset of tests can be run by selecting the test or test case from the
-XCTest navigator on the left side of the screen.
+1. If you added a new test file / suite, run `gclient runhooks` to sync for the
+list of tests in Xcode.
+2. Change the scheme to "ios_chrome_eg2test". Create and select the simulator
+you wish to use.
+3. You may run a test suite(module), TestCase or testMethod in test navigator.
+Xcode will build the targets and run the test(s) you choose. Alternatively, 
+use ⌘+U to run all the tests. See Apple's [Running Tests and Viewing Results].
 
 #### Running from the command-line
 
-When running from the command-line, it is required to pass in the *.xctest
-target, in addition to the test application.
+EG2 tests can run in the command line with test runner scripts. You’ll need to
+build the targets before running tests in cmd. This is used by continuous
+integration infra and thus not user friendly. Running UI tests directly in Xcode
+is recommended.
+
+Important notes:
+* The test runner can invoke mac_toolchain to install a new Xcode of the version
+specified to the path specified. You may want to choose a different path from
+your daily use Xcode.
+* If test_cases is empty in --args-json, all tests will run. Specifying a
+testMethod to run is currently not supported in the test runner.
+
 Example:
 ```
-./out/Debug-iphonesimulator/iossim -d "iPad Retina" -s 8.1 \
-out/Debug-iphonesimulator/ios_chrome_integration_egtests.app \
-out/Debug-iphonesimulator/ios_chrome_integration_egtests_module.xctest
+src/ios/build/bots/scripts/run.py
+    --app
+    src/out/Debug-iphonesimulator/ios_chrome_ui_eg2tests_module-Runner.app
+    --host-app
+    src/out/Debug-iphonesimulator/ios_chrome_eg2tests.app
+    --args-json
+    {"test_args": [], "xctest": false, "test_cases": ["ReadingListTestCase"],
+    "restart": false, "xcode_parallelization": true, "xcodebuild_device_runner":
+    false}
+    --out-dir
+   path/to/output/dir
+    --retries
+    3
+    --shards
+    1
+    --xcode-build-version
+    11c29
+    --mac-toolchain-cmd
+    path/to/mac_toolchain
+    --xcode-path
+    path/to/Xcode.app
+    --wpr-tools-path
+    NO_PATH
+    --replay-path
+    NO_PATH
+    --iossim
+    src/out/Debug-iphonesimulator/iossim
+    --platform
+    iPad (6th generation)
+    --version
+    13.3
 ```
+The invocation args are logged. You can find the latest arg format at the
+beginning of stdout from an infra test shard if the above doesn't work.
 
 
-[EarlGrey]: https://github.com/google/EarlGrey
+[config the bots]: https://chromium.googlesource.com/chromium/src/testing/+/refs/heads/master/buildbot/README.md#buildbot-testing-configuration-files
+[Defining Test Cases and Test Methods]: https://developer.apple.com/documentation/xctest/defining_test_cases_and_test_methods?language=objc
+[EarlGrey]: https://github.com/google/EarlGrey/tree/earlgrey2
+[EarlGrey APIs]: https://github.com/google/EarlGrey/blob/master/docs/api.md
+[eDO]: https://github.com/google/eDistantObject
+[Example of App Interface]: https://cs.chromium.org/chromium/src/ios/chrome/browser/metrics/metrics_app_interface.h
+[Example CL adding App Interface]: https://chromium-review.googlesource.com/c/chromium/src/+/1919147
 [instructions]: ./build_instructions.md
+[Running Tests and Viewing Results]: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/05-running_tests.html
+[this AppLaunchManager API]: https://source.chromium.org/chromium/chromium/src/+/master:ios/testing/earl_grey/app_launch_manager.h;drc=d0889865de20c5b3bc59d58674eb2dcc02dd2269;l=47
 [XCUITest]: https://developer.apple.com/documentation/xctest
diff --git a/chromium/docs/ios/working_with_files.md b/chromium/docs/ios/working_with_files.md
index 37a74a8f417..f7949793f43 100644
--- a/chromium/docs/ios/working_with_files.md
+++ b/chromium/docs/ios/working_with_files.md
@@ -111,16 +111,16 @@ in files, import declarations in files, listings in BUILD.gn files, and
 internally in the XCode project. As with adding a file, different tools are used
 for each of these. Unlike creating a file, which starts with actually adding a
 file to the filesystem, a rename starts with updating git (via `git mv`), then
-using the `mass_rename` tool to update file contents.
+using the `mass-rename` tool to update file contents.
 
-`tools/git/mass_rename.py` works by looking at _uncommitted_ file moves in git,
+`tools/git/mass-rename.py` works by looking at _uncommitted_ file moves in git,
 and then updating all includes, header guards, and BUILD.gn entries to use the
 new name. It doesn't update some other files, such as `Contents.json` files for
 image assets. It also doesn't change any symbols in code, so class and variable
 names won't be changed.
 
 For many file moves, it will be simpler to use another tool,
-`tools/git/move_source_file.py`, which combines `git mv` and `mass_rename` in a
+`tools/git/move_source_file.py`, which combines `git mv` and `mass-rename` in a
 single action. For example, renaming `feature_class` to `renamed_class` would be
 done like this:
 ```bash
@@ -152,7 +152,7 @@ The step-by-step procedure for a rename is:
 1.  Commit all changes (`git commit -a -m <your comment>`).
 
 A move—where a file is moved to a different directory—is in most respects
-performed using the same steps as a rename. However, while `mass_rename.py` (and
+performed using the same steps as a rename. However, while `mass-rename.py` (and
 thus `move_source_file.py`) will update existing file names in `BUILD.gn` files,
 it won't move entries from one `BUILD.gn` file to another. To move files to a
 different directory, the preceding procedure is used, but between steps 2 and 3
@@ -165,7 +165,7 @@ being renamed within a directory, it (just like `git mv`) can move multiple
 files without renaming to a new directory in a single command:
 
 ```bash
-$ tools/git/mass_rename.py ios/chrome/browser/some_feature/feature_class.* \
+$ tools/git/mass-rename.py ios/chrome/browser/some_feature/feature_class.* \
     ios/chrome/browser/some_feature/feature_class_unittest.mm \
     ios/chrome/browser/other_feature/
 ```
diff --git a/chromium/docs/lacros.md b/chromium/docs/lacros.md
index 8ba2a6dfe6a..a4fd2dc4a4b 100644
--- a/chromium/docs/lacros.md
+++ b/chromium/docs/lacros.md
@@ -50,18 +50,57 @@ The API lives in
 The ash-side implementation lives in
 [//chrome/browser/chromeos/crosapi](https://chromium.googlesource.com/chromium/src.git/+/master/chrome/browser/chromeos/crosapi).
 
-Code can be conditionally compiled into lacros via BUILDFLAG(IS_LACROS).
+Code can be conditionally compiled into lacros via
+BUILDFLAG(IS_CHROMEOS_LACROS).
 
 Lacros bugs can be filed under component: OS>LaCrOs.
 
+## GN var and C++ macros for Lacros
+
+### Desired state
+
+- defined(OS_CHROMEOS) is true in C++ for both ash-chrome and lacros-chrome.
+- BUILDFLAG(IS_CHROMEOS_ASH) in C++ is used for ash-chrome specific part.
+- BUILDFLAG(IS_CHROMEOS_LACROS) in C++ is used for lacros-chrome specific part.
+- GN variable is_chromeos is true for both ash-chrome and lacros-chrome.
+- GN variable is_chromeos is equivalent to is_chromeos_ash || is_chromeos_lacros.
+- GN variable is_chormeos_ash is used for ash-chrome specific part.
+- GN variable is_chromeos_lacros is used for lacros-chrome specific part.
+
+### Current state
+
+OS_CHROMEOS is defined and is_chromeos is set only for ash-chrome at the moment.
+We are currently migrating defined(OS_CHROMEOS) to BUILDFLAG(IS_CHROMEOS_ASH),
+see [crbug.com/1052397](https://crbug.com/1052397). Until the migration is
+complete, for parts used by both ash-chrome and lacros-chrome, use
+`BUILDFLAG(IS_CHROMEOS_ASH) || BUILDFLAG(IS_CHROMEOS_LACROS)` in C++ files and
+`is_chromeos_ash || is_chromeos_lacros` in GN files. After the migration, the
+macros and GN variables should be used according to the above desired state.
+
+Googlers:
+- [go/lacros-porting](http://go/lacros-porting) has tips on which binary the code should live in.
+- [go/lacros-macros](http://go/lacros-macros) describes the steps for the migration.
+- [go/lacros-build-config](http://go/lacros-build-config) is the original design doc.
+
 ## Testing
 
 Most test suites require ash-chrome to be running in order to provide a basic
-Wayland server and the crosapi implementation. This requires a special test
-runner:
+Wayland server. This requires a special test runner:
 
 `./build/lacros/test_runner.py test out/lacros/browser_tests --gtest_filter=BrowserTest.Title`
 
+Some test suites require ash-chrome to provide both a Wayland server and a valid
+mojo crosapi connection. This requires the test target
+`lacros_chrome_browsertests`:
+
+`./build/lacros/test_runner.py test out/lacros/lacros_chrome_browsertests --gtest_filter=ScreenManagerLacrosBrowserTest.*`
+
+By default, the test runner downloads a prebuilt ash-chrome, add the
+`--ash-chrome-path` command line argument to run the test against a locally
+built version of Ash:
+
+`./build/lacros/test_runner.py test --ash-chrome-path=out/ash/chrome out/lacros/lacros_chrome_browsertests --gtest_filter=ScreenManagerLacrosBrowserTest.*`
+
 If you're sshing to your desktop, please prefix the command with
 `./testing/xvfb.py`.
 
diff --git a/chromium/docs/linux/debugging.md b/chromium/docs/linux/debugging.md
index 03b29e3dcb8..4c1ecdb2caa 100644
--- a/chromium/docs/linux/debugging.md
+++ b/chromium/docs/linux/debugging.md
@@ -316,7 +316,7 @@ See
 https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/gdb-add-index/chromium-dev/ELRuj1BDCL4/5Ki4LGx41CcJ
 for more info.
 
-You can improve GDB load time significantly at the cost of link time by
+You can improve GDB load time significantly at the cost of link time by not
 splitting symbols from the object files. In GN, set `use_debug_fission=false` in
 your "gn args".
 
diff --git a/chromium/docs/login/DIR_METADATA b/chromium/docs/login/DIR_METADATA
new file mode 100644
index 00000000000..3f722310112
--- /dev/null
+++ b/chromium/docs/login/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Services>SignIn"
+}
\ No newline at end of file
diff --git a/chromium/docs/login/OWNERS b/chromium/docs/login/OWNERS
deleted file mode 100644
index 7bc732e34cf..00000000000
--- a/chromium/docs/login/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Services>SignIn
diff --git a/chromium/docs/login/user_types.md b/chromium/docs/login/user_types.md
index 3e5f8c999b6..99cf1c07c44 100644
--- a/chromium/docs/login/user_types.md
+++ b/chromium/docs/login/user_types.md
@@ -16,9 +16,12 @@ Regular users that were registered using their GAIA account.
 ## Child users
 
 Users that logged in using
-*   a child account - an account designated for children under the age of 13.
+*   a Unicorn account - an account designated for children under the age of
+    consent in their jurisdiction.
 *   a Geller account - an account with parental supervision that has no age
     restrictions.
+*   a Griffin account - similar to a Geller account, but for compliance with
+    European Union laws.
 
 In order to add a child user to the device, the user has to go through an
 adapted GAIA flow, which also requires their parent to authenticate.
diff --git a/chromium/docs/mac_arm64.md b/chromium/docs/mac_arm64.md
index 8c37b0e3886..646973deea1 100644
--- a/chromium/docs/mac_arm64.md
+++ b/chromium/docs/mac_arm64.md
@@ -1,5 +1,4 @@
-Chromium for arm Macs
-=====================
+# Chromium for arm Macs
 
 Apple is planning on selling Macs with arm chips by the end of 2020.
 This document describes the state of native binaries for these Macs.
@@ -11,23 +10,15 @@ There's also a [tester
 bot](https://ci.chromium.org/p/chromium/builders/ci/mac-arm64-rel-tests)
 that continuously runs tests. Most tests pass.
 
-Building _for_ arm Macs
------------------------
+## Building _for_ arm Macs
 
 You can build Chrome for arm macs on an Intel Mac. To build for arm64, you have
 to do 2 things:
 
-1. use the `MacOSX11.0.sdk` that comes with
-   Xcode 12 beta. If you're on Google's corporate network, edit your `.gclient`
-   file and add this `custom_vars`:
-
-       "custom_vars": { "mac_xcode_version": "xcode_12_beta" },
-
-   Then just run `gclient sync` and you'll automatically get that SDK and will
-   build with it.
-
-   Otherwise, manually download and install the current Xcode 12 beta and make
-   it the active Xcode with `xcode-select`.
+1. use the `MacOSX11.0.sdk` that comes with Xcode 12.2. If you're on Google's
+   corporate network, this SDK is part of the hermetic toolchain and will be
+   used automatically. Otherwise, manually download and install this version of
+   Xcode and, if necessary, make it the active Xcode with `xcode-select`.
 
 2. Add `target_cpu = "arm64"` to your `args.gn`.
 
@@ -59,8 +50,37 @@ available for Googlers to run tests on.
 You can follow the [Mac-ARM64 label](https://crbug.com/?q=label%3Amac-arm64) to
 get updates on progress.
 
-Building _on_ arm Macs
------------------------
+### Universal Builds
+
+A “universal” (or “fat”) `.app` can be created from distinct x86_64 and arm64
+builds produced from the same source version. Chromium has a `universalizer.py`
+tool that can then be used to merge the two builds into a single universal
+`.app`.
+
+    % ninja -C out/release_x86_64 chrome
+    % ninja -C out/release_arm64 chrome
+    % mkdir out/release_universal
+    % chrome/installer/mac/universalizer.py \
+          out/release_x86_64/Chromium.app \
+          out/release_arm64/Chromium.app \
+          out/release_universal/Chromium.app
+
+The universal build is produced in this way rather than having a single
+all-encompassing `gn` configuration because:
+
+ - Chromium builds tend to take a long time, even maximizing the parallelism
+   capabilities of a single machine. This split allows an additional dimension
+   of parallelism by delegating the x86_64 and arm64 build tasks to different
+   machines.
+ - During the mac-arm64 bring-up, the x86_64 and arm64 versions were built using
+   different SDK and toolchain versions. When using the hermetic SDK and
+   toolchain, a single version of this package must be shared by an entire
+   source tree, because it’s managed by `gclient`, not `gn`. However, as of
+   November 2020, Chromium builds for the two architectures converged and are
+   expected to remain on the same version indefinitely, so this is now more of a
+   historical artifact.
+
+## Building _on_ arm Macs
 
 Building _on_ arm Macs means that all the tools we use to build chrome need
 to either work under Rosetta or have a native arm binary.
diff --git a/chromium/docs/mac_build_instructions.md b/chromium/docs/mac_build_instructions.md
index 4213fd64d92..b6609bb7c80 100644
--- a/chromium/docs/mac_build_instructions.md
+++ b/chromium/docs/mac_build_instructions.md
@@ -104,6 +104,7 @@ $ gn gen out/Default
   operating system and CPU.
 * For more info on GN, run `gn help` on the command line or read the
   [quick start guide](https://gn.googlesource.com/gn/+/master/docs/quick_start.md).
+* Building Chromium for arm Macs requires [additional setup](mac_arm64.md).
 
 
 ### Faster builds
diff --git a/chromium/docs/media/DIR_METADATA b/chromium/docs/media/DIR_METADATA
new file mode 100644
index 00000000000..ab32c2e2866
--- /dev/null
+++ b/chromium/docs/media/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Blink>Media"
+}
\ No newline at end of file
diff --git a/chromium/docs/media/OWNERS b/chromium/docs/media/OWNERS
deleted file mode 100644
index 796bd0dcf51..00000000000
--- a/chromium/docs/media/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Blink>Media
diff --git a/chromium/docs/memory-infra/DIR_METADATA b/chromium/docs/memory-infra/DIR_METADATA
new file mode 100644
index 00000000000..970fc89f715
--- /dev/null
+++ b/chromium/docs/memory-infra/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Internals>Instrumentation>Memory"
+}
\ No newline at end of file
diff --git a/chromium/docs/memory-infra/OWNERS b/chromium/docs/memory-infra/OWNERS
deleted file mode 100644
index d64ae8019ab..00000000000
--- a/chromium/docs/memory-infra/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Internals>Instrumentation>Memory
diff --git a/chromium/docs/memory/DIR_METADATA b/chromium/docs/memory/DIR_METADATA
new file mode 100644
index 00000000000..970fc89f715
--- /dev/null
+++ b/chromium/docs/memory/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Internals>Instrumentation>Memory"
+}
\ No newline at end of file
diff --git a/chromium/docs/memory/OWNERS b/chromium/docs/memory/OWNERS
deleted file mode 100644
index d64ae8019ab..00000000000
--- a/chromium/docs/memory/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Internals>Instrumentation>Memory
diff --git a/chromium/docs/no_sources_assignment_filter.md b/chromium/docs/no_sources_assignment_filter.md
index 428cc9c2b0b..09760b74911 100644
--- a/chromium/docs/no_sources_assignment_filter.md
+++ b/chromium/docs/no_sources_assignment_filter.md
@@ -4,48 +4,15 @@ There is a [strong][0] [consensus][1] that the set_sources_assignment_filter
 feature from GN is a mis-feature and should be removed. This requires that
 Chromium's BUILD.gn file stop using the feature.
 
-## Why convert
+Since October 2020, the filter is no longer used.
 
-When set_sources_assignment_filter is called, it configures a list of patterns
-that will be used to filter names every time a variable named "sources" is
-assigned a value.
+Chromium build does not set a default sources assignment filter, and all build
+files must manage `sources` with explicit `if` statements.
 
-Historically, Chromium used to call this function in build/BUILDCONFIG.gn thus
-causing the patterns to be applied to every BUILD.gn file in the project. This
-had multiple drawbacks:
+## Explicit assignment
 
-1.  the configuration of the list of patterns is located far from the point
-    where they are applied and developer are usually confused when a file
-    they add to a rule is not build due to those pattern
-
-2.  the filtering is applied to every assignment to a variable named "sources"
-    after interpreting the string as a relative filename, thus build breaks if
-    one of the forbidden pattern is used in unexpected location (like naming
-    the build directory out/linux, or having mac/ in path to SDK, ...)
-
-3.  the filtering is applied to every assignment to a variable named "sources"
-    in the whole project, thus it has significant negative impact on the
-    performance of gn
-
-Since September 2020, the filter is enabled only for the files that have not
-yet been converted. Eventually, this will be removed.
-
-## Conversion pattern
-
-To convert a BUILD.gn file it is necessary to change the following:
-
-```
-  source_set("foo") {
-    sources = [
-      "foo.h",
-      "foo_mac.mm",
-      "foo_win.cc",
-      "foo_linux.cc",
-    ]
-  }
-```
-
-to
+If you have a target that have platform specific implementation files, you can
+use the following pattern:
 
 ```
   source_set("foo") {
@@ -70,18 +37,5 @@ to
   }
 ```
 
-Since the second pattern never assign a name that will be filtered out, then
-it is compatible whether the set_sources_assignment_filter feature is used or
-not.
-
-Once conversion is done, remove the following lines from the top of the file
-to avoid regressions:
-
-```
-import("//build/config/deprecated_default_sources_assignment_filter.gni")
-sources_assignment_filter = deprecated_default_sources_assignment_filter
-```
-
-
 [0]: https://groups.google.com/a/chromium.org/d/topic/chromium-dev/hyLuCU6g2V4/discussion
 [1]: https://groups.google.com/a/chromium.org/d/topic/gn-dev/oQcYStl_WkI/discussion
diff --git a/chromium/docs/origin_trials_integration.md b/chromium/docs/origin_trials_integration.md
index 2ca187f2392..f17efb90f6b 100644
--- a/chromium/docs/origin_trials_integration.md
+++ b/chromium/docs/origin_trials_integration.md
@@ -7,6 +7,11 @@ changes required.
 
 ## Code Changes
 
+NOTE: You can land these code changes before requesting to run an origin trial.
+These code changes make it possible to control a feature via an origin trial,
+but don't require an origin trial to be approved. For more on the process, see
+[Running an Origin Trial].
+
 ### Runtime Enabled Features
 
 First, you’ll need to configure [runtime\_enabled\_features.json5]. This is
@@ -186,6 +191,14 @@ To test an origin trial feature during development, follow these steps:
       tools/origin_trials/generate_token.py http://localhost:8000 MyFeature
       ```
 
+   There are additional flags to generate third-party tokens, set the expiry
+   date, and control other options. See the command help for details (`--help`).
+   For example, to generate a third-party token, with [user subset exclusion]:
+
+      ```
+      tools/origin_trials/generate_token.py --is-third-party --usage-restriction=subset http://localhost:8000 MyFeature
+      ```
+
 2. Copy the token from the end of the output and use it in a `<meta>` tag or
    an `Origin-Trial` header as described in the [Developer Guide].
 
@@ -236,4 +249,5 @@ as tests for script-added tokens. For examples, refer to the existing tests in
 [css\_properties.json5]: /third_party/blink/renderer/core/css/css_properties.json5
 [origin-trial-test-property]: https://chromium.googlesource.com/chromium/src/+/ff2ab8b89745602c8300322c2a0158e210178c7e/third_party/blink/renderer/core/css/css_properties.json5#2635
 [CSSStyleDeclaration]: /third_party/blink/renderer/core/css/css_style_declaration.idl
-
+[Running an Origin Trial]: https://www.chromium.org/blink/origin-trials/running-an-origin-trial
+[user subset exclusion]: https://docs.google.com/document/d/1xALH9W7rWmX0FpjudhDeS2TNTEOXuPn4Tlc9VmuPdHA/edit#heading=h.myaz1twlipw
diff --git a/chromium/docs/patterns/domain-lens.md b/chromium/docs/patterns/domain-lens.md
new file mode 100644
index 00000000000..c2bed7d9ee5
--- /dev/null
+++ b/chromium/docs/patterns/domain-lens.md
@@ -0,0 +1,150 @@
+# The Domain Lens Pattern
+
+The Domain Lens Pattern exposes a specific, more restricted view of a
+complicated class, customized to the needs of a specific domain. The name comes
+from the metaphor of looking at a class "through a specific lens", which
+magnifies parts of the class and hides other parts. This helps decouple clients
+from the entire implementation of the complicated class.
+
+Here's an example. Suppose we have a class NetworkRequest:
+
+```c++
+class NetworkRequest {
+  // ... lots of state ...
+  size_t bytes_done() const;
+  size_t bytes_to_do() const;
+};
+```
+
+and suppose that we are implementing a UI component that displays the status of
+a download, which is backed by a NetworkRequest. We could implement that like:
+
+```c++
+class DownloadView : public NetworkRequestObserver {
+ public:
+  // Start displaying the status of the given network request.
+  DownloadView(NetworkRequest* request);
+
+  // NetworkRequestObserver:
+  void OnRequestProgress(NetworkRequest* request) override;
+};
+```
+
+But there are two problems with this:
+
+1. When testing DownloadView, we need an entire NetworkRequest, and it's not
+   clear which parts of the NetworkRequest need to be filled in for DownloadView
+   to work;
+2. If we are refactoring and adding a different class (say for example
+   `DiskFileRequest` for a load from local disk), that class must subclass
+   `NetworkRequest` for DownloadView to be usable with it, which usually
+   involves a lot of empty methods and stub data.
+
+Instead, we can define a domain-specific lens, containing only the subset of the
+data in `NetworkRequest` needed to display download progress, like this:
+
+```c++
+struct DownloadProgress {
+  base::FilePath destination;
+  size_t bytes_done;
+  size_t bytes_to_do;
+};
+```
+
+and two interfaces for receiving updates on that domain-specific lens:
+
+```c++
+class DownloadProgressObserver {
+ public:
+  void OnDownloadProgress(const DownloadProgress& progress);
+};
+
+class DownloadProgressProvider {
+ public:
+  void AddObserver(DownloadProgressObserver* observer);
+  void RemoveObserver(DownloadProgressObserver* observer);
+
+  DownloadProgress GetCurrentProgress() const;
+};
+```
+
+at which point `DownloadView` is:
+
+```c++
+class DownloadView : public DownloadProgressObserver {
+ public:
+  DownloadView(DownloadProgressProvider* provider);
+};
+```
+
+or perhaps, using a callback rather than an observer class:
+
+```c++
+using DownloadProgressCallback =
+    base::RepeatingCallback<void(const DownloadProgress& progress)>;
+
+class DownloadProgressProvider {
+ public:
+  base::CallbackList::Subscription
+      RegisterDownloadProgressCallback(DownloadProgressCallback callback);
+  DownloadProgress GetCurrentProgress();
+};
+
+class DownloadView {
+ public:
+  DownloadView(DownloadProgressProvider* provider);
+};
+```
+
+## When To Use A Domain Lens
+
+A domain lens makes sense when you have:
+
+* A complicated object with a lot of state
+* A well-defined domain or client class that makes use of part of that
+  complicated object
+
+A common use of domain lenses is to extract only the data needed to display an
+object into a separate type, to decouple the object from its display logic. One
+Chromium example of this is [TabRendererData], which encapsulates only the state
+of a Tab needed to draw that Tab somewhere, without providing access to the
+Tab's underlying webcontents or any methods for mutating it.
+
+Here's another hypothetical, to illustrate this pattern. We have a class
+[ProfileAttributesEntry], which contains a lot of different pieces of data about
+a Profile. We might define a type and a new method on `ProfileAttributes`,
+specifically for drawing the profile "chip" that can replace the app menu icon:
+
+```c++
+// Note that this is a separate top-level type from ProfileAttributes. One could
+// instead define this as a nested type ProfileAttributes::LensForChip or
+// something similar, but then any user of this domain lens would need to have
+// the declaration of ProfileAttributes visible as well, which would cause some
+// of the coupling we're trying to avoid in the first place.
+struct ProfileAttributesForChip {
+  gfx::ImageSkia icon;
+  std::string name;
+  ...
+};
+
+ProfileAttributesForChip ProfileAttributes::ForChip() {
+  ...
+}
+```
+
+and then have the profile chip code use a `ProfileAttributesForChip` instead of
+a `ProfileAttributes`.
+
+## When Not To Use A Domain Lens
+
+Domain lenses are easy to overuse. In general, any given client of a complicated
+class uses only a subset of that class's functionality, but that does not mean
+each client should have its own lens - that would cause a lot of extra lens
+types and tangle the code needlessly. This pattern always involves writing extra
+translation functions and adapters, so it should only be done when the decreased
+coupling is worth the extra code needed to implement the lens itself. Clients
+that don't have their own domain lens on an object can continue to use the
+object itself as usual.
+
+[TabRendererData]: ../../chrome/browser/ui/tabs/tab_renderer_data.h
+[ProfileAttributesEntry]: ../../chrome/browser/profiles/profile_attributes_entry.h
diff --git a/chromium/docs/patterns/fortesting-methods.md b/chromium/docs/patterns/fortesting-methods.md
index 49718c00b53..cad25a805be 100644
--- a/chromium/docs/patterns/fortesting-methods.md
+++ b/chromium/docs/patterns/fortesting-methods.md
@@ -25,7 +25,7 @@ functionality on.
 
 ## How to use this pattern:
 
-```
+```cpp
 class Foo {
  public:
   // ... regular public API ...
@@ -38,7 +38,7 @@ The ForTesting suffix indicates to code reviewers that the method should not be
 called in production code. There is a very similar antipattern in which the
 suffix is missing:
 
-```
+```cpp
 class Foo {
  public:
   // ... regular public API ...
diff --git a/chromium/docs/patterns/friend-the-tests.md b/chromium/docs/patterns/friend-the-tests.md
index e9310b93d47..65a49d5ae45 100644
--- a/chromium/docs/patterns/friend-the-tests.md
+++ b/chromium/docs/patterns/friend-the-tests.md
@@ -34,7 +34,7 @@ individual fields or methods.
 
 ## How to use this pattern:
 
-```
+```cpp
 class Foo {
  public:
   // ... public API ...
diff --git a/chromium/docs/patterns/inversion-of-control.md b/chromium/docs/patterns/inversion-of-control.md
new file mode 100644
index 00000000000..3ad639a6168
--- /dev/null
+++ b/chromium/docs/patterns/inversion-of-control.md
@@ -0,0 +1,404 @@
+## Inversion of Control
+
+"Inversion of control" is a design pattern used to allow users of a framework
+or library (often called clients) to customize the behavior of the framework.
+
+### Our Example
+
+Examples in this document will be given by extending or modifying this example
+API, which is hopefully self-explanatory:
+
+```cpp
+class StringKVStore {
+ public:
+  StringKVStore();
+  virtual ~StringKVStore();
+
+  using KeyPredicate = base::RepeatingCallback<bool(const string&)>;
+
+  void Put(const string& key, const string& value);
+  void Remove(const string& key);
+  void Clear();
+
+  string Get(const string& key) const;
+  set<string> GetKeys() const;
+  set<string> GetKeysMatching(const KeyPredicate& predicate) const;
+
+  void SaveToPersistentStore();
+};
+```
+
+### What is inversion of control?
+
+Normally, client code calls into the library to do operations, so control flows
+from a high-level class to a low-level class:
+
+```cpp
+void YourFunction() {
+  // GetKeys() calls into the StringKVStore library
+  for (const auto& key : kv_store_.GetKeys()) {
+    ...
+  }
+}
+```
+
+In "inverted" control flow, the library calls back into your code after you
+call into it, so control flows back from a low-level class to a high-level
+class:
+
+```cpp
+bool IsKeyInteresting(const string& key) { ... }
+
+void YourFunction() {
+  StringKVStore::KeyPredicate predicate =
+      base::BindRepeating(&IsKeyInteresting);
+  // GetKeysMatching() calls into the StringKVStore library, but it calls
+  // back into IsKeyInteresting defined in this file!
+  for (const auto& key : kv_store_.GetKeysMatching(predicate)) {
+    ...
+  }
+}
+```
+
+It is also often inverted in the Chromium dependency sense. For example, in
+Chromium, code in //content can't call, link against, or generally be aware of
+code in //chrome - the normal flow of data and control is only in one direction,
+from //chrome "down" to //content. When //content calls back into //chrome, that
+is an inversion of control.
+
+Abstractly, inversion of control is defined by a low-level class defining an
+interface that a high-level class supplies an implementation of. In the example
+fragment given above, `StringKVStore` defines an interface called
+`StringKVStore::KeyPredicate`, and `YourFunction` supplies an implementation of
+that interface - namely the bound instance of `IsKeyInteresting`. This allows
+the low-level class to use functionality of the high-level class without being
+aware of the specific high-level class's existence, or a high-level class to
+plug logic into a low-level class.
+
+There are a few main ways this is done in Chromium:
+
+* Callbacks
+* Observers
+* Listeners
+* Delegates
+
+**Inversion of control should not be your first resort. It is sometimes useful
+for solving specific problems, but in general it is overused in Chromium.**
+
+### Callbacks
+
+Callbacks are one of the simplest ways to do inversion of control, and often are
+all you need. Callbacks can be used to split out part of the framework's logic
+into the client, like so:
+
+```cpp
+void StringKVStore::GetKeysMatching(const KeyPredicate& predicate) {
+  set<string> keys;
+  for (const auto& key : internal_keys()) {
+    if (predicate.Run(key))
+      keys.insert(key);
+  }
+  return keys;
+}
+```
+
+where `predicate` was supplied by the client of
+`StringKVStore::GetKeysMatching`. They can also be used for the framework
+library to notify clients of events, like so:
+
+```cpp
+void StringKVStore::Put(const string& key, const string& value) {
+  ...
+  // In real code you would use CallbackList instead, but for explanatory
+  // purposes:
+  for (const auto& callback : key_changed_callbacks_)
+    callback.Run(...);
+}
+```
+
+making use of [Subscription].
+
+Callbacks can also be used to supply an implementation of something deliberately
+omitted, like so:
+
+```cpp
+class StringKVStore {
+  using SaveCallback = base::RepeatingCallback<void(string, string)>;
+  void SaveToPersistentStore(const SaveCallback& callback);
+};
+```
+
+### Observers
+
+An "observer" receives notifications of events happening on an object. For
+example, an interface like this might exist:
+
+```cpp
+class StringKVStore::Observer {
+ public:
+  virtual void OnKeyChanged(StringKVStore* store,
+                            const string& key,
+                            const string& from_value,
+                            const string& to_value) {}
+  virtual void OnKeyRemoved(StringKVStore* store,
+                            const string& key,
+                            const string& old_value) {}
+  ...
+}
+```
+
+and then on the StringKVStore class:
+
+```cpp
+class StringKVStore {
+ public:
+  ...
+  void AddObserver(Observer* observer);
+  void RemoveObserver(Observer* observer);
+}
+```
+
+So an example of a `StringKVStore::Observer` might be:
+
+```cpp
+class HelloKeyWatcher : public StringKVStore::Observer {
+ public:
+  void OnKeyChanged(StringKVStore* store,
+                    const string& key,
+                    const string& from_value,
+                    const string& to_value) override {
+    if (key == "hello")
+      ++hello_changes_;
+  }
+  void OnKeyRemoved(StringKVStore* store,
+                    const string& key,
+                    const string& old_value) override {
+    if (key == "hello")
+      hello_changes_ = 0;
+  }
+}
+```
+
+where the `StringKVStore` arranges to call the relevant method on each
+`StringKVStore::Observer` that has been added to it whenever a matching event
+happens.
+
+Use an observer when:
+
+* More than one client may care to listen to events happening
+* Clients passively observe, but do not modify, the state of the framework
+  object being observed
+
+### Listeners
+
+A listener is an observer that only observes a single type of event. These were
+very common in C++ and Java before the introduction of lambdas, but these days
+are not as commonly seen, and you probably should not introduce new listeners -
+instead, use a plain [Callback].
+
+Here's an example:
+
+```cpp
+class StringKVStore::ClearListener {
+ public:
+  virtual void OnCleared(StringKVStore* store) = 0;
+}
+```
+
+Use a listener when:
+
+* There is only a single client listener instance at most per framework object
+* There is only a single event being listened for
+
+### Delegates
+
+A delegate is responsible for implementing part of the framework that is
+deliberately missing. While observers and listeners are generally passive with
+respect to the framework object they are attached to, delegates are generally
+active.
+
+One very common use of delegates is to allow clients to make policy decisions,
+like so:
+
+```cpp
+class StringKVStore::Delegate {
+ public:
+  virtual bool ShouldPersistKey(StringKVStore* store, const string& key);
+  virtual bool IsValidValueForKey(StringKVStore* store,
+                                  const string& key,
+                                  const string& proposed_value);
+};
+```
+
+Another common use is to allow clients to inject their own subclasses of
+framework objects that need to be constructed by the framework, by putting
+a factory method on the delegate:
+
+```cpp
+class StringKVStore::Delegate {
+ public:
+  virtual unique_ptr<StringKVStoreBackend>
+      CreateBackend(StringKVStore* store);
+}
+```
+
+And then these might exist:
+
+```cpp
+class MemoryBackedStringKVStoreDelegate : public StringKVStore::Delegate;
+class DiskBackedStringKVStoreDelegate : public StringKVStore::Delegate;
+...
+```
+
+Use a delegate when:
+
+* There needs to be logic that happens synchronously with what's happening in
+  the framework
+* It does not make sense to have a decision made statically per instance of a
+  framework object
+
+### Observer vs Listener vs Delegate
+
+If every call to the client could be made asynchronous and the API would still
+work fine for your use case, you have an observer or listener, not a delegate.
+
+If there might be multiple interested client objects instead of one, you have an
+observer, not a listener or delegate.
+
+If any method on your interface has any return type other than `void`, you have
+a delegate, not an observer or listener.
+
+You can think of it this way: an observer or listener interface *notifies* the
+observer or listener of a change to a framework object, while a delegate usually
+helps *cause* the change to the framework object.
+
+### Callbacks vs Observers/Listeners/Delegates
+
+Callbacks have advantages:
+
+* No separate interface is needed
+* Header files for client classes are not cluttered with the interfaces or
+  methods from them
+* Client methods don't need to use specific names, so the name-collision
+  problems above aren't present
+* Client methods can be bound (using [Bind]) with any needed state, including
+  which object they are attached to, so there is no need to pass the framework
+  object of interest back into them
+* The handler for an event is placed in object setup, rather than being implicit
+  in the presence of a separate method
+* They sometimes save creation of "trampoline" methods that simply discard or
+  add extra parameters before invoking the real handling logic for an event
+* Forwarding event handlers is a lot easier, since callbacks can easily be
+  passed around by themselves
+* They avoid multiple inheritance
+
+They also have disadvantages:
+
+* They can lead to deeply-nested setup code
+* Callback objects are heavyweight (performance and memory wise) compared to
+  virtual method calls
+
+### Design Tips
+
+1. Observers should have empty method bodies in the header, rather than having
+   their methods as pure virtuals. This has two benefits: client classes can
+   implement only the methods for events they care to observe, and it is
+   obvious from the header that the base observer methods do not need to be
+   called.
+
+2. Similarly, delegates should have sensible base implementations of every
+   method whenever this is feasible, so that client classes (subclasses of the
+   delegate class) can concern themselves only with the parts that are
+   relevant to their use case.
+
+3. When inverting control, always pass the framework object of interest back to
+   the observer/listener/delegate; that allows the client, if it wants to, to
+   reuse the same object as the observer/listener/delegate for multiple
+   framework objects. For example, if ButtonListener (given above) didn't pass
+   the button in, the same ButtonListener instance could not be used to listen
+   to two buttons simultaneously, since there would be no way to tell which
+   button received the click.
+
+4. Large inversion-of-control interfaces should be split into smaller
+   interfaces when it makes sense to do so. One notorious Chromium example
+   is [WebContentsObserver], which observes dozens of different events.
+   Whenever *any* of these events happens, *every* registered
+   WebContentsObserver has to be notified, even though virtually none of them
+   might care about this specific event. Using smaller interfaces helps with
+   this problem and makes the intent of installing a specific observer clearer.
+
+5. The framework class *should not* take ownership of observers or listeners.
+   For delegates the decision is less clear, but in general, err on the side of
+   not taking ownership of delegates either. It is common to hold raw pointers
+   to observers and listeners, and raw or weak pointers to delegates, with
+   lifetime issues managed via AddObserver/RemoveObserver or the helper classes
+   discussed below.
+
+6. Depending on your application and how widely-used you expect your observer,
+   listener, or delegate to be, you should probably use names that are longer
+   and more specific than you might otherwise. This is because client classes
+   may be implementing multiple inversion-of-control interfaces, so it is
+   important that their method names not collide with each other. For example,
+   instead of having `PageObserver::OnLoadStarted`, you might have
+   `PageObserver::OnPageLoadStarted` to reduce the odds of an unpleasant
+   collision with `NetworkRequestObserver::OnLoadStarted` (or similar). Note
+   that callbacks entirely avoid this problem.
+
+7. A callback is probably a better fit for what you're trying to do than one
+   of the other patterns given above!
+
+### Inversion of Control in Chromium
+
+Some key classes in `//base`:
+
+* [ScopedObserver]
+* [ObserverList] and [CheckedObserver]
+* [Subscription] and [CallbackList]
+
+And some production examples:
+
+* [WebContentsObserver] and [WebContentsDelegate]
+* [BrowserListObserver]
+* [URLRequestJobFactory::ProtocolHandler]
+* [WidgetObserver] and [ViewObserver]
+
+### When Not To Use This Pattern
+
+Inverted control can be harder to reason about, and more expensive at runtime,
+than other approaches. In particular, beware of using delegates when static data
+would be appropriate. For example, consider this hypothetical interface:
+
+```cpp
+class StringKVStore::Delegate {
+  virtual bool ShouldSaveAtDestruction() { return true; }
+}
+```
+
+It should be clear from the naming that this method will only be called once per
+StringKVStore instance and that its value cannot meaningfully change within the
+lifetime of a given instance; in this case, "should save at destruction" should
+instead be a parameter given to StringKVStore directly.
+
+A good rule of thumb is that any method on a delegate that:
+
+* Will only be called once for a given framework object, or
+* Has a value that can't meaningfully change for a given framework object, and
+* Serves primarily to return that value, rather than doing some other work
+  like constructing a helper object
+
+should be a property on the framework object instead of a delegate method.
+
+[Bind]: ../../base/bind.h
+[BrowserListObserver]: ../../chrome/browser/ui/browser_list_observer.h
+[CallbackList]: ../../base/callback_list.h
+[Callback]: ../../base/callback.h
+[CheckedObserver]: ../../base/observer_list_types.h
+[ObserverList]: ../../base/observer_list.h
+[ScopedObserver]: ../../base/scoped_observer.h
+[Subscription]: ../../base/callback_list.h
+[URLRequestJobFactory::ProtocolHandler]: ../../net/url_request/url_request_job_factory.h
+[Unretained]: ../../base/bind.h
+[ViewObserver]: ../../ui/views/view_observer.h
+[WebContentsDelegate]: ../../content/public/browser/web_contents_delegate.h
+[WebContentsObserver]: ../../content/public/browser/web_contents_observer.h
+[WidgetObserver]: ../../ui/views/widget/widget_observer.h
diff --git a/chromium/docs/patterns/passkey.md b/chromium/docs/patterns/passkey.md
index 06ef8918a83..bb7828053c5 100644
--- a/chromium/docs/patterns/passkey.md
+++ b/chromium/docs/patterns/passkey.md
@@ -10,7 +10,7 @@ constructed by specific other classes, and requiring an instance of that passkey
 class to be passed in when calling methods you wish to restrict the use of. It
 is used like this:
 
-```
+```cpp
 class Foo {
  public:
   Foo();
diff --git a/chromium/docs/patterns/synchronous-runloop.md b/chromium/docs/patterns/synchronous-runloop.md
index adf3512d8d7..b8a4822dc09 100644
--- a/chromium/docs/patterns/synchronous-runloop.md
+++ b/chromium/docs/patterns/synchronous-runloop.md
@@ -42,10 +42,10 @@ This pattern relies on two important facts about [base::RunLoop]:
 That means that if your code does this:
 
 ```c++
-  base::RunLoop loop;
-  maybe-asynchronously { loop.Quit(); }
-  loop.Run();
-  LOG(INFO) << "Hello!";
+base::RunLoop loop;
+maybe-asynchronously { loop.Quit(); }
+loop.Run();
+LOG(INFO) << "Hello!";
 ```
 
 then regardless of whether the maybe-asynchronous `loop.Quit()` is executed
@@ -59,44 +59,44 @@ before the `Run`, the `Run` will be a no-op; if the `Quit` happens after the
 If the asynchronous thing in question takes a completion callback:
 
 ```c++
-  base::RunLoop run_loop;
-  Reply reply;
-  DoThingAndReply(
-      base::BindLambdaForTesting([&](const Reply& r) {
-          reply = r;
-          run_loop.Quit();
-      }));
-  run_loop.Run();
+base::RunLoop run_loop;
+Reply reply;
+DoThingAndReply(
+    base::BindLambdaForTesting([&](const Reply& r) {
+        reply = r;
+        run_loop.Quit();
+    }));
+run_loop.Run();
 ```
 
 or perhaps even just:
 
 ```c++
-  base::RunLoop run_loop;
-  DoThing(run_loop.QuitClosure());
-  run_loop.Run();
+base::RunLoop run_loop;
+DoThing(run_loop.QuitClosure());
+run_loop.Run();
 ```
 
 If there exists a GizmoObserver interface with an OnThingDone event:
 
 ```c++
-  class TestGizmoObserver : public GizmoObserver {
-   public:
-    TestGizmoObserver(base::RunLoop* loop, Gizmo* thing)
-        : GizmoObserver(thing), loop_(loop) {}
-
-    // GizmoObserver:
-    void OnThingStarted(Gizmo* observed_gizmo) override { ... }
-    void OnThingProgressed(Gizmo* observed_gizmo) override { ... }
-    void OnThingDone(Gizmo* observed_gizmo) override {
-      loop_->Quit();
-    }
-  };
+class TestGizmoObserver : public GizmoObserver {
+ public:
+  TestGizmoObserver(base::RunLoop* loop, Gizmo* thing)
+      : GizmoObserver(thing), loop_(loop) {}
+
+  // GizmoObserver:
+  void OnThingStarted(Gizmo* observed_gizmo) override { ... }
+  void OnThingProgressed(Gizmo* observed_gizmo) override { ... }
+  void OnThingDone(Gizmo* observed_gizmo) override {
+    loop_->Quit();
+  }
+};
 
-  base::RunLoop run_loop;
-  TestGizmoObserver observer(&run_loop, gizmo);
-  gizmo->StartDoingThing();
-  run_loop.Run();
+base::RunLoop run_loop;
+TestGizmoObserver observer(&run_loop, gizmo);
+gizmo->StartDoingThing();
+run_loop.Run();
 ```
 
 This is sometimes wrapped up into a helper class that internally constructs the
@@ -104,26 +104,26 @@ RunLoop like so, if all you need to do is wait for the event but don't care
 about observing any intermediate states too:
 
 ```c++
-  class ThingDoneWaiter : public GizmoObserver {
-   public:
-    ThingDoneWaiter(Gizmo* thing) : GizmoObserver(thing) {}
+class ThingDoneWaiter : public GizmoObserver {
+ public:
+  ThingDoneWaiter(Gizmo* thing) : GizmoObserver(thing) {}
 
-    void Wait() {
-      run_loop_.Run();
-    }
+  void Wait() {
+    run_loop_.Run();
+  }
 
-    // GizmoObserver:
-    void OnThingDone(Gizmo* observed_gizmo) {
-      run_loop_.Quit();
-    }
+  // GizmoObserver:
+  void OnThingDone(Gizmo* observed_gizmo) {
+    run_loop_.Quit();
+  }
 
-   private:
-    RunLoop run_loop_;
-  };
+ private:
+  RunLoop run_loop_;
+};
 
-  ThingDoneWaiter waiter(gizmo);
-  gizmo->StartDoingThing();
-  waiter.Wait();
+ThingDoneWaiter waiter(gizmo);
+gizmo->StartDoingThing();
+waiter.Wait();
 ```
 
 ## Events vs States
@@ -141,29 +141,29 @@ The following is an example of a Waiter helper class that waits for a state, as
 opposed to an event:
 
 ```c++
-  class GizmoReadyWaiter : public GizmoObserver {
-   public:
-    GizmoReadyObserver(Gizmo* gizmo)
-        : gizmo_(gizmo) {}
-    ~GizmoReadyObserver() override = default;
-
-    void WaitForGizmoReady() {
-      if (!gizmo_->ready()) {
-        gizmo_observer_.Add(gizmo_);
-        run_loop_.Run();
-      }
+class GizmoReadyWaiter : public GizmoObserver {
+ public:
+  GizmoReadyObserver(Gizmo* gizmo)
+      : gizmo_(gizmo) {}
+  ~GizmoReadyObserver() override = default;
+
+  void WaitForGizmoReady() {
+    if (!gizmo_->ready()) {
+      gizmo_observer_.Add(gizmo_);
+      run_loop_.Run();
     }
+  }
 
-    // GizmoObserver:
-    void OnGizmoReady(Gizmo* observed_gizmo) {
-      run_loop_.Quit();
-    }
+  // GizmoObserver:
+  void OnGizmoReady(Gizmo* observed_gizmo) {
+    run_loop_.Quit();
+  }
 
-   private:
-    RunLoop run_loop_;
-    Gizmo* gizmo_;
-    ScopedObserver<Gizmo, GizmoObserver> gizmo_observer_{this};
-  };
+ private:
+  RunLoop run_loop_;
+  Gizmo* gizmo_;
+  ScopedObserver<Gizmo, GizmoObserver> gizmo_observer_{this};
+};
 ```
 
 ## Sharp edges
@@ -173,27 +173,27 @@ opposed to an event:
 A common mis-use of this pattern is like so:
 
 ```c++
-  gizmo->StartDoingThing();
-  base::RunLoop run_loop;
-  TestGizmoObserver observer(&run_loop, gizmo);
-  run_loop.Run();
+gizmo->StartDoingThing();
+base::RunLoop run_loop;
+TestGizmoObserver observer(&run_loop, gizmo);
+run_loop.Run();
 ```
 
 This looks tempting because it seems that you can write a helper function:
 
 ```c++
-  void TerribleHorribleNoGoodVeryBadWaitForThing(Gizmo* gizmo) {
-    base::RunLoop run_loop;
-    TestGizmoObserver observer(&run_loop, gizmo);
-    run_loop.Run();
-  }
+void TerribleHorribleNoGoodVeryBadWaitForThing(Gizmo* gizmo) {
+  base::RunLoop run_loop;
+  TestGizmoObserver observer(&run_loop, gizmo);
+  run_loop.Run();
+}
 ```
 
 and then your test code can simply read:
 
 ```c++
-  gizmo->StartDoingThing();
-  TerribleHorribleNoGoodVeryBadWaitForThing(gizmo);
+gizmo->StartDoingThing();
+TerribleHorribleNoGoodVeryBadWaitForThing(gizmo);
 ```
 
 However, this is a recipe for a flaky test: if `gizmo->StartDoingThing()`
@@ -210,18 +210,18 @@ If you still really want a helper function, perhaps you just want to inline the
 start:
 
 ```c++
-  void NiceFriendlyDoThingAndWait(Gizmo* gizmo) {
-    base::RunLoop run_loop;
-    TestGizmoObserver observer(&run_loop, gizmo);
-    gizmo->StartDoingThing();
-    run_loop.Run();
-  }
+void NiceFriendlyDoThingAndWait(Gizmo* gizmo) {
+  base::RunLoop run_loop;
+  TestGizmoObserver observer(&run_loop, gizmo);
+  gizmo->StartDoingThing();
+  run_loop.Run();
+}
 ```
 
 with the test code being:
 
 ```c++
-  NiceFriendlyDoThingAndWait(gizmo);
+NiceFriendlyDoThingAndWait(gizmo);
 ```
 
 Note that this is not an issue when waiting on a *state*, since the observer can
@@ -233,17 +233,17 @@ Sometimes, there's no easy way to observe completion of an event. In that case,
 if the code under test looks like this:
 
 ```c++
-  void StartDoingThing() { PostTask(&StepOne); }
-  void StepOne() { PostTask(&StepTwo); }
-  void StepTwo() { /* done! */ }
+void StartDoingThing() { PostTask(&StepOne); }
+void StepOne() { PostTask(&StepTwo); }
+void StepTwo() { /* done! */ }
 ```
 
 it can be tempting to do:
 
 ```c++
-  gizmo->StartDoingThing();
-  base::RunLoop().RunUntilIdle();
-  /* now it's done! */
+gizmo->StartDoingThing();
+base::RunLoop().RunUntilIdle();
+/* now it's done! */
 ```
 
 However, doing this is adding dependencies to your test code on the exact async
@@ -301,43 +301,43 @@ gracefully.
 
 
 ```c++
-  class GizmoReadyWaiter : public GizmoObserver {
-   public:
-    GizmoReadyObserver(Gizmo* gizmo)
-        : gizmo_(gizmo) {}
-    ~GizmoReadyObserver() override = default;
-
-    void WaitForGizmoReady() {
-      ASSERT_TRUE(gizmo_)
-          << "Trying to call Wait() after the Gizmo was destroyed!";
-      if (!gizmo_->ready()) {
-        gizmo_observer_.Add(gizmo_);
-        run_loop_.Run();
-      }
+class GizmoReadyWaiter : public GizmoObserver {
+ public:
+  GizmoReadyObserver(Gizmo* gizmo)
+      : gizmo_(gizmo) {}
+  ~GizmoReadyObserver() override = default;
+
+  void WaitForGizmoReady() {
+    ASSERT_TRUE(gizmo_)
+        << "Trying to call Wait() after the Gizmo was destroyed!";
+    if (!gizmo_->ready()) {
+      gizmo_observer_.Add(gizmo_);
+      run_loop_.Run();
     }
+  }
 
-    // GizmoObserver:
-    void OnGizmoReady(Gizmo* observed_gizmo) {
-      gizmo_observer_.Remove(observed_gizmo);
-      run_loop_.Quit();
-    }
-    void OnGizmoDestroying(Gizmo* observed_gizmo) {
-      DCHECK_EQ(gizmo_, observed_gizmo);
-      gizmo_ = nullptr;
-      // Remove the observer now, to avoid a UAF in the destructor.
-      gizmo_observer_.Remove(observed_gizmo);
-      // Bail out so we don't time out in the test waiting for a ready state
-      // that will never come.
-      run_loop_.Quit();
-      // Was this a possible expected outcome? If not, consider:
-      // ADD_FAILURE() << "The Gizmo was destroyed before it was ready!";
-    }
+  // GizmoObserver:
+  void OnGizmoReady(Gizmo* observed_gizmo) {
+    gizmo_observer_.Remove(observed_gizmo);
+    run_loop_.Quit();
+  }
+  void OnGizmoDestroying(Gizmo* observed_gizmo) {
+    DCHECK_EQ(gizmo_, observed_gizmo);
+    gizmo_ = nullptr;
+    // Remove the observer now, to avoid a UAF in the destructor.
+    gizmo_observer_.Remove(observed_gizmo);
+    // Bail out so we don't time out in the test waiting for a ready state
+    // that will never come.
+    run_loop_.Quit();
+    // Was this a possible expected outcome? If not, consider:
+    // ADD_FAILURE() << "The Gizmo was destroyed before it was ready!";
+  }
 
-   private:
-    RunLoop run_loop_;
-    Gizmo* gizmo_;
-    ScopedObserver<Gizmo, GizmoObserver> gizmo_observer_{this};
-  };
+ private:
+  RunLoop run_loop_;
+  Gizmo* gizmo_;
+  ScopedObserver<Gizmo, GizmoObserver> gizmo_observer_{this};
+};
 ```
 
 [base::RunLoop]: ../../base/run_loop.h
diff --git a/chromium/docs/patterns/testapi.md b/chromium/docs/patterns/testapi.md
index 3367764a3cd..8afe1463538 100644
--- a/chromium/docs/patterns/testapi.md
+++ b/chromium/docs/patterns/testapi.md
@@ -23,8 +23,7 @@ you want to be confident that this test functionality is not used outside tests.
 ## How to use this pattern:
 
 `//foo/commonly_used.h`:
-```
-
+```cpp
 class CommonlyUsed {
  public:
   // ... big public API ...
@@ -38,7 +37,7 @@ class CommonlyUsed {
 ```
 
 `//foo/commonly_used_test_api.h`:
-```
+```cpp
 class CommonlyUsedTestApi {
  public:
   CommonlyUsedTestApi(CommonlyUsed* thing);
@@ -53,8 +52,8 @@ class CommonlyUsedTestApi {
 ```
 
 And then client code can do:
-```
-  CommonlyUsedTestApi(commonly_used).DoTestStuff(...);
+```cpp
+CommonlyUsedTestApi(commonly_used).DoTestStuff(...);
 ```
 
 Then only link `commonly_used_test_api.{cc,h}` in test targets, so these methods
diff --git a/chromium/docs/pgo.md b/chromium/docs/pgo.md
new file mode 100644
index 00000000000..a7eef3f9aca
--- /dev/null
+++ b/chromium/docs/pgo.md
@@ -0,0 +1,40 @@
+# Generating PGO Profiles
+
+Normally devs don't need to worry about this and can use the default profile
+for official builds.  The default profile can be fetched by adding
+`"checkout_pgo_profiles": True` to `custom_vars` in the gclient config and
+running `gclient runhooks`.
+
+To produce an executable built with a custom PGO profile:
+
+* Produce the instrumented executable using the following gn args:
+
+  ```
+  chrome_pgo_phase = 1
+  enable_resource_allowlist_generation = false
+  is_official_build = true
+  symbol_level = 0
+  use_goma = true
+  ```
+
+* Run representative benchmarks to produce profiles
+
+  * `vpython tools/perf/run_benchmark system_health.common_desktop --assert-gpu-compositing --run-abridged-story-set --browser=exact --browser-executable=out/path/to/chrome`
+  * `vpython tools/perf/run_benchmark speedometer2 --assert-gpu-compositing --browser=exact --browser-executable=out/path/to/chrome`
+  * `vpython tools/perf/run_benchmark webrtc --assert-gpu-compositing --browser=exact --browser-executable=out/path/to/chrome`
+  * This will produce `*.profraw` files in the current working directory
+
+* Merge the profiling data
+
+  * Get the `llvm-profdata` tool by adding `"checkout_clang_coverage_tools": True,` to `custom_vars` in the gclient config and running `gclient runhooks`.
+  * Run `third_party/llvm-build/Release+Asserts/bin/llvm-profdata merge *.profraw -o chrome.profdata`
+
+* Produce the final PGO'd executable with the following gn args:
+
+  ```
+  enable_resource_allowlist_generation = false
+  is_official_build = true
+  symbol_level = 0
+  use_goma = true
+  pgo_data_path = {path-to-the-profile}
+  ```
diff --git a/chromium/docs/privacy/DIR_METADATA b/chromium/docs/privacy/DIR_METADATA
new file mode 100644
index 00000000000..10d12ab8b35
--- /dev/null
+++ b/chromium/docs/privacy/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Privacy"
+}
\ No newline at end of file
diff --git a/chromium/docs/privacy/OWNERS b/chromium/docs/privacy/OWNERS
index 0eeaf5c3d84..00060a9665a 100644
--- a/chromium/docs/privacy/OWNERS
+++ b/chromium/docs/privacy/OWNERS
@@ -4,5 +4,4 @@ mgalonsky@chromium.org
 mkwst@chromium.org
 msramek@chromium.org
 rhalavati@chromium.org
-tnagel@chromium.org
-# COMPONENT: Privacy
+tnagel@chromium.org
\ No newline at end of file
diff --git a/chromium/docs/privacy_budget/DIR_METADATA b/chromium/docs/privacy_budget/DIR_METADATA
new file mode 100644
index 00000000000..4b9931a7932
--- /dev/null
+++ b/chromium/docs/privacy_budget/DIR_METADATA
@@ -0,0 +1,12 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Privacy>Fingerprinting"
+}
+team_email: "privacy-sandbox-dev@chromium.org"
\ No newline at end of file
diff --git a/chromium/docs/privacy_budget/OWNERS b/chromium/docs/privacy_budget/OWNERS
index cfc756a1170..dc548692bc4 100644
--- a/chromium/docs/privacy_budget/OWNERS
+++ b/chromium/docs/privacy_budget/OWNERS
@@ -1,4 +1 @@
 file://third_party/blink/public/common/privacy_budget/OWNERS
-
-# TEAM: privacy-sandbox-dev@chromium.org
-# COMPONENT: Privacy>Fingerprinting
diff --git a/chromium/docs/privacy_budget/good_identifiable_surface.md b/chromium/docs/privacy_budget/good_identifiable_surface.md
new file mode 100644
index 00000000000..5210d3d14db
--- /dev/null
+++ b/chromium/docs/privacy_budget/good_identifiable_surface.md
@@ -0,0 +1,286 @@
+# What's a Good Candidate For an IdentifiableSurface? {#good-surface}
+
+Once you have a source of potentially identifying information picked out, you
+need to determine how to represent the surface using
+[`blink::IdentifiableSurface`].
+
+The first step would be to determine what the surface *is* in the first place.
+
+_If the surface were to be presented as a question that the document asks
+a user-agent, what details should the question include in order for the answer
+to be identifiable across a wide range of user-agents?_
+
+Sometimes the question is straightforward. E.g. [`window.screenTop`] pretty much
+captures the entire question. But it can get tricky as we'll see in the
+examples below.
+
+All the pieces of information that the document needs to present to the
+user-agent in order to ask the identifiable question should be represented in
+the [`blink::IdentifiableSurface`].
+
+There are two broad categories of identifiable surfaces:
+
+*  **Direct Surfaces**: Surfaces accessible via looking up an attribute or
+   invoking a parameter-less operation of a global singleton object.
+
+   *Global singleton objects* refer to an object which is effectively the only
+   instance of its interface in a single execution context. If one were to
+   start from the global object and follow a chain of attributes or
+   parameter-less methods, all objects encountered along the way are global
+   singleton objects. One could pluck the attribute or operation out of the
+   last interface and stick it in the global object and there would be no
+   semantic difference.
+
+   In our `window.screenTop` example the global object exposes the `Window`
+   interface. `Window.window` or just `window` is a reference back to this
+   global object. The `Window` interface exposes the `screenTop` attribute. So
+   `window.screenTop` is an expression that looks up an attribute of the global
+   object.
+
+   By convention direct surfaces are represented using their corresponding
+   [`blink::WebFeature`]. All APIs that are direct identifiable surfaces should
+   have corresponding [Use Counters] and hence corresponding `WebFeature`
+   values.
+
+   For `window.screenTop`, the resulting `IdentifiableSurface` constructor
+   would look like this:
+
+   ```cpp
+   IdentifiableSurface::FromTypeAndToken(
+       Type::kWebFeature,                  // All direct surfaces use this type.
+       WebFeature::WindowScreenTop)
+   ```
+
+   See [Instrumenting Direct Surfaces] for details on how to instrument
+   these surfaces.
+
+2. **Indirect Surfaces**. A.k.a. everything else.
+
+   [`HTMLMediaElement.canPlayType()`] takes a string indicating a MIME type and
+   returns a vague indication of whether that media type is supported (its
+   return values are one of `"probably"`, `"maybe"`, or `""`). So the question
+   necessarily must include the MIME type.
+
+   Hence the `IdentifiableSurface` constructor could look like this:
+
+   ```cpp
+   IdentifiableSurface::FromTypeAndToken(
+       Type::kHTMLMediaElement_CanPlayType,
+       IdentifiabilityBenignStringToken(mime_type))
+   ```
+
+   The [`blink::IdentifiableSurface`] includes:
+   * That it represents an `HTMLMediaElement.canPlayType()` invocation.
+     `Type::kHTMLMediaElement_CanPlayType` is a bespoke enum value that was
+     introduced for this specific surface. See [Adding a Surface Type]
+     for details on how to add a surface type.
+   * The parameter that was passed to the operation.
+
+   `IdentifiabilityBenignStringToken` is a helper function that calculates
+   a digest of a "benign" string. See [Instrumentation] for more details on how
+   to represent operation arguments.
+
+The distinction between a direct surface and an indirect surface can sometimes
+be fuzzy. But it's always based on what's known _a priori_ and what's practical
+to measure. A `canPlayType("audio/ogg; codecs=vorbis")` query could just as
+easily be represented as a `WebFeature` like
+`MediaElementCanPlayType_Audio_Ogg_Codecs_Vorbis`. But
+
+* [This doesn't scale].
+* The set of MIME types can be pretty large and changing.
+* It's not possible to hardcode all possible values at coding time.
+* Most of the values will be irrelevant to identifiability, but we don't know which ones.
+
+All things considered, deriving a digest for the argument is much more
+practical than alternatives.
+
+### Example: NetworkInformation.saveData {#eg-net-effective-type}
+
+The following expression yields whether the user-agent is operating under
+a reduce data usage constraint (See [`NetworkInformation.saveData`]):
+
+```js
+navigator.connection.saveData
+```
+
+This is a [direct surface]. As such constructing a `IdentifableSurface` only
+requires knowing the interface and name of the final attribute or operation in
+the expression.
+
+Hence the `IdentifiableSurface` is of type `kWebFeature` with a web feature
+named `NetInfoEffectiveType` (which was a pre-existing [Use Counter][Use
+counters]). I.e.:
+
+```cpp
+IdentifiableSurface::FromTypeAndToken(
+    Type::kWebFeature,
+    WebFeature::NetInfoEffectiveType)
+```
+
+### Example: Media Capabilities {#eg-media-capabilities}
+
+The [Media Capabilities API] helps determine whether some media type is
+supported. E.g.:
+
+```js
+await navigator.mediaCapabilities.decodingInfo({
+  type: "file",
+  audio: { contentType: "audio/mp3" }
+});
+```
+
+In this case the script is specifying a [`MediaDecodingConfiguration`]
+dictionary. The [`MediaCapabilitiesInfo`] object returned by [`decodingInfo()`]
+depends on the input. Hence we have to capture the input in the
+`IdentifiableSurface` as follows:
+
+```cpp
+IdentifiableSurface::FromTypeAndToken(
+    Type::kHTMLMediaElement_CanPlayType,
+    IdentifiabilityBenignStringToken(mime_type))
+```
+
+See [Instrumentation] for more details on how to represent operation arguments
+and caveats around encoding strings.
+
+### Example: Media Streams API {#eg-media-streams}
+
+Another more complicated example is this use of the [Media Streams API].
+
+```js
+var mediaStream = await navigator.mediaDevices.getUserMedia({video: {
+  height: 240,
+  width: 320
+}});
+
+var firstAudioTrack = mediaStream.getAudioTracks()[0];
+
+var capabilities = firstAudioTrack.getCapabilities();
+```
+
+The target identifiable surface is the value of `capabilities`.
+
+An important consideration here is that [`MediaDevices.getUserMedia`] operation
+involves user interaction.
+
+In theory, if the `getUserMedia` operation is successful, the
+`IdentifiableSurface` for `capabilities` should represent the artifacts
+(starting with the last global singleton object):
+
+1. The operation [`MediaDevices.getUserMedia`].
+
+1. A [`MediaStreamConstraints`] dictionary with value
+   `{video: {height: 240, width: 320}}`.
+
+1. The user action.
+
+1. The operation [`MediaStream.getAudioTracks`] -- which is invoked on the
+   result of the prior step assuming the operation succeeded.
+
+1. `[0]`^th^ index -- applied to the list of [`MediaStreamTrack`]s resulting from
+   the previous step
+
+   > The Media Streams API does not specify the order of tracks. In general
+   > where a spec doesn't state the ordering of a sequence, the ordering itself
+   > can be a tracking concern. However in this case the implementation yields
+   > at most one audio track after a successful `getUserMedia` invocation.
+   > Hence there's no ordering concern here at least in Chromium.
+
+1. The operation [`MediaStreamTrack.getCapabilities`] -- which is invoked on
+   the result of the prior step.
+
+However,
+
+* The user action is not observable by the document. The only outcome exposed
+  to the document is whether `getUserMedia()` returned a `MediaStream` or if
+  the request was rejected due to some reason.
+
+  It's not necessary to go beyond what the document can observe.
+
+* If the call is successful the initial state of the resulting `MediaStream`
+  determines the stable properties that a document can observe.
+
+  The remaining accessors (e.g. `getAudioTracks()`, `getVideoTracks()` etc...)
+  deterministically depend on the returned `MediaStream` with the exception of
+  the indexing in step 5 which can be non-deterministic if there is more than
+  one audio track.
+
+  The diversity of document exposed state past step 3 is a subset of the
+  diversity of the initial `MediaStream` object.
+
+* If the call is rejected due to the request being over-constrained, then the
+  exception could indicate limitations of the underlying devices.
+
+Considering the above, we can tease apart multiple identifiable surfaces:
+
+1. **VALID** The mapping from &lt;`"MediaDevices.getUserMedia"` operation,
+   `MediaStreamConstraints` instance&gt; to &lt;`Exception` instance&gt; when
+   the call rejects prior to any user interaction.
+
+1. **OUT OF SCOPE** The mapping from &lt;`"MediaDevices.getUserMedia"`
+   operation, `MediaStreamConstraints` instance&gt; to &lt;time elapsed&gt; when
+   the call resolves.
+
+   Timing vectors like this are outside the scope of the initial study.
+
+1. **INFEASIBLE** The mapping from &lt;`"MediaDevices.getUserMedia"` operation,
+   &lt;`MediaStreamConstraints` instance, (user action)&gt; to
+   &lt;`MediaStream` instance&gt;.
+
+   As mentioned earlier the user action is not exposed to the document. Hence
+   we end up with an incomplete metric where the key doesn't have sufficient
+   diversity to account for the outcomes.
+
+1. **INFEASIBLE** The mapping from &lt;`"MediaDevices.getUserMedia"` operation,
+   `MediaStreamConstraints` instance, (user action)&gt; to &lt;`Exception`
+   instance&gt;.
+
+   Same problem as above.
+
+1. **VALID** The mapping from &lt;`MediaStreamTrack` instance&gt; to
+   &lt;`MediaTrackCapabilities` instance&gt;.
+
+   We can reason that this mapping is going to be surjective. The diversity of
+   &lt;`MediaTrackCapabilities` instance&gt; is not going to add information.
+
+   For simplicity surjective mappings can be collapsed into a single point
+   without losing information. Thus the mapping here is just &lt;`MediaStream`
+   instance&gt; to &lt;`1`&gt; where the value is arbitrary and doesn't matter.
+
+1. **VALID** The mapping from &lt;`MediaStreamTrack.label` string&gt; to
+   &lt;`MediaTrackCapabilities` instance&gt;.
+
+   The label is a string like "Internal microphone" which can be presented to
+   the user and assumed to be discerning enough that the user will find the
+   string sufficient to identify the correct device.
+
+The metrics we can derive from this surface are marked as **VALID**.
+
+Constructing a digest out of any of the dictionary instances also requires some
+care. Only include properties of each object that are expected to persist
+across browsing contexts. For example, any identifier that is origin-local,
+document-local, or depends on input from the document is not a good candidate.
+
+<!-- sort, case insensitive -->
+[`blink::IdentifiableSurface`]: ../../third_party/blink/public/common/privacy_budget/identifiable_surface.h
+[`blink::WebFeature`]: ../../third_party/blink/public/mojom/web_feature/web_feature.mojom
+[`decodingInfo()`]: https://www.w3.org/TR/media-capabilities/#dom-mediacapabilities-decodinginfo
+[`HTMLMediaElement.canPlayType()`]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType
+[`MediaCapabilitiesInfo`]: https://www.w3.org/TR/media-capabilities/#dictdef-mediacapabilitiesinfo
+[`MediaDecodingConfiguration`]: https://developer.mozilla.org/en-US/docs/Web/API/MediaDecodingConfiguration
+[`MediaDevices.getUserMedia`]: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia
+[`MediaStream.getAudioTracks`]: https://developer.mozilla.org/en-US/docs/Web/API/MediaStream/getAudioTracks
+[`MediaStream`]: https://developer.mozilla.org/en-US/docs/Web/API/MediaStream
+[`MediaStreamConstraints`]: https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackConstraints
+[`MediaStreamTrack.getCapabilities`]: https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/getCapabilities
+[`MediaStreamTrack`]: https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack
+[`NetworkInformation.saveData`]: https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation/saveData
+[`window.screenTop`]: https://developer.mozilla.org/en-US/docs/Web/API/Window/screenTop
+[Adding a Surface Type]: privacy_budget_instrumentation.md#adding-a-surface-type
+[direct surface]: privacy_budget_glossary.md#directsurface
+[Instrumentation]: privacy_budget_instrumentation.md
+[Instrumenting Direct Surfaces]: privacy_budget_instrumentation.md#annotating-direct-surfaces
+[Media Capabilities API]: https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API
+[Media Streams API]: https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API
+[this doesn't scale]: https://thecooperreview.com/10-tricks-appear-smart-meetings/
+[Use Counters]: ../use_counter_wiki.md
diff --git a/chromium/docs/privacy_budget/privacy_budget_instrumentation.md b/chromium/docs/privacy_budget/privacy_budget_instrumentation.md
index 54ddc90c11d..af7f28b1bbb 100644
--- a/chromium/docs/privacy_budget/privacy_budget_instrumentation.md
+++ b/chromium/docs/privacy_budget/privacy_budget_instrumentation.md
@@ -17,10 +17,10 @@ Follow the instructions below for adding instrumentation for an API.
 1. Determine the `UkmSourceId` and `UkmRecorder` to use for reporting, which
    depends on what you have. See the table below:
 
-   |You have this              |Use this                                                                 |
-   |---------------------------|-------------------------------------------------------------------------|
-   |[`blink::Document`]        |`Document::UkmRecorder()` and `Document::UkmSourceID()`                  |
-   |[`blink::ExecutionContext`]|`ExecutionContext::UkmRecorder()` and `ExecutionContext::UkmSourceID()`  |
+   | You have this              | Use this                                                                |
+   |----------------------------|-------------------------------------------------------------------------|
+   |[`blink::Document`]         |`Document::UkmRecorder()` and `Document::UkmSourceID()`                  |
+   |[`blink::ExecutionContext`] |`ExecutionContext::UkmRecorder()` and `ExecutionContext::UkmSourceID()`  |
 
    Several classes inherit `blink::ExecutionContext` and therefore implement
    `UkmRecorder()` and `UkmSourceID()` methods. E.g.:
@@ -38,12 +38,12 @@ Follow the instructions below for adding instrumentation for an API.
    source ID can be mapped to a top level navigation.
 
 1. Decide on the [`blink::IdentifiableSurface`] to use, and the method for
-   constructing it. If there's no corresponding surface type, see the [Surface
-   Types](#surface-types) section for instructions on adding a new type.
+   constructing it. If there's no corresponding surface type, see the
+   [Surface Types](#surface-types) section for instructions on adding a new type.
 
    *** note
-   When constructing the [`blink::IdentifiableSurface`] instance, prefer
-   `FromTypeAndToken` instead of `FromTypeFromInput`.
+   What's a good candidate for [`blink::IdentifiableSurface`]?
+   See [What's a good candidate for IdentifiableSurface?] below.
    ***
 
 1. Condition all additional work on whether the study is active and whether the
@@ -236,7 +236,7 @@ belong to two different types. I.e. two different
 [`blink::IdentifiableSurface::Type`]`s`. If a matching type doesn't exist,
 you'll need to add one. See the next section for how to do that.
 
-### Adding a Surface Type
+### Adding a Surface Type {#adding-a-surface-type}
 
 All surface types and their parameters must be documented in
 [`identifiable_surface.h`]. When adding a new type, you should document:
@@ -291,8 +291,6 @@ Here's a sample CL that shows what needs to be done:
   * http://crrev.com/c/2351957: Adds IDL based instrumentation for
     `Screen.internal` and `Screen.primary`.
 
-TODO(dylancutler@google.com): Add examples of adding support for new V8 types.
-
 Don't add custom `UseCounter` enums and instead rely on the generated
 `UseCounter` name whenever possible.
 
@@ -327,7 +325,7 @@ detail that doesn't belong in the IDL. It also adds unnecessary noise.
 
 *** note
 **IMPORTANT** Make sure that each API has its own `UseCounter` name. Otherwise
-multiple APIs will have their samples accumulate within the same bucket. This
+multiple APIs will have their samples aggregated within the same bucket. This
 alters the observed characteristics of the API from what it really is.
 ***
 
@@ -337,12 +335,15 @@ alters the observed characteristics of the API from what it really is.
 [`blink::IdentifiabilityStudySettings`]: ../../third_party/blink/public/common/privacy_budget/identifiability_study_settings.h
 [`blink::IdentifiableSurface::Type`]: ../../third_party/blink/public/common/privacy_budget/identifiable_surface.h
 [`blink::IdentifiableSurface`]: ../../third_party/blink/public/common/privacy_budget/identifiable_surface.h
+[`blink::WebFeature`]: ../../third_party/blink/public/mojom/web_feature/web_feature.mojom
+[`HighEntropy`]: ../../third_party/blink/renderer/bindings/IDLExtendedAttributes.md#HighEntropy_m_a_c
 [`identifiability_digest_helpers.h`]: ../../third_party/blink/renderer/platform/privacy_budget/identifiability_digest_helpers.h
 [`identifiable_surface.h`]: ../../third_party/blink/public/common/privacy_budget/identifiable_surface.h
 [`identifiable_token.h`]: ../../third_party/blink/public/common/privacy_budget/identifiable_token.h
+[`Measure`]: ../../third_party/blink/renderer/bindings/IDLExtendedAttributes.md#Measure_i_m_a_c
 [`Plugin`]: ../../third_party/blink/renderer/modules/plugins/plugin.idl
 [`Screen`]: ../../third_party/blink/renderer/core/frame/screen.idl
 [direct surface]: privacy_budget_glossary.md#directsurface
+[Use Counter]: ../use_counter_wiki.md
 [volatile surface]: privacy_budget_glossary.md#volatilesurface
-[`HighEntropy`]: ../../third_party/blink/renderer/bindings/IDLExtendedAttributes.md#HighEntropy_m_a_c
-[`Measure`]: ../../third_party/blink/renderer/bindings/IDLExtendedAttributes.md#Measure_i_m_a_c
+[What's a good candidate for IdentifiableSurface?]: good_identifiable_surface.md
diff --git a/chromium/docs/security/DIR_METADATA b/chromium/docs/security/DIR_METADATA
new file mode 100644
index 00000000000..907d38f0b47
--- /dev/null
+++ b/chromium/docs/security/DIR_METADATA
@@ -0,0 +1,12 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Security"
+}
+team_email: "security-dev@chromium.org"
\ No newline at end of file
diff --git a/chromium/docs/security/OWNERS b/chromium/docs/security/OWNERS
index 1ea372401d2..a8623751d4e 100644
--- a/chromium/docs/security/OWNERS
+++ b/chromium/docs/security/OWNERS
@@ -11,6 +11,4 @@ palmer@chromium.org
 parisa@chromium.org
 rsesek@chromium.org
 tsepez@chromium.org
-vakh@chromium.org
-# COMPONENT: Security
-# TEAM: security-dev@chromium.org
+vakh@chromium.org
\ No newline at end of file
diff --git a/chromium/docs/security/lookalikes/interstitial.png b/chromium/docs/security/lookalikes/interstitial.png
new file mode 100644
index 00000000000..ce67fe4ad71
--- /dev/null
+++ b/chromium/docs/security/lookalikes/interstitial.png
diff --git a/chromium/docs/security/lookalikes/lookalike-domains.md b/chromium/docs/security/lookalikes/lookalike-domains.md
new file mode 100644
index 00000000000..569fa18c7f4
--- /dev/null
+++ b/chromium/docs/security/lookalikes/lookalike-domains.md
@@ -0,0 +1,86 @@
+# "Lookalike" Warnings in Google Chrome
+
+"Lookalike" domains are domains that are crafted to impersonate the URLs of
+other sites in order to trick users into believing they're on a different site.
+These domains are used in social engineering attacks, from phishing to retail
+fraud.
+
+In addition to [Google Safe Browsing](https://safebrowsing.google.com/)
+protections, Chrome attempts to detect these lookalike domains using a number of
+on-device heuristics. These heuristics compare the visited URL against domains
+that the user has visited previously and other popular domains.
+
+When Chrome detects a potential lookalike domain, it may block the page and show
+a full-page warning, or it may show a warning overlay, depending on how certain
+Chrome is that the site is a spoof. These warnings typically have a "Did you
+mean ...?" message.
+
+| High-confidence warnings               | Low-confidence warning        |
+|:--------------------------------------:|:-----------------------------:|
+| ![Interstitial page](interstitial.png) | ![Safety Tip bubble](tip.png) |
+
+## Examples of lookalike domains
+
+Chrome's heuristics are designed to detect spoofing techniques in the wild. Some
+example "lookalike" patterns include:
+
+ * Domains that are a small edit-distance away from other domains, such as
+   `goog0le.com`.
+ * Domains that embed other domain names within their own hostname, such as
+   `google.com.example.com`.
+ * Domains that use IDN
+   [homographs](https://chromium.googlesource.com/chromium/src/+/master/docs/idn.md),
+   such as `goögle.com`.
+
+This list is not exhaustive, and developers are encouraged to avoid using
+domains that users without technical backgrounds may confuse for another site.
+
+
+## Heuristics are imperfect
+
+Like all heuristics, Chrome's heuristics are not always right. For instance,
+attackers can choose lookalike domains that Chrome is unable to detect. Our
+intent with Chrome's lookalike heuristics is not to make spoofing impossible,
+but to force attackers to use less convincing lookalikes, allowing users to
+notice spoofs more easily.
+
+In addition to not catching all spoofs, Chrome's heuristics also label some
+benign pages as lookalikes. We have several approaches to minimize these
+mistakes:
+
+ * Heuristics are tuned to minimize warnings on legitimate pages.
+ * Users are never prohibited from visiting the site requested, and the warnings
+   shown are designed to be helpful and informative, rather than scary.
+ * We monitor what sites trigger the most warnings on a regular basis, and
+   disable warnings on identified false positives.
+ * For domains used internally, we provide an [Enterprise
+   Policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=LookalikeWarningAllowlistDomains)
+   allowing businesses to selectively disable these warnings as needed for their
+   users.
+ * For several months following the roll-out of new heuristics, we accept
+   appeals from site operators whose sites have been incorrectly flagged.
+ * Heuristics launching in M88 or later will trigger a console message informing
+   site owners of the issue for at least one release prior to triggering
+   user-visible warnings.
+
+
+## Appealing a Lookalike Warning
+
+If you operate a site that erroneously triggers lookalike warnings in Chrome,
+you can ask for a manual appeal. These appeals are evaluated manually, and we
+can suppress the warning for all Chrome users when necessary.
+
+In the case of compelling spoofs, we may ask you to demonstrate that you not
+only own the site on which the warning is shown, but the site that Chrome
+believes that your site is spoofing. We may also decline to suppress the warning
+if the domain is only used internally (i.e. no external users are impacted).
+
+Appeals for domains triggered by a given heuristic are generally considered for
+the 6 months following the release of that heuristic. These six months are
+designed to allow Chrome to detect most existing sites that trigger the
+heuristic erroneously. After that time, we encourage developers to test their
+new sites in Chrome to ensure that their new domain does not trigger warnings.
+
+If you are a site operator and would like to request an appeal, please fill out
+a
+[request](https://bugs.chromium.org/p/chromium/issues/entry?template=Safety+Tips+Appeals).
diff --git a/chromium/docs/security/lookalikes/tip.png b/chromium/docs/security/lookalikes/tip.png
new file mode 100644
index 00000000000..4295b896f25
--- /dev/null
+++ b/chromium/docs/security/lookalikes/tip.png
diff --git a/chromium/docs/security/mojo.md b/chromium/docs/security/mojo.md
index fd1d2237296..51d325ce1f6 100644
--- a/chromium/docs/security/mojo.md
+++ b/chromium/docs/security/mojo.md
@@ -64,8 +64,9 @@ interface Teleporter {
   TeleportGoat(Goat) = ();
   TeleportPlant(Plant) => ();
 
-  // TeleportStats is only non-null if success is true.
-  GetStats() => (bool success, TeleporterStats?);
+  // TeleporterStats will be have a value if and only if the call was
+  // successful.
+  GetStats() => (TeleporterStats?);
 };
 ```
 
@@ -78,7 +79,7 @@ interface Teleporter {
   // supposed to only pass one non-null argument per call?
   Teleport(Animal?, Fungi?, Goat?, Plant?) => ();
 
-  // Does this return all stats if sucess is true? Or just the categories that
+  // Does this return all stats if success is true? Or just the categories that
   // the teleporter already has stats for? The intent is uncertain, so wrapping
   // the disparate values into a result struct would be cleaner.
   GetStats() =>
@@ -114,11 +115,9 @@ interface Teleporter {
   TeleportGoat(Goat) => ();
   TeleportPlant(Plant) => ();
 
-  // Returns current teleportation stats. On failure (e.g. a teleportation
-  // operation is currently in progress) success will be false and a null stats
-  // object will be returned.
-  GetStats() =>
-      (bool success, TeleportationStats?);
+  // Returns current teleporter stats. On failure (e.g. a teleportation
+  // operation is currently in progress) a null stats object will be returned.
+  GetStats() => (TeleporterStats?);
 };
 ```
 
diff --git a/chromium/docs/security/rule-of-2.md b/chromium/docs/security/rule-of-2.md
index c5253352940..9f68cbe1a01 100644
--- a/chromium/docs/security/rule-of-2.md
+++ b/chromium/docs/security/rule-of-2.md
@@ -219,6 +219,14 @@ Ultimately this process results in parsing significantly simpler grammars. (PNG
 > language and still have such high performance, that'd be ideal. But that's
 > unlikely to happen soon.)
 
+While less preferable to Mojo, we also similarly trust Protobuf for
+deserializing messages at high privilege from potentially untrustworthy senders.
+For example, Protobufs are sometimes embedded in Mojo IPC messages. It is
+always preferable to use a Mojo message where possible, though sometimes
+external constraints require the use of Protobuf. Note that this only applies to
+Protobuf as a container format; the data contained within a Protobuf must be
+handled according to this rule as well.
+
 ### Safe Languages
 
 Where possible, it's great to use a memory-safe language. Of the currently
@@ -238,6 +246,14 @@ formats can be a great approach. We do a similar thing with the pure-Java
 to 'vet' incoming JSON in a memory-safe way before passing the input to the C++
 JSON implementation.
 
+On Android, many system APIs that are exposed via Java are not actually
+implemented in a safe language, and are instead just facades around an unsafe
+implementation. A canonical example of this is the
+[BitmapFactory](https://developer.android.com/reference/android/graphics/BitmapFactory)
+class, which is a Java wrapper [around C++
+Skia](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/libs/hwui/jni/BitmapFactory.cpp;l=586;drc=864d304156d1ef8985ee39c3c1858349b133b365).
+These APIs are therefore not considered memory-safe under the rule.
+
 ## Existing Code That Violates The Rule
 
 We still have a lot of code that violates this rule. For example, until very
diff --git a/chromium/docs/security/security-labels.md b/chromium/docs/security/security-labels.md
index 97b6d66fe38..45e24a378a8 100644
--- a/chromium/docs/security/security-labels.md
+++ b/chromium/docs/security/security-labels.md
@@ -33,22 +33,8 @@ that.)
 * **Security_Impact-**{**Head**, **Beta**, **Stable**, **None**}: Designates
 which branch(es) were impacted by the bug. Only apply the label corresponding
 with the earliest affected branch. **None** means that a security bug is in a
-disabled feature, or otherwise doesn't impact Chrome. A disabled feature does
-not _guarantee_ impact **None**:
-    * The feature really must be disabled on 100% of devices. Specifically,
-      if the feature is controlled by field trials or some other network
-      configuration service, the feature must also be disabled by default in
-      the code, such that the code is inactive even on devices that can't
-      access the network configuration service.
-    * The feature control check must be somewhere that the attacker could not
-      have influenced. For example a privilege escalation from a lower-
-      privileged process to a higher-privileged process assumes that the lower-
-      privileged process is already compromised. The attacker could overwrite
-      memory for any feature checks performed within that lower-privileged
-      process; the bug only qualifies as impact **None** if checks are
-      performed in the higher-privileged process. (For example, in a
-      privilege escalation from the renderer to the browser process, the
-      checks would need to be in the browser process.)
+disabled feature, or otherwise doesn't impact Chrome: see the section below
+for more detail.
     * Note that **Security_Severity** should still be set on
       **Security_Impact-None** issues, as if the feature were enabled or the
       code reachable.
@@ -77,7 +63,7 @@ guidelines are as follows:
     decisions made externally, such as:
       * We receive advance notice of security bugs from an upstream open source
         project or Google partner and they organize a coordinated disclosure
-        process. We'd remove the restriction label if/when the embarge gets
+        process. We'd remove the restriction label if/when the embargo gets
         lifted.
       * The reporter indicates a preference to remain anonymous an the bug
         history would give away the reporter's identity (if they file using an
@@ -116,6 +102,47 @@ appropriate bug(s) with the label for easy searching.
 **Security_Impact**, **OS**, **Pri**, **M**, **Component**, and an
 **owner** set.
 
+### When to use Security_Impact-None {#TOC-Security_Impact-None}
+
+**Security_Impact-None** says that the bug can't affect any users running the
+default configuration of Chrome. It's most commonly used for cases where
+code is entirely disabled or absent in the production build.
+
+Other cases where it's OK to set **Security_Impact-None**:
+
+* The impacted code runs behind a feature flag which is *disabled by default*,
+  and the field trial configuration has not been switched on.
+* The impacted code only runs behind a command-line flag or `chrome://flags`
+  entry. (In particular, if a bug can only affect those who have
+  set `#enable-experimental-web-platform-features`, it is **Security_Impact-None**.
+* It's a V8 feature behind flags such as `--future`, `--es-staging` or
+  `--wasm-staging` or other experimental flags that are disabled by default.
+
+Cases where it's *not* OK to set **Security_Impact-None**:
+
+* Features enabled via normal UI or settings which users might happen across
+  in normal usage. For instance, accessibility features.
+* Origin trials. Origin trials are only active on some websites, but the
+  affected code does run for Chrome users with the default Chrome configuration.
+* The impacted code runs behind a feature flag which is *enabled by default*,
+  even if that field trial configuration has been switched off. That's because
+  the code may be active for devices which can't access the field trial
+  configuration service.
+* The feature is turned on only for a small percent of users, e.g. 1%.
+* Feature or flag checks are done somewhere that the attacker could influence.
+  For example a privilege escalation from a lower-privileged process
+  (e.g. renderer) to a higher-privileged process (e.g. browser)
+  assumes that the lower-privileged process is already compromised. The
+  attacker could overwrite memory for any feature checks performed within
+  that lower-privileged process; the bug only qualifies as impact **None**
+  if checks are performed in the higher-privileged process.
+
+It's important to get this right, because this label influences how rapidly
+we merge and release the fix. Ask for help if you're not sure.
+
+Some **Security_Impact-None** bugs may still be subject to VRP rewards, if
+those bugs are found in found in code that we're likely to enable in the future.
+
 ### OS Labels
 
 It can be hard to know which OS(s) a bug applies to. Here are some guidelines:
diff --git a/chromium/docs/security/severity-guidelines.md b/chromium/docs/security/severity-guidelines.md
index 30820436610..06d01668889 100644
--- a/chromium/docs/security/severity-guidelines.md
+++ b/chromium/docs/security/severity-guidelines.md
@@ -154,6 +154,15 @@ Example bugs:
 ([128163](https://crbug.com/128163)).
 
 
+## Can't impact Chrome users by default {#TOC-No-impact}
+
+If the bug can't impact Chrome users by default, this is denoted instead by
+the **Security-Impact_None** label. See
+[the security labels document](security-labels.md#TOC-Security_Impact-None)
+for more information. The bug should still have a severity set according
+to these guidelines.
+
+
 ## Not a security bug {#TOC-Not-a-security-bug}
 
 The [security FAQ](faq.md) covers many of the cases that we do not consider to
diff --git a/chromium/docs/security/side-channel-threat-model.md b/chromium/docs/security/side-channel-threat-model.md
index 888baad3ce9..afe54be4fe1 100644
--- a/chromium/docs/security/side-channel-threat-model.md
+++ b/chromium/docs/security/side-channel-threat-model.md
@@ -208,11 +208,7 @@ tracked this as [Issue
 ###### Flash
 
 Click To Play greatly reduces the risk that Flash-borne Spectre (and other)
-exploits will be effective at scale.  Additionally, the enterprise policies
-[PluginsBlockedForUrls](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=PluginsBlockedForUrls)
-and
-[PluginsAllowedForUrls](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=PluginsAllowedForUrls)
-can be combined to restrict Flash to specific websites.
+exploits will be effective at scale.
 Even so,
 [we might want to consider teaching CORB about Flash flavour of CORS](https://crbug.com/816318).
 
diff --git a/chromium/docs/speed/DIR_METADATA b/chromium/docs/speed/DIR_METADATA
new file mode 100644
index 00000000000..6930cc4c5f1
--- /dev/null
+++ b/chromium/docs/speed/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Speed"
+}
\ No newline at end of file
diff --git a/chromium/docs/speed/OWNERS b/chromium/docs/speed/OWNERS
deleted file mode 100644
index aed0a9618ea..00000000000
--- a/chromium/docs/speed/OWNERS
+++ /dev/null
@@ -1,4 +0,0 @@
-benhenry@chromium.org
-ushesh@chromium.org
-per-file apk_size_regressions.md=agrieve@chromium.org
-# COMPONENT: Speed
diff --git a/chromium/docs/speed/benchmark/DIR_METADATA b/chromium/docs/speed/benchmark/DIR_METADATA
new file mode 100644
index 00000000000..a761f765271
--- /dev/null
+++ b/chromium/docs/speed/benchmark/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Test>Telemetry"
+}
\ No newline at end of file
diff --git a/chromium/docs/speed/benchmark/OWNERS b/chromium/docs/speed/benchmark/OWNERS
deleted file mode 100644
index 5b10219821e..00000000000
--- a/chromium/docs/speed/benchmark/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Test>Telemetry
diff --git a/chromium/docs/speed/benchmark/harnesses/rendering.md b/chromium/docs/speed/benchmark/harnesses/rendering.md
index fb5aae73279..47e757853cf 100644
--- a/chromium/docs/speed/benchmark/harnesses/rendering.md
+++ b/chromium/docs/speed/benchmark/harnesses/rendering.md
@@ -30,7 +30,7 @@ These benchmarks are run on the [Chromium Perf Waterfall](https://ci.chromium.or
 Rendering metrics are [written in Javascript](https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/rendering/). The list of all metrics and their meanings should be documented in the files they are defined in.
 
 -   [cpu\_utilization.html](https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/rendering/cpu_utilization.html): `cpu_time_per_frame` and `tasks_per_frame`
--   [frame\_time.html](https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/rendering/frame_time.html): `frame_times`, `percentage_smooth`, `frame_lengths`, `avg_surface_fps`, `jank_count`, and `ui_frame_times`
+-   [frame\_time.html](https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/rendering/frame_time.html): `frame_times`, `avg_surface_fps`, `jank_count`, and `ui_frame_times`
 -   [pixels.html](https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/rendering/pixels.html): `mean_pixels_approximated` and `mean_pixels_checkerboarded`
 -   [queueing\_duration.html](https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/rendering/queueing_duration.html): `queueing_durations`
 
diff --git a/chromium/docs/speed/binary_size/DIR_METADATA b/chromium/docs/speed/binary_size/DIR_METADATA
new file mode 100644
index 00000000000..22e8befaaca
--- /dev/null
+++ b/chromium/docs/speed/binary_size/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Speed>Release"
+}
\ No newline at end of file
diff --git a/chromium/docs/speed/binary_size/OWNERS b/chromium/docs/speed/binary_size/OWNERS
deleted file mode 100644
index a35bb21b220..00000000000
--- a/chromium/docs/speed/binary_size/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Speed>Release
diff --git a/chromium/docs/speed/binary_size/android_binary_size_trybot.md b/chromium/docs/speed/binary_size/android_binary_size_trybot.md
index 7c813ea43c7..444462f41d9 100644
--- a/chromium/docs/speed/binary_size/android_binary_size_trybot.md
+++ b/chromium/docs/speed/binary_size/android_binary_size_trybot.md
@@ -205,6 +205,8 @@ For more information on when to use `const char *` vs `const char[]`, see
 
 ## Code Locations
 
-- [Link to recipe](https://cs.chromium.org/chromium/build/scripts/slave/recipes/binary_size_trybot.py)
+- [Trybot recipe](https://source.chromium.org/chromium/chromium/tools/build/+/master:recipes/recipes/binary_size_trybot.py),
+[CI recipe](https://source.chromium.org/chromium/chromium/tools/build/+/master:recipes/recipes/binary_size_generator_tot.py),
+[recipe module](https://source.chromium.org/chromium/chromium/tools/build/+/master:recipes/recipe_modules/binary_size/api.py)
 - [Link to src-side checks](/tools/binary_size/trybot_commit_size_checker.py)
 - [Link to Gerrit Plugin](https://chromium.googlesource.com/infra/gerrit-plugins/chromium-binary-size/)
diff --git a/chromium/docs/speed/bot_health_sheriffing/main.md b/chromium/docs/speed/bot_health_sheriffing/main.md
index e6b2d1605bf..cb5dbb16a90 100644
--- a/chromium/docs/speed/bot_health_sheriffing/main.md
+++ b/chromium/docs/speed/bot_health_sheriffing/main.md
@@ -38,7 +38,9 @@ roll](https://autoroll.skia.org/r/catapult-autoroll), which should
 automatically TBR the sheriff. If the catapult roll fails, the sheriff should
 investigate and revert suspect changelists.
 
-The sheriff should *not* feel like responsible for investigating hard problems. The volume of incoming alerts makes this infeasible. Instead, they should delegate deep investigations to the right owners. As a rule of thumb, a trained sheriff should expect to spend 10-20 minutes per alert and should never be spending more than an hour per alert.
+Near the end of their shift, sheriffs should also inspect[this dashboard](https://dashboards.corp.google.com/_e3cbeb60_d250_4e67_8795_56cd9af8a303) for the time covered during their shift, and do a first-pass analysis of any anomalies (e.g. jobs taking 6 hours when they normally take 1.5).
+
+The sheriff should *not* feel responsible for investigating hard problems. The volume of incoming alerts makes this infeasible. Instead, they should delegate deep investigations to the right owners. As a rule of thumb, a trained sheriff should expect to spend 10-20 minutes per alert and should never be spending more than an hour per alert.
 
 ## Workflow
 
diff --git a/chromium/docs/speed/images/DIR_METADATA b/chromium/docs/speed/images/DIR_METADATA
new file mode 100644
index 00000000000..b2607fdfee8
--- /dev/null
+++ b/chromium/docs/speed/images/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Speed>Benchmarks"
+}
\ No newline at end of file
diff --git a/chromium/docs/speed/images/OWNERS b/chromium/docs/speed/images/OWNERS
deleted file mode 100644
index 48be081137c..00000000000
--- a/chromium/docs/speed/images/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Speed>Benchmarks
diff --git a/chromium/docs/speed/metrics_changelog/2020_10_cls.md b/chromium/docs/speed/metrics_changelog/2020_10_cls.md
new file mode 100644
index 00000000000..62212c37482
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/2020_10_cls.md
@@ -0,0 +1,76 @@
+# Cumulative Layout Shift Changes in Chrome 86
+
+## Changes in Chrome 86
+
+A large change was made to the way Chrome records underlying layout shifts
+which contribute to Cumulative Layout Shift in Chrome 86. The source code of the
+change is [here](https://chromium-review.googlesource.com/c/chromium/src/+/2336301/).
+
+The goal of the change was to better align the implementation to the
+[specification](https://wicg.github.io/layout-instability/), which says:
+
+> The visual representation of a Node N is defined as follows:
+> * If N is an Element which generates one or more boxes, the visual representation of N is the set of all points that lie within the bounds of any fragment of any box generated by N, in the coordinate space of the viewport, excluding any points that lie outside of the viewport.
+> * If N is a text node, the visual representation of N is the set of all points that lie within the bounds of any line box generated by N, in the coordinate space of the viewport, excluding any points that lie outside of the viewport.
+
+This change has a few different impacts.
+
+First, it no longer reports layout shifts from ink overflows, which should
+improve Cumulative Layout Shift scores on pages with hover effects.
+
+Second, when text shifts, the area shifted is the containing block starting from
+the LayoutText moved, with the logical height of the text (source code for
+using the logical height [here](https://chromium-review.googlesource.com/c/chromium/src/+/2386842)).
+This will have a small impact on the score in some cases.
+
+Third, there has been a change to how the area of the
+[impact fraction](https://web.dev/cls/#impact-fraction) is computed. In Chrome
+85 and below, when content overflowed the parent element, each descendant area
+was counted separately, using each element's border box. As of Chrome 86, the
+implementation has been updated to conform with the spec, by using the layout
+overflow rect, which contains all points that lie in the bounds of any fragment
+box. In both cases, the rects are still clipped to the viewport:
+
+Before change | After
+------------- | -----
+![Example of M85 Border Boxes](images/CLS_M85_Example1.png) | ![Example of M86 Layout Overflow Rects](images/CLS_M86_Example1.png)
+
+### Problem in Chrome 86
+
+Unfortunately, there is a problem in the specification that was only
+uncovered as the change rolled out to stable. It occurs in cases
+when a shifted node's positioned descendants overflow on the other side
+of the viewport. The intersection of the viewport and the layout overflow rect
+can be larger than the visible shift, as in this example below:
+
+Before change | After
+------------- | -----
+![Example of M85 border boxes with extreme shifts](images/CLS_M85_Example2.png) | ![Example of M86 border boxes with extreme shifts](images/CLS_M86_Example2.png)
+
+The issue has been fixed on chromium trunk (source code [here](https://chromium-review.googlesource.com/c/chromium/src/+/2503330)), but the fix will not roll out to stable until Chrome 87.
+
+## How does this affect a site's metrics?
+
+Sites with hover effects can expect to see small improvements on their Cumulative
+Layout Shift Scores.
+
+Sites with absolutely positioned content with negative offsets outside the
+viewport will see large regressions in their Cumulative Layout Shift scores
+until the fix rolls out to stable.
+
+### My CLS score regressed in M86. Is that a result of the above-mentioned issue?
+
+You can test the fix on [Chrome Canary](https://www.google.com/chrome/canary/) version
+88.0.4307.0 or later. You can navigate to `chrome://version` (by typing that in
+the URL bar) to verify your browser's version. Either the
+[JavaScript implementation](https://web.dev/cls/#measure-cls-in-javascript) or the
+[Chrome Extension](https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma?hl=en)
+can be used to check the Cumulative Layout Shift score on both canary and stable
+channels.
+
+If your CLS score returns to expected levels with the fix, there is no need to
+make changes to your site to address the metric changes in Chrome 86.
+
+## When were users affected?
+
+Most users were updated to Chrome 86 the week of October 19, 2020.
diff --git a/chromium/docs/speed/metrics_changelog/2020_10_cls_2.md b/chromium/docs/speed/metrics_changelog/2020_10_cls_2.md
new file mode 100644
index 00000000000..61e24d9906c
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/2020_10_cls_2.md
@@ -0,0 +1,24 @@
+# Cumulative Layout Shift Changes in Chrome 87
+
+## Changes in Chrome 87
+
+In Chrome 86, a [problem was introduced](2020_10_cls.md) to the way the area of
+the [impact fraction](https://web.dev/cls/#impact-fraction) is calculated
+for layout shifts of nodes containing positioned content that overflows to the
+other side of the viewport. In Chrome 87, the problem is fixed by using visual
+rects to calculate the impact area instead of layout overflow rects (source code
+for the change
+[here](https://chromium-review.googlesource.com/c/chromium/src/+/2503330)).
+
+Before change | After
+------------- | -----
+![Example of M86 problem](images/CLS_M86_Problem.png) | ![Example of M87 fix](images/CLS_M87_Fix.png)
+
+## How does this affect a site's metrics?
+
+Sites which showed this regression in Chrome 86 should return to accurate layout
+shift scores in Chrome 87.
+
+## When were users affected?
+
+Most users will be updated to Chrome 87 the week of November 17, 2020.
diff --git a/chromium/docs/speed/metrics_changelog/2020_11_cls.md b/chromium/docs/speed/metrics_changelog/2020_11_cls.md
new file mode 100644
index 00000000000..de6b42106e0
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/2020_11_cls.md
@@ -0,0 +1,52 @@
+# Cumulative Layout Shift Changes in Chrome 88
+
+## Changes in Chrome 88
+
+### Bug fix for descendents of sticky elements
+
+Before Chrome 88, Cumulative Layout Shift did not take shifts of descendents of
+sticky elements into account. This has been fixed in Chrome 88.
+[Source code for this change](https://chromium-review.googlesource.com/c/chromium/src/+/2519360).
+
+### Bug fix for fixed position elements
+
+Prior to Chrome 88, Cumulative Layout Shift did not take shifts of fixed
+position elements into account. This has been fixed in Chrome 88.
+[Source code for this change](https://chromium-review.googlesource.com/c/chromium/src/+/2520330).
+
+### Bug fix for content-visibility: auto
+
+When the `content-visibility: auto` feature was shipped in Chrome 85, a
+CLS-impacting flaw was present: changes between the skipped and not-skipped
+state of a `content-visibility: auto` subtree caused an observed layout shift
+in the `content;visibility: auto` element as it resized.
+
+In Chrome 88, the CLS issue was [fixed](https://crbug.com/1151526).
+Going forward, there should be no CLS penalty for such elements. (Note that
+there still may be a layout shift for onscreen elements adjacent to (but not
+descendants of) the `content-visibility: auto` element.
+
+## How does this affect a site's metrics?
+
+All of these changes only affect sites with specific types of content. Here are
+the specifics for each change:
+
+### Bug fix for descendents of sticky elements
+
+Sites with descendents of  sticky position elements which shift unexpectedly
+should see an increase in their Cumulative Layout Shift scores.
+
+### Bug fix for fixed position elements
+
+Sites with fixed position elements which shift unexpectedly should see an
+increase in their Cumulative Layout Shift scores.
+
+### Bug fix for content-visibility: auto
+
+Sites using `content-visibility: auto` should no longer see any impact of this
+feature on their Cumulative Layout Shift scores, resulting in a decrease in
+their scores.
+
+## When were users affected?
+
+Chrome 88 is currently scheduled to be released the week of January 19, 2021.
diff --git a/chromium/docs/speed/metrics_changelog/2020_12_cls.md b/chromium/docs/speed/metrics_changelog/2020_12_cls.md
new file mode 100644
index 00000000000..6f71bdf7569
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/2020_12_cls.md
@@ -0,0 +1,26 @@
+# Cumulative Layout Shift Changes in Chrome 89
+
+## Changes in Chrome 89
+
+### Ignore layout shift when visibility:hidden becomes visible
+
+We have been always ignoring layout shifts when the element has
+visibility:hidden. However before Chrome 89, if the element having
+visibility:hidden became visible and shift at the same time, we reported layout
+shift. Now we also consider the previous visibility and ignore layout shift in
+the case.
+[Source code for this change](https://chromium-review.googlesource.com/c/chromium/src/+/2591367)
+
+## How does this affect a site's metrics?
+
+All of these changes only affect sites with specific types of content. Here are
+the specifics for each change:
+
+### Ignore layout shift when visibility:hidden becomes visible
+
+Sites using visibility:hidden to hide layout changes may see a decrease in
+their Cumulative Layout Shift scores.
+
+## When were users affected?
+
+Chrome 89 is currently scheduled to be released the week of March 2, 2021.
diff --git a/chromium/docs/speed/metrics_changelog/cls.md b/chromium/docs/speed/metrics_changelog/cls.md
index a2d8fa13cb9..5867effffa1 100644
--- a/chromium/docs/speed/metrics_changelog/cls.md
+++ b/chromium/docs/speed/metrics_changelog/cls.md
@@ -2,12 +2,16 @@
 
 This is a list of changes to [Cumulative Layout Shift](https://web.dev/cls).
 
+* Chrome 89
+  * Metric definition improvement: [Ignore layout shift when visibility:hidden becomes visible](2020_12_cls.md)
+* Chrome 88
+  * Metric definition improvement: [Cumulative layout shift properly detects shifts of fixed position elements](2020_11_cls.md)
+  * Metric definition improvement: [Cumulative layout shift properly detects shifts of descendents of a sticky element](2020_11_cls.md)
+  * Metric definition improvement: [no penalty for content-visibility: auto content](2020_11_cls.md)
+* Chrome 87
+  * Metric definition improvement: [Fix problem in Cumulative Layout shift calculation of impact region](2020_10_cls_2.md)
 * Chrome 86
-  * Fixed bugs about ink overflows (crbug.com/1108622) and transforms (crbug.com/1109053).
-  * Now we aggregate layout shift reports of:
-    * an element and its descendants if they move together, and
-    * inline elements and texts in a block after a shifted text.
-  These changes will affect layout instability score for the specific cases.
+  * Metric definition changes and bug: [Cumulative Layout Shift score changes and regressions in impact region calculation](2020_10_cls.md)
 * Chrome 85
   * Metric definition improvement: [Cumulative Layout Shift ignores layout shifts from video slider thumb](2020_06_cls.md)
 * Chrome 79
diff --git a/chromium/docs/speed/metrics_changelog/images/CLS_M85_Example1.png b/chromium/docs/speed/metrics_changelog/images/CLS_M85_Example1.png
new file mode 100644
index 00000000000..6a4852f7db7
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/images/CLS_M85_Example1.png
diff --git a/chromium/docs/speed/metrics_changelog/images/CLS_M85_Example2.png b/chromium/docs/speed/metrics_changelog/images/CLS_M85_Example2.png
new file mode 100644
index 00000000000..2013489f028
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/images/CLS_M85_Example2.png
diff --git a/chromium/docs/speed/metrics_changelog/images/CLS_M86_Example1.png b/chromium/docs/speed/metrics_changelog/images/CLS_M86_Example1.png
new file mode 100644
index 00000000000..b586a2324b6
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/images/CLS_M86_Example1.png
diff --git a/chromium/docs/speed/metrics_changelog/images/CLS_M86_Example2.png b/chromium/docs/speed/metrics_changelog/images/CLS_M86_Example2.png
new file mode 100644
index 00000000000..5c2f6e5390e
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/images/CLS_M86_Example2.png
diff --git a/chromium/docs/speed/metrics_changelog/images/CLS_M86_Problem.png b/chromium/docs/speed/metrics_changelog/images/CLS_M86_Problem.png
new file mode 100644
index 00000000000..6243ff35a07
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/images/CLS_M86_Problem.png
diff --git a/chromium/docs/speed/metrics_changelog/images/CLS_M87_Fix.png b/chromium/docs/speed/metrics_changelog/images/CLS_M87_Fix.png
new file mode 100644
index 00000000000..34db9ab75e3
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/images/CLS_M87_Fix.png
diff --git a/chromium/docs/speed/perf_lab_platforms.md b/chromium/docs/speed/perf_lab_platforms.md
index 59decbb192a..72c441f03a6 100644
--- a/chromium/docs/speed/perf_lab_platforms.md
+++ b/chromium/docs/speed/perf_lab_platforms.md
@@ -23,6 +23,8 @@
 
  * [mac-10_12_laptop_low_end-perf](https://ci.chromium.org/p/chrome/builders/ci/mac-10_12_laptop_low_end-perf): MacBook Air, Core i5 1.8 GHz, 8GB RAM, 128GB SSD, HD Graphics.
  * [mac-10_13_laptop_high_end-perf](https://ci.chromium.org/p/chrome/builders/ci/mac-10_13_laptop_high_end-perf): MacBook Pro, Core i7 2.8 GHz, 16GB RAM, 256GB SSD, Radeon 55.
+ * [mac-arm_dtk_arm-perf](https://ci.chromium.org/p/chrome/builders/ci/mac-arm_dtk_arm-perf): Mac ARM DTK (ARM Chrome).
+ * [mac-arm_dtk_x86-perf](https://ci.chromium.org/p/chrome/builders/ci/mac-arm_dtk_x86-perf): Mac ARM DTK (X86 Chrome).
 
 ## Win
 
diff --git a/chromium/docs/speed/perf_waterfall.md b/chromium/docs/speed/perf_waterfall.md
index 6d1de5e8443..1c643d092ac 100644
--- a/chromium/docs/speed/perf_waterfall.md
+++ b/chromium/docs/speed/perf_waterfall.md
@@ -14,6 +14,32 @@ of speed:
 > "If you make a change that regresses measured performance, you will be
 > required to fix it or revert".
 
+## How It Works
+
+The perf waterfall is split into three stages - builders, testers, and processors.
+
+### Builders
+
+For each commit to the Chromium repo, a Builder is invoked. The builder builds
+Google Chrome, acquires test assets, and bundles everything up to be passed
+along to Testers. We execute a builder for each platform we support. To ensure
+we can keep up with the rapid flow of commits, we have a set of builders per
+platform, each building a different commit.
+
+### Testers
+
+For each platform, we have a single tester job running continuously. Each run of
+a tester covers the set of commits from the end commit of the previous
+invocation to the latest _built_ commit. Each tester has one or more subdevices
+(shards). The tester delegates a subset of tests to each shard and aggregates
+high-level results (pass/fail, runtimes).
+
+### Processors
+
+Processors analyze the raw data generated by each Tester and convert it into a form that can be utilized
+by the [Chrome Performance Dashboard](https://chromeperf.appspot.com/report).
+For some jobs, this work is executed by the tester instead.
+
 ## Contact
 
   * You can reach the Chromium performance sheriffs at perf-sheriffs@chromium.org.
diff --git a/chromium/docs/speed_metrics/DIR_METADATA b/chromium/docs/speed_metrics/DIR_METADATA
new file mode 100644
index 00000000000..35bab6d4e60
--- /dev/null
+++ b/chromium/docs/speed_metrics/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Blink>PerformanceAPIs"
+}
\ No newline at end of file
diff --git a/chromium/docs/speed_metrics/OWNERS b/chromium/docs/speed_metrics/OWNERS
deleted file mode 100644
index 2bf71fe278e..00000000000
--- a/chromium/docs/speed_metrics/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Blink>PerformanceAPIs
\ No newline at end of file
diff --git a/chromium/docs/speed_metrics/webperf_okrs.md b/chromium/docs/speed_metrics/webperf_okrs.md
index 98cf59c6640..8e3d775ef45 100644
--- a/chromium/docs/speed_metrics/webperf_okrs.md
+++ b/chromium/docs/speed_metrics/webperf_okrs.md
@@ -2,6 +2,82 @@
 
 [TOC]
 
+## 2020 Q4 Objectives
+
+### New web performance APIs
+
+  * {#measure-memory-20204}**performance.measureMemory**:
+    * Add support for cross-origin iframes.
+    * Send Intent to Ship and ship --- API would become available early next year.
+  * {#spas-20204}**Single Page Apps**:
+    * Publish document for feedback on measurement issues, attributions issues, and other issues specific
+      to SPAs.
+    * Land support for User Timing hints in Chrome, and get 2+ frameworks to start using such hints.
+  * {#page-abandonment-20204}**Page abandonment**: publish data on abandonment rates, making a case for or against
+    an abandonment API.
+  * {#js-profiler-20204}**JS Sampling Profiler**:
+    * Implement the API so it requires COOP/COEP.
+    * Add support for warm codemap initialization.
+    * Add web platform tests.
+    * _(Stretch)_ Send Intent to Ship.
+  * {#smoothness-20204}**Smoothness** (FrameTiming):
+    * Discuss and socialize API shape.
+    * Propose API on WICG.
+    * Start a TAG review.
+  * {#bf-cache-20204}**Back-forward cache**: document and socialize a concrete proposal on a web API that supports
+    monitoring performance of sites on browsers that may perform back-forward navigations.
+  * {#responsiveness-20204}**Responsiveness**:
+    * Investigate internal metrics and potentially add new metrics to capture end-to-end responsiveness.
+    * Document how popular frameworks handle user interactions.
+    * Brainstorm on how to expand Event Timing to capture user handling for asynchronous work and to handle multiple
+      events referring to a single user interaction.
+    * Complete on-going investigation on whether scroll performance is also a problem in the web that needs a web API.
+
+### Existing web performance API improvements
+
+  * {#lcp-20204}**Largest Contentful Paint**:
+    * Complete [investigation](https://bugs.chromium.org/p/chromium/issues/detail?id=1045640) on removed nodes
+      and if needed update the API.
+    * [Ignore](https://bugs.chromium.org/p/chromium/issues/detail?id=1133883) images that occupy the full viewport.
+  * {#cls-20204}**Cumulative Layout Shift**: evaluate the impact of triggering on empty or invisible content and update
+    [spec](https://github.com/WICG/layout-instability/issues/61) and implementation accordingly.
+  * {#fcp-20204}**First Contentful Paint**: improve implementation to pass more
+    [tests](https://wpt.fyi/results/paint-timing?label=master&label=experimental).
+  * {#rt-worker-20204}**Navigation Timing**: [Fix](https://crbug.com/925239) encoded/decoded body sizes when going
+    through service workers.
+
+## 2020 Q3 Progress
+
+### New web performance APIs
+
+  * [performance.measureMemory](#measure-memory-20203):
+    * Spec was reviewed and polished.
+    * API support was added for workers (available from Chrome 87).
+  * [Page abandonment](#page-abandonment-20203): improved data was gathered, but more accuracy improvements are needed.
+  * [VisibilityStateEntry](#page-visibility-20203):
+    [explainer](https://docs.google.com/document/d/1l5kHiJRkdQwEN-CYI5_mUNODhQVB5rCyjN4jHDdXDHA/edit#),
+    [discussion](https://github.com/w3c/performance-timeline/issues/105), and TAG
+    [review](https://github.com/w3ctag/design-reviews/issues/534) kicked off, but no consensus yet on API shape.
+  * [FrameTiming](#frame-timing-20203): a lot of research on defining a good metric to capture smoothness.
+  * [isInputPending](#fb-driven-20203): shipped and available from Chrome 87!
+
+### Existing web performance API improvements
+
+  * [LargestContentfulPaint](#lcp-20203):
+    * Did analysis on how LCP would change when removed content is included.
+    * Ignored paints occurring with opacity 0.
+  * CumulativeLayoutShift [fixes](https://chromium.googlesource.com/chromium/src/+/master/docs/speed/metrics_changelog/cls.md):
+    * Ignored shifts from video thumb sliders.
+    * Fixed computations for ink overflow and transforms.
+    * Updated computations when child moves alongside their parent element.
+
+### Interop
+
+  * [Web vitals specs](#vitals-specs-20203): triaged new
+    [issues](https://github.com/search?q=is%3Aissue+created%3A2020-06-01..2020-09-30+repo%3Awicg%2Flayout-instability+repo%3Awicg%2Flargest-contentful-paint+repo%3Awicg%2Fevent-timing&type=issues)
+    as well as existing ones.
+  * [Paint Timing](#paint-timing-20203): fixed two FCP tests by improving our implementation.
+
 ## 2020 Q3 Objectives
 
 ### New web performance APIs
diff --git a/chromium/docs/static_initializers.md b/chromium/docs/static_initializers.md
index e8ee5e49afc..d8fee93e896 100644
--- a/chromium/docs/static_initializers.md
+++ b/chromium/docs/static_initializers.md
@@ -23,6 +23,17 @@ Common fixes include:
 
 ## Listing Static Initializers
 
+### Method 1 - Ask compiler to report them
+1. Edit [//build/config/BUILDCONFIG.gn](https://cs.chromium.org/chromium/src/build/config/BUILDCONFIG.gn)
+and add `"//build/config/compiler:wglobal_constructors"` to `default_compiler_configs`
+2. Set GN arg `treat_warnings_as_errors=false`
+3. Compile and look at warnings
+
+This will produce far more warnings than there are static initializers because
+it (seems to) trigger on global variables initialized with constexpr
+constructors.
+
+### Method 2 - Use objdump to report them
 For Linux:
 
     tools/linux/dump-static-initializers.py out/Release/chrome
diff --git a/chromium/docs/sync/DIR_METADATA b/chromium/docs/sync/DIR_METADATA
new file mode 100644
index 00000000000..17ae8c61690
--- /dev/null
+++ b/chromium/docs/sync/DIR_METADATA
@@ -0,0 +1,12 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Services>Sync"
+}
+team_email: "chromium-reviews@chromium.org"
\ No newline at end of file
diff --git a/chromium/docs/sync/OWNERS b/chromium/docs/sync/OWNERS
deleted file mode 100644
index 87ed1525e6f..00000000000
--- a/chromium/docs/sync/OWNERS
+++ /dev/null
@@ -1,2 +0,0 @@
-# COMPONENT: Services>Sync
-# TEAM: chromium-reviews@chromium.org
diff --git a/chromium/docs/sync/model_api.md b/chromium/docs/sync/model_api.md
index 63c2e938393..5ab353a0a59 100644
--- a/chromium/docs/sync/model_api.md
+++ b/chromium/docs/sync/model_api.md
@@ -197,7 +197,7 @@ base::Optional<ModelError> DeviceInfoSyncBridge::ApplySyncChanges(
   }
 
   batch->TakeMetadataChangesFrom(std::move(metadata_change_list));
-  store_->CommitWriteBatch(std::move(batch), base::Bind(...));
+  store_->CommitWriteBatch(std::move(batch), base::BindOnce(...));
   NotifyModelOfChanges();
   return {};
 }
@@ -231,7 +231,7 @@ void WriteLocalChange(std::string key, ModelData data) {
                             batch->GetMetadataChangeList());
   }
   batch->WriteData(key, data.specifics->SerializeAsString());
-  store_->CommitWriteBatch(std::move(batch), base::Bind(...));
+  store_->CommitWriteBatch(std::move(batch), base::BindOnce(...));
 }
 ```
 
diff --git a/chromium/docs/testing/DIR_METADATA b/chromium/docs/testing/DIR_METADATA
new file mode 100644
index 00000000000..5bd66c6c14b
--- /dev/null
+++ b/chromium/docs/testing/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Test"
+}
\ No newline at end of file
diff --git a/chromium/docs/testing/OWNERS b/chromium/docs/testing/OWNERS
deleted file mode 100644
index d3d78c210f1..00000000000
--- a/chromium/docs/testing/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Test
diff --git a/chromium/docs/testing/android_test_instructions.md b/chromium/docs/testing/android_test_instructions.md
index 6a51945bb9e..4f1792fd742 100644
--- a/chromium/docs/testing/android_test_instructions.md
+++ b/chromium/docs/testing/android_test_instructions.md
@@ -130,6 +130,12 @@ resize2fs android_emulator_sdk/sdk/system-images/android-25/x86/userdata.img 1G
 tune2fs -e continue android_emulator_sdk/sdk/system-images/android-25/x86/userdata.img
 ```
 
+### AdbCommandFailedError: failed to stat remote object
+
+There's a known issue (https://crbug.com/1094062) where the unit test binaries can fail on
+Android R and later: if you see this error, try rerunning on an Android version
+with API level <= 29 (Android <= Q).
+
 ## Symbolizing Crashes
 
 Crash stacks are logged and can be viewed using `adb logcat`. To symbolize the
diff --git a/chromium/docs/testing/chromeos_debugging_tips.md b/chromium/docs/testing/chromeos_debugging_tips.md
index ca4e06c3c46..afe581c4554 100644
--- a/chromium/docs/testing/chromeos_debugging_tips.md
+++ b/chromium/docs/testing/chromeos_debugging_tips.md
@@ -20,15 +20,22 @@ tests failing (likely in the `chrome_all_tast_tests` step), you can:
 
 - **Inspect the failed test's log snippet**: There should be a log link for
 each failed test with failure information. eg: For this [failed build], opening
-the [platform.Histograms] log link contains stack traces and error messages.
+the [ui.WindowControl] log link contains stack traces and error messages.
 
 - **View browser & system logs**: A common cause of failure on Chrome's builders
 are browser crashes. When this happens, each test's log snippets will simply
 contain warnings like "[Chrome probably crashed]". To debug these crashes,
-navigate to the test's Isolated output, most likely listed in the build under
-the test step's [shard #0 isolated out] link. From there, view the various
-`log/chrome/...` or `log/ui/...` text files and you should find some with
-browser [crashes and stack traces].
+navigate to the test's Isolated output, listed in the build under the test
+step's [shard #0 isolated out] link. There you'll find expanded logs for every
+test. For example, the [tests/ui.WindowControl/messages] log has more info
+than its earlier snippet. Additionally, you can find system logs under
+the `system_logs/` prefix. To find a system log for a particular test, match
+the timestamps printed in the test's log with the timestamps present in the
+system log filename. For instance, the previous `ui.WindowControl` failure
+matches the [system_logs/chrome/chrome_20201029-195153] browser log, which
+contains the culprit Chrome crash and backtrace.
+
+### Disabling a test
 
 There a couple ways to disable a test on Chrome's builders:
 - **With a full CrOS checkout**: If you have a full CrOS checkout, you can add
@@ -43,6 +50,21 @@ disabled tests for the step's GN target. For example, to disable a test in the
 In both cases, please make sure a bug is filed for the test, and route it to
 the appropriate owners.
 
+### Running a test locally
+
+To run a Tast test the same way it's ran on Chrome's builders:
+
+- Decide which Chrome OS device type or VM to test on.
+
+- Build Chrome via the [Simple Chrome] workflow for that board.
+
+- Deploy your Chrome to the device via the [deploy_chrome.py] tool.
+
+- Finally, run the Tast test on the device via the `cros_run_test` tool under
+  `//third_party/chromite/bin/`. eg:
+  `cros_run_test --device $DEVICE_IP --tast ui.ChromeLogin`. See [here] for more
+  info on cros_run_test.
+
 ## Telemetry
 
 >TODO: Add instructions for debugging telemetry failures.
@@ -58,10 +80,14 @@ the appropriate owners.
 
 [linux-chromeos]: https://chromium.googlesource.com/chromium/src/+/master/docs/chromeos_build_instructions.md
 [Tast]: https://chromium.googlesource.com/chromiumos/platform/tast/+/HEAD/README.md
-[failed build]: https://ci.chromium.org/p/chromium/builders/ci/chromeos-kevin-rel/14102
-[platform.Histograms]: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8904949911599004400/+/steps/chrome_all_tast_tests_on_ChromeOS/0/logs/Deterministic_failure:_platform.Histograms__status_FAILURE_/0
+[failed build]: https://ci.chromium.org/p/chromium/builders/ci/chromeos-kevin-rel/29791
+[ui.WindowControl]: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8865053459542681936/+/steps/chrome_all_tast_tests_on_ChromeOS/0/logs/Deterministic_failure:_ui.WindowControl__status_FAILURE_/0
 [Chrome probably crashed]: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8905974915785988832/+/steps/chrome_all_tast_tests__retry_shards_with_patch__on_ChromeOS/0/logs/Deterministic_failure:_ui.ChromeLogin__status_FAILURE_/0
-[shard #0 isolated out]: https://isolateserver.appspot.com/browse?namespace=default-gzip&hash=fd1f6d76b076f07cc98fa7b2e0c0097f35c51cd0
-[crashes and stack traces]: https://isolateserver.appspot.com/browse?namespace=default-gzip&digest=993d58ff48bb08071d951bd8e103fa5a3c03efb1&as=chrome_20190805-044653
+[shard #0 isolated out]: https://isolateserver.appspot.com/browse?namespace=default-gzip&hash=3d35c273195f640c69b1cf0d15d19d9868e3f593
+[tests/ui.WindowControl/messages]: https://isolateserver.appspot.com/browse?namespace=default-gzip&digest=baefbcfd24c02b3ada4617d259dc6b4220b413b9&as=messages
+[system_logs/chrome/chrome_20201029-195153]: https://isolateserver.appspot.com/browse?namespace=default-gzip&digest=272166c85f190c336a9885f0267cbdea912e31da&as=chrome_20201029-195153
 [Tast attributes]: https://chromium.googlesource.com/chromiumos/platform/tast/+/HEAD/docs/test_attributes.md
 [this list]: https://codesearch.chromium.org/chromium/src/chromeos/BUILD.gn?rcl=7b0393a9091fd02edc9ae773739124f7be5a0782&l=242
+[Simple Chrome]: https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md
+[deploy_chrome.py]: https://chromium.googlesource.com/chromiumos/docs/+/master/simple_chrome_workflow.md#Deploying-Chrome-to-the-device
+[here]: https://chromium.googlesource.com/chromiumos/docs/+/master/cros_vm.md#in-simple-chrome
diff --git a/chromium/docs/testing/gtest_flake_tips.md b/chromium/docs/testing/gtest_flake_tips.md
new file mode 100644
index 00000000000..f9cf55bb40e
--- /dev/null
+++ b/chromium/docs/testing/gtest_flake_tips.md
@@ -0,0 +1,77 @@
+# Addressing Flaky GTests
+
+## Understanding builder results
+
+The [Flake portal](https://analysis.chromium.org/p/chromium/flake-portal/flakes)
+links to the flake occurrences of various tests on various bots. On the flake
+occurrences page for a specific test, clicking on any of the timestamps takes
+you to the bot run that flaked.
+
+![flake_portal_occurrences]
+
+You can then search the page for the flaky test name to view
+details on how it failed. The failure will either be in a unittest run or
+browsertest run. Note that the flake may either be detected as a flaky failure
+if it passed on a following run (a "cq hidden flake" on the flake portal), or it
+could have flaked multiple times causing the bot run to fail (a "cq false
+rejection" on the flake portal). The build step output provides a link to your
+test output. If your flaky test has both hidden flakes and false rejections,
+take a look at the output for both as they may provide different hints toward
+the issue.
+
+![flaky_build_step]
+
+Compare the flake output to the expected output when the test passes. Sometimes
+observing the output is enough to narrow down the issue. However, sometimes
+there’s very little output or it’s not that useful, such as when the test times
+out. In this case you can try and add more logging and reproduce the flake.
+
+## Reproducing the flaky test
+
+If debugging via bot is too slow or you otherwise need to drill further into the
+cause of the flake, you can try to reproduce the flake locally. Reproducing the
+flake can be difficult, so it can help to try and replicate the test environment
+as closely as possible.
+
+Copy the gn args from one of the bots where the flake occurs, and try to choose
+a bot close to your system, i.e. linux-rel if you're building on linux. To get
+the gn args, you can again click on the timestamp in the flake portal to view
+the bot run details, and search for the "lookup GN args" build step to copy the
+args.
+
+![bot_gn_args]
+
+Build and run the test locally. Depending on the frequency of the flake, it may
+take some time to reproduce. Some helpful flags:
+ - --gtest_repeat=100
+ - --gtest_also_run_disabled_tests (if the flaky test(s) you're looking at have
+been disabled)
+
+If you're unable to reproduce the flake locally, you can also try uploading your
+patch with the debug logging and flaky test enabled to try running the bot to
+reproduce the flake with more information.
+
+>TODO: Add more tips for reproducing flaky tests
+
+## Debugging the flaky test
+
+If the test is flakily timing out, consider any asynchronous code that may cause
+race conditions, where the test subject may early exit and miss a callback, or
+return faster than the test can start waiting for it (i.e. make sure event
+listeners are spawned before invoking the event).
+
+For browsertest flakes, consider possible inter-process issues, such as the
+renderer taking too long or returning something unexpected.
+
+>TODO: Add more tips for common flake causes
+
+## Preventing similar flakes
+
+Once you understand the problem and have a fix for the test, think about how the
+fix may apply to other tests, or if documentation can be improved either in the
+relevant code or this flaky test documentation.
+
+
+[flake_portal_occurrences]: images/flake_portal_occurrences.png
+[flaky_build_step]: images/flaky_build_step.png
+[bot_gn_args]: images/bot_gn_args.png
\ No newline at end of file
diff --git a/chromium/docs/testing/images/bot_gn_args.png b/chromium/docs/testing/images/bot_gn_args.png
new file mode 100644
index 00000000000..a4cda9a3a14
--- /dev/null
+++ b/chromium/docs/testing/images/bot_gn_args.png
diff --git a/chromium/docs/testing/images/flake_portal_occurrences.png b/chromium/docs/testing/images/flake_portal_occurrences.png
new file mode 100644
index 00000000000..6c1b35a31ac
--- /dev/null
+++ b/chromium/docs/testing/images/flake_portal_occurrences.png
diff --git a/chromium/docs/testing/images/flaky_build_step.png b/chromium/docs/testing/images/flaky_build_step.png
new file mode 100644
index 00000000000..b2ea0922ffd
--- /dev/null
+++ b/chromium/docs/testing/images/flaky_build_step.png
diff --git a/chromium/docs/testing/images/web_tests_archive_blink_web_tests_step.png b/chromium/docs/testing/images/web_tests_archive_blink_web_tests_step.png
new file mode 100644
index 00000000000..1104b6c47e1
--- /dev/null
+++ b/chromium/docs/testing/images/web_tests_archive_blink_web_tests_step.png
diff --git a/chromium/docs/testing/images/web_tests_blink_web_tests_step.png b/chromium/docs/testing/images/web_tests_blink_web_tests_step.png
new file mode 100644
index 00000000000..ee35be79f41
--- /dev/null
+++ b/chromium/docs/testing/images/web_tests_blink_web_tests_step.png
diff --git a/chromium/docs/testing/images/web_tests_results_viewer_flaky_test.png b/chromium/docs/testing/images/web_tests_results_viewer_flaky_test.png
new file mode 100644
index 00000000000..750575a0356
--- /dev/null
+++ b/chromium/docs/testing/images/web_tests_results_viewer_flaky_test.png
diff --git a/chromium/docs/testing/images/web_tests_results_viewer_query_filter.png b/chromium/docs/testing/images/web_tests_results_viewer_query_filter.png
new file mode 100644
index 00000000000..2d92238bd24
--- /dev/null
+++ b/chromium/docs/testing/images/web_tests_results_viewer_query_filter.png
diff --git a/chromium/docs/testing/on_disabling_tests.md b/chromium/docs/testing/on_disabling_tests.md
index cb3031ff560..439b9c8b33f 100644
--- a/chromium/docs/testing/on_disabling_tests.md
+++ b/chromium/docs/testing/on_disabling_tests.md
@@ -1,59 +1,58 @@
 # On disabling tests
 
 Sometimes you don't want to run a test that you've written (or that
-you've imported, like conformance tests).
+you've imported, like conformance tests). The test might not be possible to
+run in a particular configuration, or be temporarily broken by another
+change, or be flaky, or simply not work yet. In these cases (and perhaps others),
+you should disable the test :).
 
-There are a number of different ways to "disable" a test.
+There are a number of different ways to do so:
 
 *   If the test is an entire binary or test suite, the first (and
-    simplest) first way is to simply not build (or build, but not run)
-    the test binary, of course.
+    simplest) way is to simply not build (or build, but not run)
+    the test binary, of course. This makes sense for binaries that
+    are specific to particular build configurations (e.g., Android JUnit
+    tests don't need to be built on Windows).
 
-*   The second way (for tests in C++) is to not compile a test in a
-    given configuration, e.g., #ifndef WIN. In this situation, the only
+*   A second way (for tests in C++) is to not compile a test in a
+    given configuration, e.g., `#ifndef WIN`. In this situation, the only
     way you would know the test existed and was disabled would be to
-    examine the source code.  In most cases today, we use this path for
-    tests that will never be enabled, but sometimes we do this to
-    temporarily skip tests as well.
-
-*   The third way, for GTest-based tests, is a variant of the second
-    way: instead of compiling it out completely, you change the name, so
-    that you simply don't run the test by default. But, at least in this
-    case, you can potentially determine at runtime the list of disabled
-    tests, because the code is still in the binary. And, potentially you
-    can still force the test to be run via a command line flag.
-
-*   A fourth way is for a test harness to skip over a test at runtime
-    for some reason, e.g., the harness determines that you're running on
-    a machine w/ no GPU and so the GPU tests are never invoked. Here you
-    can also ask the harness which tests are being skipped.
-
-*   A fifth way is for a test harness to run the test, but then have the
-    test detect at runtime that it should skip or exit early (e.g., the
-    test itself could detect there was no GPU). Depending on how the
-    test does this, it may be impossible for you to really detect that
-    this happened, and you'd just view the test as 'passing'.
-
-*   A sixth way is to use [expectations files and filter
-    files](https://bit.ly/chromium-test-list-format), and have the test
-    harness use that file to decide what to run and what to skip.
-
-In theory, we should eventually consistently have either or both of
-expectations files and filter files for all test steps. We still don't
-have this consistently everywhere in Chrome (as of 2020-09-18), but
-folks are working on them expanding the number of kinds of tests that do
-have them. Once we do have them, we can expect people to stop using at
-least the third path.
-
-As you can see from the above, it's difficult if not impossible to
-determine "all of the disabled tests" at any point in time. At best,
-you'd have to decide what subsets of disabled tests that you're
-targeting, and which you'd like to ignore.
-
-You could also choose to "ban" certain approaches, but those bans might
-be hard to enforce, and some approaches may practically be necessary in
-some cases.
-
-Ultimately, the more temporary disabling we can do via the sixth path,
-the better off we probably are: the sixth path is the easiest for us to
-write tooling to support and the most generic of all of the approaches.
+    parse the source code. We often do this today for tests that will
+    never be enabled in particular build configurations, but sometimes we do
+    this to temporarily skip tests as well.
+
+*   A third way is to take advantage of features in your testing framework to
+    skip over tests. Examples include involve adding `DISABLED_` to the test
+    method name for GTest-based tests, `@unittest.skip` for Python-based tests,
+    or using the
+    [DisabledTest](../../base/test/android/javatests/src/org/chromium/base/test/DisabledTest.java)
+    annotation for JUnit-based Java tests.  In these cases, you don't run the
+    test by default, but you can determine the list of disabled tests at
+    runtime because the tests are present in the executable, and you may still
+    be able to force the test to be run via a command-line flag.
+
+*   Fourth, for test frameworks that support
+    [expectations files or filter files](https://bit.ly/chromium-test-list-format),
+    you can use them to decide what to run and what to skip. This moves
+    the mechanisms out of the source code and into separate files; there are
+    advantages and disadvantages to this. The main advantage is that it
+    can make it easier to write tooling to disable tests, and the main
+    disadvantage is that it moves the mechanism away from the code it affects,
+    potentially making it harder to understand what's going on.
+
+*   Finally, the test harness can run the test, but the test itself
+    might detect at runtime that it should exit early for some reason
+    rather than actually executing the code paths you'd normally want to
+    test. For example, if you have a test for some code path that requires
+    a GPU, but there's no GPU on the machine, the test might check for a
+    GPU and exit early with "success".
+
+If you want to be able to determine a global picture of which tests
+were disabled, you can either parse BUILD files, expectations and filter
+files, and source code to try and figure that out, or require the tests be
+present in test binaries (i.e., not compiled out) and then run the test
+binaries in order to collect the lists of disabled tests and report them
+to a central system.
+
+Parsing code can be straightforward for some types of tests, but
+difficult-to-impractical to do correctly for others.
diff --git a/chromium/docs/testing/testing_in_chromium.md b/chromium/docs/testing/testing_in_chromium.md
index 9ba7909c032..b7e97bed0f5 100644
--- a/chromium/docs/testing/testing_in_chromium.md
+++ b/chromium/docs/testing/testing_in_chromium.md
@@ -149,13 +149,15 @@ Go to [code coverage dashboard](https://analysis.chromium.org/p/chromium/coverag
 
 ## How to deal with flaky tests
 
-Go to [Flaky portal] to find the report about the flaky tests in your projects.
+Go to [Flake Portal] to find reports about flaky tests in your projects.
 
-If you can not fix the flaky tests in a short time, consider to disable it first,
-then fix it later. [How do I disable a flaky test] is the instruction about how to disable a flaky test.
-
->TODO: add the link to the instruction about how to reproduce/debug/verify flaky tests.
+* [Addressing Flaky GTests](./gtest_flake_tips.md)
+* [Addressing Flaky Web Tests](./web_tests_addressing_flake.md)
+* [Addressing Flaky WPTs](./web_platform_tests_addressing_flake.md)
 
+If you cannot fix a flaky test in a short timeframe, disable it first to reduce
+development pain for other and then fix it later. "[How do I disable a flaky
+test]" has instructions on how to disable a flaky test.
 
 [gtest]: https://github.com/google/googletest
 [Simple gtests]: https://github.com/google/googletest/blob/master/googletest/docs/primer.md#simple-tests
@@ -167,7 +169,7 @@ then fix it later. [How do I disable a flaky test] is the instruction about how
 [Tast]: https://chromium.googlesource.com/chromiumos/platform/tast/+/HEAD/README.md
 [Web Tests]: ./web_tests.md
 [crbug/611756]: https://bugs.chromium.org/p/chromium/issues/detail?id=611756
-[Flaky portal]: https://analysis.chromium.org/p/chromium/flake-portal
+[Flake Portal]: https://analysis.chromium.org/p/chromium/flake-portal
 [Write Fuzz Target]: https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/getting_started.md#write-fuzz-target
 [Telemetry: Run benchmarks locally]: https://chromium.googlesource.com/catapult/+/HEAD/telemetry/docs/run_benchmarks_locally.md
 [Run fuzz target locally]: https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/getting_started.md#build-and-run-fuzz-target-locally
diff --git a/chromium/docs/testing/web_platform_tests_addressing_flake.md b/chromium/docs/testing/web_platform_tests_addressing_flake.md
new file mode 100644
index 00000000000..5b6401f1eb5
--- /dev/null
+++ b/chromium/docs/testing/web_platform_tests_addressing_flake.md
@@ -0,0 +1,42 @@
+# Addressing Flaky WPTs
+
+This document provides tips and tricks for reproducing and debugging flakes in
+[Web Platform Tests](web_platform_tests.md) (WPTs). As WPTs are a form of Web
+Test, you may also wish to refer to the documentation on [Addressing Flaky Web
+Tests](web_tests_addressing_flake.md).
+
+## Debugging flaky WPTs
+
+See also the documentation in [Addressing Flaky Web
+Tests](web_tests_addressing_flake.md#Debugging-flaky-Web-Tests).
+
+### Loading WPT tests directly in content\_shell
+
+WPT tests have to be loaded from a server, `wptserve`, to run properly. In a
+terminal, run:
+
+```
+./third_party/blink/tools/run_blink_wptserve.py
+```
+
+This will start the necessary server(s), and print the ports they are listening
+on. Most tests can just be loaded over the main HTTP server (usually
+`http://localhost:8001`), although some may require using the HTTPS server
+instead.
+
+To load a WPT test in content\_shell, run:
+
+```
+out/Default/content_shell http://localhost:8001/path/to/test.html
+```
+
+Here, the `path/to/test.html` is relative to the root of
+`third_party/blink/web_tests/external/wpt`, e.g. `dom/historical.html`.
+
+**Caveat**: As with all Web Tests, running `content_shell` like this is not
+equivalent to what `run_web_tests.py` runs. See the same section in [Addressing
+Flaky Web
+Tests](web_tests_addressing_flake.md#Loading-the-test-directly-in-content_shell)
+for more details and some suggestions. In addition to that list, some WPTs
+(usually security-related) also expect a real domain and may behave differently
+when loaded from localhost.
diff --git a/chromium/docs/testing/web_platform_tests_wptrunner.md b/chromium/docs/testing/web_platform_tests_wptrunner.md
new file mode 100644
index 00000000000..54120ac8a70
--- /dev/null
+++ b/chromium/docs/testing/web_platform_tests_wptrunner.md
@@ -0,0 +1,140 @@
+# Using upstream wptrunner in Chromium (experimental)
+
+This page documents the *experimental* support for using the upstream
+[`wptrunner`](https://github.com/web-platform-tests/wpt/tree/master/tools/wptrunner/)
+tooling for running WPT tests in Chromium (vs the [current
+approach](web_platform_tests.md#Running-tests) that uses `run_web_tests.py`).
+
+It is written as a user guide. For technical details on the project, see the
+[design doc](https://docs.google.com/document/d/1Pq5fxR1t2JzOVPynqeRpRS4bM4QO_Z1um0Q_RiR5ETA/edit).
+
+[TOC]
+
+## Differences versus `run_web_tests.py`
+
+The main differences between `run_web_tests.py` and `wptrunner` are that:
+
+1. `wptrunner` runs the full `chrome` binary, rather than the stripped-down
+   `content_shell`, and
+1. `wptrunner` communicates with the binary via WebDriver (`chromedriver`),
+   instead of talking directly to the browser binary.
+
+These differences mean that any feature that works on upstream WPT today (e.g.
+print-reftests) should work in `wptrunner`, but conversely features available to
+`run_web_tests.py` (e.g. the `internals` API) are not yet available to
+`wptrunner`.
+
+## Running tests locally
+
+*** note
+**NOTE**: Running locally is an area of active development, so the following
+instructions may be out of date.
+***
+
+The runner script is
+[`testing/scripts/run_wpt_tests.py`](https://source.chromium.org/chromium/chromium/src/+/master:testing/scripts/run_wpt_tests.py).
+Before running the script, you must have built the necessary ninja targets:
+
+```
+autoninja -C out/Release wpt_tests_isolate
+```
+
+To run the script, you must enter the `testing/scripts/` directory before
+executing it:
+
+```
+cd testing/scripts
+./run_wpt_tests.py [test list]
+```
+
+The list of tests should be given relative to `external/wpt/`, e.g.
+`webauthn/createcredential-timeout.https.html`. Directories are also accepted.
+Omitting the test list will run all WPT tests.
+
+Results from the run are placed in your build folder, in a folder called
+`layout-test-results` (e.g. `../../out/Release/layout-test-results/`). Logs from
+the browser should be shown by the runner as it executes each test.
+
+Useful flags:
+
+* `-t/--target`: select which `src/out/` sub-directory to use, e.g. `-t Debug`.
+  Defaults to `Release`.
+* `--help`: show the help text
+
+## The MVP bots
+
+As of Q4 2020, an MVP of wptrunner in Chromium is being run with two customer
+teams: Web Payments and Web Identity. For these teams, two **Linux-only** bots
+have been brought up:
+
+* [linux-wpt-identity-fyi-rel](https://ci.chromium.org/p/chromium/builders/ci/linux-wpt-identity-fyi-rel),
+  which runs tests under `external/wpt/webauthn/`.
+* [linux-wpt-payments-fyi-rel](https://ci.chromium.org/p/chromium/builders/ci/linux-wpt-payments-fyi-rel),
+  which runs tests under `external/wpt/payment-{handler, method-basic-card,
+  request}`.
+
+These bots run on the waterfall, but can also be run on CLs by clicking the
+`Choose Tryjobs` button in Gerrit followed by searching for the bot name in the
+modal dialog that appears. One can also include the tag `Cq-Include-Trybots:
+luci.chromium.try:linux-wpt-identity-fyi-rel` (or payments) in the description
+for the CL, which will make the bot mandatory for that CL.
+
+Results for the bots use the existing layout test results viewer
+([example](https://test-results.appspot.com/data/layout_results/linux-wpt-identity-fyi-rel/201/wpt_tests_suite/layout-test-results/results.html)).
+
+## Expectations and baseline files
+
+[Similar to `run_web_tests.py`](web_test_expectations.md), `wptrunner` offers
+the ability to add an expected status for a test or provide a baseline file that
+codifies what the output result should be.
+
+By default `wptrunner` will inherit expected statuses from `TestExpecations`.
+This can currently be overridden by adding an entry to the
+[`WPTOverrideExpectations`](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/web_tests/WPTOverrideExpectations)
+file when `wptrunner` has a different result than `run_web_tests.py`.
+`WPTOverrideExpectations` is however [deprecated](https://crbug.com/1035911),
+and the preferred method for specifying expected results for `wptrunner` is to
+use baseline files (which will also override a TestExpectation entry for the
+test).
+
+Baseline files for `wptrunner` use a different filename and format than
+the `-expected.txt` files used by `run_web_tests.py`. The ini-like baseline format is
+[documented here](https://web-platform-tests.org/tools/wptrunner/docs/expectation.html),
+and baseline files should be placed alongside the test with an `.ini` suffix:
+
+```
+external/wpt/folder/my-test.html
+external/wpt/folder/my-test-expected.txt <-- run_web_tests.py baseline
+external/wpt/folder/my-test.html.ini <-- wptrunner baseline
+```
+
+We currently do not support the full ini-like format that upstream WPT does;
+most notably we have chosen not to support dynamic conditionals (such as
+platform checks). Most `.ini` baseline files in Chromium should have the form:
+
+```
+[my-test.html]
+  expected: OK
+
+  [First subtest name]
+    expected: FAIL
+    message: The failure message, e.g. assert_false didn't work
+
+  [Second subtest name]
+    expected: PASS
+```
+
+*** note
+**TODO**: Explain how .any.js and variants work in this world.
+***
+
+## Known issues
+
+* There is no debugging support in `run_wpt_tests.py` today. In the future, we
+  intend to allow pausing the browser after each test, and (long-term) intend to
+  support hooking up gdb to test runs.
+* There is not yet support for non-Linux platforms. We would love for you to try
+  it on other operating systems and file bugs against us if it doesn't work!
+
+Please [file bugs and feature requests](https://crbug.com/new) against
+`Blink>Infra>Ecosystem`, tagging the title with `[wptrunner]`.
diff --git a/chromium/docs/testing/web_tests_addressing_flake.md b/chromium/docs/testing/web_tests_addressing_flake.md
new file mode 100644
index 00000000000..33ca33d1c13
--- /dev/null
+++ b/chromium/docs/testing/web_tests_addressing_flake.md
@@ -0,0 +1,125 @@
+# Addressing Flaky Web Tests
+
+This document provides tips and tricks for reproducing and debugging flakes in
+[Web Tests](web_tests.md). If you are debugging a flaky Web Platform Test (WPT),
+you may wish to check the specific [Addressing Flaky
+WPTs](web_platform_tests_addressing_flake.md) documentation.
+
+This document assumes you are familiar with running Web Tests via
+`run_web_tests.py`; if you are not then [see
+here](web_tests.md#Running-Web-Tests).
+
+[TOC]
+
+## Understanding builder results
+
+Often (e.g. by Flake Portal), you will be pointed to a particular build in which
+your test has flaked. You will need the name of the specific build step that has
+flaked; usually for Web Tests this is `blink_web_tests` but there are variations
+(e.g. `not_site_per_process_blink_web_tests`).
+
+On the builder page, find the appropriate step:
+
+![web_tests_blink_web_tests_step]
+
+While you can examine the individual shard logs to find your test output, it is
+easier to view the consolidated information, so scroll down to the **archive
+results for blink\_web\_tests** step and click the `layout_test_results` link:
+
+![web_tests_archive_blink_web_tests_step]
+
+This will open a new tab with the results viewer. By default your test should be
+shown, but if it isn't then you can click the 'All' button in the 'Query' row,
+then enter the test filename in the textbox beside 'Filters':
+
+![web_tests_results_viewer_query_filter]
+
+There are a few ways that a Web Test can flake, and what the result means may
+depend on the [test type](writing_web_tests.md#Test-Types):
+
+1. `FAIL` - the test failed. For reference or pixel tests, this means it did not
+   match the reference image. For JavaScript tests, the test either failed an
+   assertion *or* did not match the [baseline](web_test_expectations.md)
+   `-expected.txt` file checked in for it.
+   * For image tests, this status is reported as `IMAGE` (as in an image diff).
+   * For Javascript tests, this status is reported as `TEXT` (as in a text
+     diff).
+1. `TIMEOUT` - the test timed out before producing a result. This may happen if
+   the test is slow and normally runs close to the timeout limit, but is usually
+   caused by waiting on an event that never happens. These unfortunately [do not
+   produce any logs](https://crbug.com/487051).
+1. `CRASH` - the browser crashed while executing the test. There should be logs
+   associated with the crash available.
+1. `PASS` - this can happen! Web Tests can be marked as [expected to
+   fail](web_test_expectations.md), and if they then pass then that is an
+   unexpected result, aka a potential flake.
+
+Clicking on the test row anywhere *except* the test name (which is a link to the
+test itself) will expand the entry to show information about the failure result,
+including actual/expected results and browser logs if they exist.
+
+In the following example, our flaky test has a `FAIL` result which is a flake
+compared to its (default) expected `PASS` result. The test results (`TEXT` - as
+explained above this is equivalent to `FAIL`), output, and browser log links are
+highlighted.
+
+![web_tests_results_viewer_flaky_test]
+
+## Reproducing Web Test flakes
+
+>TODO: document how to get the args.gn that the bot used
+
+>TODO: document how to get the flags that the bot passed to `run_web_tests.py`
+
+### Repeatedly running tests
+
+Flakes are by definition non-deterministic, so it may be necessary to run the
+test or set of tests repeatedly to reproduce the failure. Two flags to
+`run_web_tests.py` can help with this:
+
+* `--repeat-each=N` - repeats each test in the test set N times. Given a set of
+  tests A, B, and C, `--repeat-each=3` will run AAABBBCCC.
+* `--iterations=N` - repeats the entire test set N times. Given a set of tests
+  A, B, and C, `--iterations=3` will run ABCABCABC.
+
+## Debugging flaky Web Tests
+
+>TODO: document how to attach gdb
+
+### Seeing logs from content\_shell
+
+When debugging flaky tests, it can be useful to add `LOG` statements to your
+code to quickly understand test state. In order to see these logs when using
+`run_web_tests.py`, pass the `--driver-logging` flag:
+
+```
+./third_party/blink/tools/run_web_tests.py --driver-logging path/to/test.html
+```
+
+### Loading the test directly in content\_shell
+
+When debugging a specific test, it can be useful to skip `run_web_tests.py` and
+directly run the test under `content_shell` in an interactive session. For many
+tests, one can just pass the test path to `content_shell`:
+
+```
+out/Default/content_shell third_party/blink/web_tests/path/to/test.html
+```
+
+**Caveat**: running tests like this is not equivalent to `run_web_tests.py`,
+which passes the `--run-web-tests` flag to `content_shell`. The
+`--run-web-tests` flag enables a lot of testing-only code in `content_shell`,
+but also runs in a non-interactive mode.
+
+Useful flags to pass to get `content_shell` closer to the `--run-web-tests` mode
+include:
+
+* `--enable-blink-test-features` - enables status=test and status=experimental
+  features from `runtime_enabled_features.json5`.
+
+>TODO: document how to deal with tests that require a server to be running
+
+[web_tests_blink_web_tests_step]: images/web_tests_blink_web_tests_step.png
+[web_tests_archive_blink_web_tests_step]: images/web_tests_archive_blink_web_tests_step.png
+[web_tests_results_viewer_query_filter]: images/web_tests_results_viewer_query_filter.png
+[web_tests_results_viewer_flaky_test]: images/web_tests_results_viewer_flaky_test.png
diff --git a/chromium/docs/ui/DIR_METADATA b/chromium/docs/ui/DIR_METADATA
new file mode 100644
index 00000000000..2769d07edc7
--- /dev/null
+++ b/chromium/docs/ui/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "UI"
+}
\ No newline at end of file
diff --git a/chromium/docs/ui/OWNERS b/chromium/docs/ui/OWNERS
deleted file mode 100644
index e7169536f86..00000000000
--- a/chromium/docs/ui/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: UI
diff --git a/chromium/docs/ui/android/mvc_architecture_tutorial.md b/chromium/docs/ui/android/mvc_architecture_tutorial.md
index dfd06e58078..365c89c573e 100644
--- a/chromium/docs/ui/android/mvc_architecture_tutorial.md
+++ b/chromium/docs/ui/android/mvc_architecture_tutorial.md
@@ -24,21 +24,19 @@ The class responsible for setting up the component. This should be the only publ
 ```java
 public class SimpleProgressCoordinator {
 
-   private SimpleProgressMediator mMediator;
+   private final SimpleProgressMediator mMediator;
+   private final View mView;
 
-   public SimpleProgressCoordinator (Tab tabProgressBarIsFor) {
+   public SimpleProgressCoordinator (Tab tabProgressBarIsFor, Context context) {
 
        PropertyModel model = new PropertyModel.Builder(SimpleProgressProperties.ALL_KEYS)
                .with(SimpleProgressProperties.PROGRESS_FRACTION, 0f)
                .with(SimpleProgressProperties.FOREGROUND_COLOR, Color.RED)
                .build();
 
-       // This view can come from multiple places, in this case we find it in the existing
-       // view hierarchy.
-       View view = tabProgressBarIsFor.getActivity().findViewById(
-               R.id.my_simple_progress_bar);
+       mView = LayoutInflater.from(context).inflate(R.layout.my_simple_progress_bar);
 
-       PropertyModelChangeProcessor.create(model, view, SimpleProgressViewBinder::bind);
+       PropertyModelChangeProcessor.create(model, mView, SimpleProgressViewBinder::bind);
 
        mMediator = new SimpleProgressMediator(model, tabProgressBarIsFor);
    }
@@ -46,8 +44,13 @@ public class SimpleProgressCoordinator {
    public void destroy() {
        mMediator.destroy();
    }
+
+   public View getView() {
+       return mView;
+   }
 }
 ```
+Note that there are several ways to acquire the view. If this MVC component owns its own layout file, then it should inflate the view, as shown above. #getView() allows the parent component's coordinator to add this component's view to the hierarchy. However, if the desired view for this MVC component is part of some other parent component's layout file, then the parent component should be responsible for calling findViewById() and passing the right view into this coordinator. See [this email thread](http://g/clank-frontend/u8x2PBa5EfI) for related discussion.
 
 #### SimpleProgressMediator
 The class that handles all of the signals coming from the outside world. External classes should never interact with this class directly.
@@ -55,9 +58,8 @@ The class that handles all of the signals coming from the outside world. Externa
 ```java
 class SimpleProgressMediator extends EmptyTabObserver {
 
-   private PropertyModel mModel;
-
-   private Tab mObservedTab;
+   private final PropertyModel mModel;
+   private final Tab mObservedTab;
 
    public SimpleProgressMediator(PropertyModel model, Tab tabProgressBarIsFor) {
        mModel = model;
@@ -118,4 +120,3 @@ class SimpleProgressProperties {
     public static final PropertyKey[] ALL_KEYS = {PROGRESS_FRACTION, FOREGROUND_COLOR};
 }
 ```
-
diff --git a/chromium/docs/ui/android/night_mode.md b/chromium/docs/ui/android/night_mode.md
index 4d1a0bf95b4..284ad5ef5b3 100644
--- a/chromium/docs/ui/android/night_mode.md
+++ b/chromium/docs/ui/android/night_mode.md
@@ -115,7 +115,7 @@ If adding a new theme, make sure the parent (or any indirect ancestor) theme of
   * `RemoteView` is an exception. See [RemoteViewsWithNightModeInflater.java](https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/night_mode/RemoteViewsWithNightModeInflater.java) for details.
 * Make sure color resources are accessed from `Activity` or `View` context instead of `Application` context
 * Check whether `Configuration.uiMode & UI_MODE_NIGHT_MASK` gives the correct UI night mode
-  * If uiMode is not correct, it could be a support library issue or an Android framework issue. You can contact chrome-android-app@chromium.org for help.
+  * If uiMode is not correct, it could be a support library issue or an Android framework issue. You can contact clank-app-team@google.com for help.
 
 ## Test new features in night mode
 ### Automatic Testing
diff --git a/chromium/docs/ui/create/examples/theme_aware.md b/chromium/docs/ui/create/examples/theme_aware.md
index ac71db13837..36e4152bcd1 100644
--- a/chromium/docs/ui/create/examples/theme_aware.md
+++ b/chromium/docs/ui/create/examples/theme_aware.md
@@ -92,8 +92,7 @@ theme changes, including when a `View` is first shown.
 
 
 ``` cpp
-class ThemeTrackingCheckbox : public views::Checkbox,
-                              public views::ButtonListener {
+class ThemeTrackingCheckbox : public views::Checkbox {
  public:
   explicit ThemeTrackingCheckbox(const base::string16& label)
       : Checkbox(label, this) {}
@@ -110,8 +109,7 @@ class ThemeTrackingCheckbox : public views::Checkbox,
     SetChecked(GetNativeTheme()->ShouldUseDarkColors());
   }
 
-  // views::ButtonListener:
-  void ButtonPressed(views::Button* sender, const ui::Event& event) override {
+  void ButtonPressed() {
     GetNativeTheme()->set_use_dark_colors(GetChecked());
 
     // An OS or Chrome theme change would do this automatically.
@@ -138,7 +136,9 @@ theme changes.
 
 ``` cpp
 AddChildView(std::make_unique<TextVectorImageButton>(
-      this, l10n_util::GetStringUTF16(IDS_COLORED_DIALOG_CHOOSER_BUTTON),
+      base::BindRepeating(&ColoredDialogChooser::ButtonPressed,
+                          base::Unretained(this)),
+      l10n_util::GetStringUTF16(IDS_COLORED_DIALOG_CHOOSER_BUTTON),
       views::kInfoIcon));
 ```
 
@@ -153,10 +153,10 @@ change.
 ``` cpp
 class TextVectorImageButton : public views::MdTextButton {
 public:
- TextVectorImageButton(ButtonListener* listener,
+ TextVectorImageButton(PressedCallback callback,
                        const base::string16& text,
                        const gfx::VectorIcon& icon)
-     : MdTextButton(listener, text), icon_(icon) {}
+     : MdTextButton(std::move(callback), text), icon_(icon) {}
  TextVectorImageButton(const TextVectorImageButton&) = delete;
  TextVectorImageButton& operator=(const TextVectorImageButton&) = delete;
  ~TextVectorImageButton() override = default;
diff --git a/chromium/docs/ui/learn/bestpractices/layout.md b/chromium/docs/ui/learn/bestpractices/layout.md
index 5740c73dd03..37bc61c3752 100644
--- a/chromium/docs/ui/learn/bestpractices/layout.md
+++ b/chromium/docs/ui/learn/bestpractices/layout.md
@@ -512,13 +512,12 @@ in clearer code.
 // |           | subtitle            |                |
 // +-----------+---------------------+----------------+
 HoverButton::HoverButton(
-    views::ButtonListener* button_listener,
+    ...
     std::unique_ptr<views::View> icon_view,
     const base::string16& title,
     const base::string16& subtitle,
     std::unique_ptr<views::View> secondary_view,
-    bool resize_row_for_secondary_view,
-    bool secondary_view_can_process_events) {
+    ...) {
   ...
   views::GridLayout* grid_layout =
       SetLayoutManager(
@@ -591,13 +590,12 @@ HoverButton::HoverButton(
 // |           | subtitle            |                |
 // +-----------+---------------------+----------------+
 HoverButton::HoverButton(
-    views::ButtonListener* button_listener,
+    ...
     std::unique_ptr<views::View> icon_view,
     const base::string16& title,
     const base::string16& subtitle,
     std::unique_ptr<views::View> secondary_view,
-    bool resize_row_for_secondary_view,
-    bool secondary_view_can_process_events) {
+    ...) {
   ...
   SetLayoutManager(
       std::make_unique<views::FlexLayout>())
diff --git a/chromium/docs/ui/learn/bestpractices/ownership.md b/chromium/docs/ui/learn/bestpractices/ownership.md
index e1f1482d96d..c845ff42350 100644
--- a/chromium/docs/ui/learn/bestpractices/ownership.md
+++ b/chromium/docs/ui/learn/bestpractices/ownership.md
@@ -289,8 +289,7 @@ destroyed:
 #####
 
 ``` cpp
-class CastDialogNoSinksView
-    : public views::View, public views::ButtonListener {
+class CastDialogNoSinksView ... {
   ...
  private:
   base::WeakPtrFactory<CastDialogNoSinksView>
@@ -313,8 +312,7 @@ CastDialogNoSinksView::CastDialogNoSinksView(
 #####
 
 ``` cpp
-class CastDialogNoSinksView
-    : public views::View, public views::ButtonListener {
+class CastDialogNoSinksView ... {
   ...
  private:
   base::OneShotTimer timer_;
diff --git a/chromium/docs/ui/views/DIR_METADATA b/chromium/docs/ui/views/DIR_METADATA
new file mode 100644
index 00000000000..1aa4f31fa42
--- /dev/null
+++ b/chromium/docs/ui/views/DIR_METADATA
@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Internals>Views"
+}
\ No newline at end of file
diff --git a/chromium/docs/ui/views/OWNERS b/chromium/docs/ui/views/OWNERS
deleted file mode 100644
index ad039d74d10..00000000000
--- a/chromium/docs/ui/views/OWNERS
+++ /dev/null
@@ -1 +0,0 @@
-# COMPONENT: Internals>Views
diff --git a/chromium/docs/vscode.md b/chromium/docs/vscode.md
index 7ddc8192392..523473ff3c6 100644
--- a/chromium/docs/vscode.md
+++ b/chromium/docs/vscode.md
@@ -25,6 +25,7 @@ Here's what works well:
     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.
+    *   For more information on debugging Python code, see [here](vscode_python.md).
 *   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
diff --git a/chromium/docs/vscode_python.md b/chromium/docs/vscode_python.md
new file mode 100644
index 00000000000..47c973bf8f6
--- /dev/null
+++ b/chromium/docs/vscode_python.md
@@ -0,0 +1,55 @@
+# Debugging Chromium Python With The VSCode Debugger
+
+## Before You Begin
+
+1. Patch in [this CL](https://chromium-review.googlesource.com/c/chromium/src/+/2466896).
+2. Run gclient sync.
+
+## Via SSH
+
+SSH is useful if you’re modifying and debugging code on another device, such as
+the desktop sitting at your office desk. To do so:
+
+1. Set up VSCode to work with normal development by following the instructions
+   in the Remote Visual Studio Code section
+   [here](https://docs.google.com/document/d/1ZlG8VQxudxvDs-EtpQvaPVcAPfSMdYlXr42s_487wLo/edit#bookmark=id.j10hyv6nlkws).
+2. Open the Connection Dialog of Chrome’s SSH plugin: ![open
+   dialog](images/vscode_python_connection_dialog.png)
+3. Create a new connection and set the username, hostname, port, and SSH relay
+   server options as you normally would. Then, set SSH arguments to "-2 -L
+   50371:localhost:50371"
+
+    a. You can replace 50371 with a different value, so long as it's consistent
+    with step 7b.
+
+4. Open a connection, and set this window aside.
+5. In VSCode, open the code you want to set a breakpoint in, and add the
+   following:
+
+```
+import debugpy
+
+# Your code here!
+debugpy.listen(50371)
+print("Wait for attach...")
+debugpy.wait_for_attach()
+debugpy.brerakpoint()
+```
+
+Note: The port passed to debugpy.listen() should match the port configured in (3).
+
+6. Click on the Debug tab
+7. Click Run. A dialog will appear asking you to set up a debug configuration.
+   Do so, and select “Remote Debug”.
+
+    a. Leave the hostname as-is
+
+    b. Set the port to 50371
+
+8. Run your program on the remote machine. It should stop executing at “Wait for
+   attach”.
+9. Start the debugger in VSCode. It should attach!
+
+## Locally
+
+Follow the same steps as above, but start from step 5.
diff --git a/chromium/docs/webui_explainer.md b/chromium/docs/webui_explainer.md
index 6d247540630..f62e208a4c7 100644
--- a/chromium/docs/webui_explainer.md
+++ b/chromium/docs/webui_explainer.md
@@ -407,12 +407,12 @@ resource map can be added as follows:
 ```
 
 <a name="SetupWebUIDataSource"></a>
-### webui::SetupWebUIDataSource() and webui::SetupBundledWebUIDataSource()
+### webui::SetupWebUIDataSource()
 
-These methods perform common configuration tasks on a data source for a Web UI
-that uses JS modules. When creating a Web UI that uses JS modules, use these
-utilities instead of duplicating the configuration steps they perform elsewhere.
-Specific setup steps performed by these utilities include:
+This method performs common configuration tasks on a data source for a Web UI
+that uses JS modules. When creating a Web UI that uses JS modules, use this
+utility instead of duplicating the configuration steps it performs elsewhere.
+Specific setup steps include:
 
 * Setting the content security policy to allow the data source to load only
   resources from its own host (e.g. chrome://history), chrome://resources, and
@@ -422,13 +422,7 @@ Specific setup steps performed by these utilities include:
 * Adding the test loader files to the data source, so that test files can be
   loaded as JS modules.
 * Setting the resource to load for the empty path.
-
-The version for non-bundled UIs (<code>SetupWebUIDataSource()</code>) also adds
-all resources in a GritResourceMap.
-
-The version for bundled UIs (<code>SetupBundledWebUIDataSource()</code>) adds
-a single specified bundled resource. Note that this version is only defined when
-the optimize_webui build flag is enabled.
+* Adding all resources from a GritResourceMap.
 
 ## Browser (C++) &rarr; Renderer (JS)
 
diff --git a/chromium/docs/webui_in_components.md b/chromium/docs/webui_in_components.md
index 67b0154e4c9..dd84e4792fd 100644
--- a/chromium/docs/webui_in_components.md
+++ b/chromium/docs/webui_in_components.md
@@ -31,6 +31,7 @@ WebUI resources in `components/` will be added in your specific project folder.
  <link rel="stylesheet" href="hello_world.css">
  <script src="chrome://resources/js/cr.js"></script>
  <script src="chrome://resources/js/load_time_data.js"></script>
+ <script src="chrome://resources/js/assert.js"></script>
  <script src="chrome://resources/js/util.js"></script>
  <script src="strings.js"></script>
  <script src="hello_world.js"></script>
diff --git a/chromium/docs/win_cross.md b/chromium/docs/win_cross.md
index 7b3d3af60b2..53195762539 100644
--- a/chromium/docs/win_cross.md
+++ b/chromium/docs/win_cross.md
@@ -82,6 +82,10 @@ Add `target_os = "win"` to your args.gn.  Then just build, e.g.
 
 ## Goma
 
+*** note
+**Warning:** This is unsupported and known to not work at times.
+***
+
 For now, one needs to use the rbe backend, not the borg backend
 (default for Googlers).
 Use cloud backend instead.
diff --git a/chromium/docs/windows_build_instructions.md b/chromium/docs/windows_build_instructions.md
index 7497a1e8834..05fe102f0fa 100644
--- a/chromium/docs/windows_build_instructions.md
+++ b/chromium/docs/windows_build_instructions.md
@@ -178,58 +178,6 @@ $ gn gen out/Default
   operating system and CPU.
 * For more info on GN, run `gn help` on the command line or read the [quick
   start guide](https://gn.googlesource.com/gn/+/master/docs/quick_start.md).
-
-### Using the Visual Studio IDE
-
-If you want to use the Visual Studio IDE, use the `--ide` command line
-argument to `gn gen` when you generate your output directory (as described on
-the [get the code](https://dev.chromium.org/developers/how-tos/get-the-code)
-page):
-
-```shell
-$ gn gen --ide=vs out\Default
-$ devenv out\Default\all.sln
-```
-
-GN will produce a file `all.sln` in your build directory. It will internally
-use Ninja to compile while still allowing most IDE functions to work (there is
-no native Visual Studio compilation mode). If you manually run "gen" again you
-will need to resupply this argument, but normally GN will keep the build and
-IDE files up to date automatically when you build.
-
-The generated solution will contain several thousand projects and will be very
-slow to load. Use the `--filters` argument to restrict generating project files
-for only the code you're interested in. Although this will also limit what
-files appear in the project explorer, debugging will still work and you can
-set breakpoints in files that you open manually. A minimal solution that will
-let you compile and run Chrome in the IDE but will not show any source files
-is:
-
-```
-$ gn gen --ide=vs --filters=//chrome --no-deps out\Default
-```
-
-You can selectively add other directories you care about to the filter like so:
-`--filters=//chrome;//third_party/WebKit/*;//gpu/*`.
-
-There are other options for controlling how the solution is generated, run `gn
-help gen` for the current documentation.
-
-By default when you start debugging in Visual Studio the debugger will only
-attach to the main browser process. To debug all of Chrome, install
-[Microsoft's Child Process Debugging Power Tool](https://blogs.msdn.microsoft.com/devops/2014/11/24/introducing-the-child-process-debugging-power-tool/).
-You will also need to run Visual Studio as administrator, or it will silently
-fail to attach to some of Chrome's child processes.
-
-It is also possible to debug and develop Chrome in Visual Studio without a
-solution file. Simply "open" your chrome.exe binary with
-`File->Open->Project/Solution`, or from a Visual Studio command prompt like
-so: `devenv /debugexe out\Debug\chrome.exe <your arguments>`. Many of Visual
-Studio's code editing features will not work in this configuration, but by
-installing the [VsChromium Visual Studio Extension](https://chromium.github.io/vs-chromium/)
-you can get the source code to appear in the solution explorer window along
-with other useful features such as code search.
-
 ### Faster builds
 
 * Reduce file system overhead by excluding build directories from
@@ -418,7 +366,7 @@ To update an existing checkout, you can run
 
 ```shell
 $ git rebase-update
-$ gclient sync
+$ gclient sync -D
 ```
 
 The first command updates the primary Chromium source repository and rebases
@@ -426,5 +374,70 @@ any of your local branches on top of tip-of-tree (aka the Git branch `origin/mas
 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 the subrepositories to the appropriate versions and
-re-runs the hooks as needed.
+The second command syncs the subrepositories to the appropriate versions,
+deleting those that are no longer needed, and re-runs the hooks as needed.
+
+### Editing and Debugging With the Visual Studio IDE
+
+You can use the Visual Studio IDE to edit and debug Chrome, with or without
+Intellisense support.
+
+#### Using Visual Studio Intellisense
+
+If you want to use Visual Studio Intellisense when developing Chromium, use the
+`--ide` command line argument to `gn gen` when you generate your output
+directory (as described on the [get the code](https://dev.chromium.org/developers/how-tos/get-the-code)
+page):
+
+```shell
+$ gn gen --ide=vs out\Default
+$ devenv out\Default\all.sln
+```
+
+GN will produce a file `all.sln` in your build directory. It will internally
+use Ninja to compile while still allowing most IDE functions to work (there is
+no native Visual Studio compilation mode). If you manually run "gen" again you
+will need to resupply this argument, but normally GN will keep the build and
+IDE files up to date automatically when you build.
+
+The generated solution will contain several thousand projects and will be very
+slow to load. Use the `--filters` argument to restrict generating project files
+for only the code you're interested in. Although this will also limit what
+files appear in the project explorer, debugging will still work and you can
+set breakpoints in files that you open manually. A minimal solution that will
+let you compile and run Chrome in the IDE but will not show any source files
+is:
+
+```
+$ gn gen --ide=vs --filters=//chrome --no-deps out\Default
+```
+
+You can selectively add other directories you care about to the filter like so:
+`--filters=//chrome;//third_party/WebKit/*;//gpu/*`.
+
+There are other options for controlling how the solution is generated, run `gn
+help gen` for the current documentation.
+
+#### Using Visual Studio without Intellisense
+
+It is also possible to debug and develop Chrome in Visual Studio without the
+overhead of a multi-project solution file. Simply "open" your chrome.exe binary
+with `File->Open->Project/Solution`, or from a Visual Studio command prompt like
+so: `devenv /debugexe out\Debug\chrome.exe <your arguments>`. Many of Visual
+Studio's code exploration features will not work in this configuration, but by
+installing the [VsChromium Visual Studio Extension](https://chromium.github.io/vs-chromium/)
+you can get the source code to appear in the solution explorer window along
+with other useful features such as code search. You can add multiple executables
+of interest (base_unittests.exe, browser_tests.exe) to your solution with
+`File->Add->Existing Project...` and change which one will be debugged by
+right-clicking on them in `Solution Explorer` and selecting `Set as Startup
+Project`. You can also change their properties, including command line
+arguments, by right-clicking on them in `Solution Explorer` and selecting
+`Properties`.
+
+By default when you start debugging in Visual Studio the debugger will only
+attach to the main browser process. To debug all of Chrome, install
+[Microsoft's Child Process Debugging Power Tool](https://blogs.msdn.microsoft.com/devops/2014/11/24/introducing-the-child-process-debugging-power-tool/).
+You will also need to run Visual Studio as administrator, or it will silently
+fail to attach to some of Chrome's child processes.
+
diff --git a/chromium/docs/windows_shortcut_and_taskbar_handling.md b/chromium/docs/windows_shortcut_and_taskbar_handling.md
new file mode 100644
index 00000000000..655d6ab8226
--- /dev/null
+++ b/chromium/docs/windows_shortcut_and_taskbar_handling.md
@@ -0,0 +1,75 @@
+# Windows Shortcut and Pinned Taskbar Icon handling
+
+When Chrome is installed on Windows, it creates a shortcut on the desktop that
+launches Chrome. It also adds the same shortcut to the start menu. These
+shortcuts do not specify a profile, so they launch Chrome with the most recently
+used profile. 
+
+Windows allows users to pin applications to the taskbar. When a user
+pins an application to the taskbar, Windows looks for a desktop shortcut that
+matches the application, and if it finds one, it creates a .lnk file in the
+directory
+`<user dir>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar.`
+If it does not find a matching desktop shortcut, it creates an 8-hex-digit
+sub-directory of
+`<user dir>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\ImplicitAppShortcuts\`
+and puts the .lnk file in that directory. For example, 3ffff1b1b170b31e.
+
+App windows on Windows have an
+[App User Model ID (AUMI)](https://docs.microsoft.com/en-us/windows/win32/shell/appids)
+property. For Chrome windows, this is set in
+[BrowserWindowPropertyManager::UpdateWindowProperties](https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/ui/views/frame/browser_window_property_manager_win.cc?q=BrowserWindowPropertyManager::UpdateWindowProperties),
+when a window is opened. Windows desktop shortcuts have an app model property,
+and this should match the open window's AUMI. Windows groups open windows with
+the same AUMI to a taskbar icon.
+
+There are two kinds of Chrome windows with AUMI's: browser windows, and app
+windows, which include web apps, and extensions, i.e., windows opened via
+--app-id or --app.
+
+[GetAppUserModelIdForBrowser](https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/shell_integration_win.cc?q=GetAppUserModelIdForBrowser)
+constructs an AUMI for a browser window and
+[GetAppUserModelIdForApp](https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/shell_integration_win.cc?q=GetAppUserModelIdForApp)
+constructs an AUMI for an app window. Each calls
+[ShellUtil::BuildAppUserModelId](https://source.chromium.org/chromium/chromium/src/+/master:chrome/installer/util/shell_util.cc;q=ShellUtil::BuildAppUserModelId)
+to construct the AUMI out of component strings.
+
+All AUMI's start with the base app id,
+[install_static::GetBaseAppId](https://source.chromium.org/chromium/chromium/src/+/master:chrome/install_static/install_util.cc?q=install_static::GetBaseAppId).
+This varies for different Chrome channels (e.g., Canary vs. Stable) and
+different Chromium-based browsers (e.g., Chrome vs. Chromium).
+
+The AUMI for a browser app has the format:
+`<BaseAppId>.<app_name>[.<profile_name>]`.
+profile_name is only appended when it's not the default profile.
+
+The AUMI for a Chrome browser window has the format:
+`<BaseAppId>[browser_suffix][.profile_name]`.
+profile_name is only appended when it's not the default profile.
+browser_suffix is only appended to the BaseAppId if the installer
+has set the kRegisterChromeBrowserSuffix command line switch, e.g.,
+on user-level installs.
+
+Since AUMI's for browser and app windows include the profile_name, each
+profile's windows will be grouped together on the taskbar.
+
+shell_integration_win.cc has a function [GetExpectedAppId](https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/shell_integration_win.cc?q=GetExpectedAppid)
+to determine what the AUMI for a shortcut should be. It also has a function
+[MigrateTaskbarPins](https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/shell_integration_win.cc?q=MigrateTaskbarPins)
+to migrate pinned taskbar icons if the AUMI's need to change.
+
+## Multi-profile Support
+When the user has more than one profile, the shortcuts are renamed to include
+the profile name, e.g., `Chrome.lnk` becomes `<profile name> - Chrome`.  The
+shortcut icons, both desktop and taskbar, are badged with their profile icon.
+This badged icon is also used in the tab preview for a Chrome window.
+
+## Diagnosing Issues
+To dump a taskbar icon's properties, run this command:
+
+`python \src\chromium\src\chrome\installer\tools\shortcut_properties.py --dump-all <user dir>\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar`
+
+This shows you the properties of all the taskbar pinned icons. If the taskbar
+icon is in a subdirectory of ImplicitApps, pass that directory to
+shortcut_properties.py.
+