BASELINE: Update Chromium to 92.0.4515.166

Change-Id: I42a050486714e9e54fc271f2a8939223a02ae364

7 files changed, 284 insertions, 28 deletions

diff --git a/chromium/docs/speed/addressing_performance_regressions.md b/chromium/docs/speed/addressing_performance_regressions.md
index c4b8fcc4c7a..3c3fdcee305 100644
--- a/chromium/docs/speed/addressing_performance_regressions.md
+++ b/chromium/docs/speed/addressing_performance_regressions.md
@@ -18,6 +18,8 @@ Each test has an owner, named in
 [this spreadsheet](https://docs.google.com/spreadsheets/d/1xaAo0_SU3iDfGdqDJZX_jRV0QtkufwHUKH3kQKF3YQs/edit#gid=0),
 who you can cc on a performance bug if you have questions.
 
+(Googlers only) For broad overview of various performance tools available for Chrome and where lab perf fits in, see [go/chrome-performance-how](http://go/chrome-performance-how).
+
 ## Understanding the bisect results
 
 ### The bug comment
diff --git a/chromium/docs/speed/apk_size_regressions.md b/chromium/docs/speed/apk_size_regressions.md
index a9f2110c4f0..f41bc4a1d2b 100644
--- a/chromium/docs/speed/apk_size_regressions.md
+++ b/chromium/docs/speed/apk_size_regressions.md
@@ -135,6 +135,8 @@ and [calendar](https://calendar.google.com/calendar/embed?src=c_188b8oq5puj67tl3
    and `Performance-Size` [here](https://bugs.chromium.org/p/chromium/issues/list?q=label:Performance-Sheriff%20label:Performance-Size&sort=-modified).
  * After resolving the bug by finding an owner or debugging or commenting,
    remove the `Performance-Sheriff` label.
+ * Process for Chrome OS bugs is at [go/cros-image-size-triage](https://goto.google.com/cros-image-size-triage).
+   * Generally just expected to ignore these.
 
 ## Step 2: Check Alerts Regularly
 
diff --git a/chromium/docs/speed/binary_size/binary_size_explainer.md b/chromium/docs/speed/binary_size/binary_size_explainer.md
new file mode 100644
index 00000000000..1689830880d
--- /dev/null
+++ b/chromium/docs/speed/binary_size/binary_size_explainer.md
@@ -0,0 +1,237 @@
+# Binary Size Explainer
+
+This document explains the overhead of each kind of binary size, where
+"overhead" is the performance cost of existing (e.g.  does not include the
+overhead of loading an image, just the overhead of an image existing).  This
+document focuses on Android, but several types of size are the same on other
+platforms.
+
+*** note
+See [optimization_advice.md] for ideas on how to reduce
+size.
+***
+
+[optimization_advice.md]: optimization_advice.md
+
+[TOC]
+
+## How big is Chrome?
+
+* Chrome's per-commit size is tracked in [chromeperf](https://chromeperf.appspot.com/report):
+  * For Android, look for "resource\_sizes".
+    * Googlers, see also [go/chromeapksizes], and [go/chromemilestonesizes].
+  * For other platforms: look for "sizes".
+* As of 2019, Chrome for Android (arm32) grows by about 100kb per week.
+* To get a feeling for how large individual features are, open a
+  [milestone size breakdown] and group by "Component" (Googlers only).
+  * For non-googlers, run `//tools/binary_size/supersize archive` on a release
+    build to create a `.size` file, and upload it to [the viewer].
+
+[go/chromeapksizes]: http://go/chromeapksizes
+[go/chromemilestonesizes]: http://go/chromemilestonesizes
+[milestone size breakdown]: https://goto.google.com/chrome-supersize
+[the viewer]: https://chrome-supersize.firebaseapp.com/viewer.html
+
+## Why care about binary size?
+
+* Takes disk space away from users.
+  * Much less so than Chrome's cache, but this is space that cannot be
+    cleared, and on Android is displayed prominently in the Play Store and in
+    system settings.
+* Takes disk space on system images for Android and Chrome OS.
+  * It routinely happens that system images fill up, and all components need
+    to do their part to fit into the space.
+* Binary size is a "proxy metric" for other performance metrics.
+  * It's a metric that is trivial to measure, and correlates to RAM usage,
+    start-up speed etc.  (there are nuances, which we try to capture in this
+    doc).
+* Binary size affects users' perception of Chrome's performance.
+  * E.g. Large app size leads users to think Chrome is "bloated".
+* Binary size is much easier to stay on top of than it is to retroactively fix.
+
+Googlers - see [go/chromebinarysizematters] for more links to studies.
+
+[go/chromebinarysizematters]: http://go/chromebinarysizematters
+
+### How much effort should I spend to reduce binary size?
+
+Chrome is currently not under any hard growth limits, but to mitigate
+unnecessary bloat of this shared resource, everyone should ensure that
+reasonable diligence is taken to minimize growth.
+
+* "Reasonable diligence" requires judgement and varies depending on the change.
+  A rough guideline:
+  * For small (<50kb) increases: spend a day trying to reduce (unless it's obviously not possible).
+  * For larger increases: Try to understand and document why the change requires so much size.
+  * If you are unsure, reach out on [binary-size@] for advice.
+* The [android-binary-size][size_trybot] trybot will alert for single commits that increase
+  binary size on 32-bit Android by more than 16kb.
+  * While such increases are often fine, this helps prevent unexpected
+  increases.
+* It typically takes about a week of engineering time to reduce Android's binary size by 50kb.
+
+[binary-size@]: https://groups.google.com/a/chromium.org/g/binary-size/
+[size_trybot]: /docs/speed/binary_size/android_binary_size_trybot.md
+
+## How Chrome is Packaged
+
+### WebView vs Chrome
+
+Android WebView is used by the majority of Android apps, so overhead (other
+than clean memory) introduced into WebView has a multiplicative effect on the
+OS.  See
+[android\_build\_instructions.md]
+for how packaging of Chrome / WebView changes by OS version.
+
+[android\_build\_instructions.md]: /docs/android_build_instructions.md#Multiple-Chrome-Targets
+
+### APK Splits
+
+Chrome ships as an [Android App Bundle], and consists of several APK splits.
+
+[Android App Bundle]: /docs/android_dynamic_feature_modules.md#about-bundles
+
+#### The "base" split
+
+* Loaded on start-up by every process.
+* Keeping its dex size minimal is crucial, since it has both RAM and start-up
+  overhead _per-renderer_.
+
+#### In the "chrome" feature split
+
+* Loaded on start-up by the browser process.
+* Important to keep dex size small in order to have Chrome start-up quickly,
+  and to minimize our baseline memory requirement.
+
+#### In another feature split
+
+* Since they are loaded on-demand, binary size matters proportionally to the
+  number of users that use the module.
+
+#### In a DFM
+
+* These are feature splits that are not even downloaded until needed. Binary
+  size matters proportionally to the number of users that use the module.
+
+## Types of Overhead
+
+Here we define some terms used to describe overhead.
+
+**Clean Memory:**
+
+* Backed by a file on disk, and mapped to virtual memory via `mmap()`.
+* Shared between processes.
+* Paged into RAM on-demand by the OS.
+* Fast when disk cache is hot, and slower when disk cache is cold.
+
+**Dirty Memory:**
+
+* Not backed by a file, and thus cannot be safely paged out (except to zram)
+
+## Overhead for Each Type of Binary Size
+
+### Native code Size
+
+#### Code (.text)
+
+Machine instructions.
+
+* **RAM:** _Clean Memory_, with good locality thanks to PGO.
+* **Start-up:** No effect beyond page faults.
+
+#### Read-only Data (.rodata)
+
+String literals, global constants, etc.
+
+* **RAM:** _Clean Memory_, with poor locality (most is paged in after a short amount of time)
+* **Start-up:** No effect beyond page faults.
+
+#### Read-only-after-relocated Data (.data.rel.ro)
+
+Read-only data that must be adjusted based on the base load address of the executable.
+
+* **RAM:** _Dirty-ish Memory_. It's complicated.  Refer to
+  [native_relocations.md].
+* **Start-up:** Some overhead. Again, read the linked doc.
+
+[native relocations.md]: /docs/native_relocations.md#why-do-they-matter
+
+#### Mutable Data (.data)
+
+Global non-const variables.
+
+* **RAM:** _Dirty Memory_
+* **Start-up:** The entire section is loaded before any code is run.
+
+### Native resources (.pak)
+
+UI Images, chrome:// pages, UI strings, etc.
+
+* **RAM:** _Clean Memory_
+* **Start-up:** Platform-dependent. None on Android. Page faults on desktop.
+* Locality improved [using an orderfile] on some platforms.
+
+[using an orderfile]: /tools/gritsettings/README.md#:~:text=internal%20translation%20process.-,startup_resources_%5Bplatform%5D.txt,-%3A%20These%20files%20provide
+
+### Android: Java code size (.dex)
+
+Java bytecode in the [DEX file format], stored in `classes.dex`, `classes2.dex`,
+...  When Android installs Chrome, this bytecode is turned into machine code and
+stored as `.odex` & `.vdex` files.  The size of these files depends on the OS
+version and dex compilation profile.  Generally, they are 1x the size of
+uncompressed `.dex` on Android Go, and 4x the size of uncompressed `.dex` on
+other devices.
+
+* **RAM:** Mostly _Clean Memory_, but Some _Dirty Memory_ as well.
+  * E.g.: The number of method declarations (referred to as "method count")
+    directly corresponds to dirty RAM, where 1 entry = 4 bytes (on arm32).
+* **Start-up:** Impact proportional to overall size.  Mitigated by packaging
+  code into [feature splits] when possible.
+
+[DEX file format]: https://source.android.com/devices/tech/dalvik/dex-format
+[feature splits]: /docs/android_dynamic_feature_modules.md#:~:text=files%2C%20known%20as%20%E2%80%9C-,feature%20splits,-%E2%80%9D.%20Feature%20splits%20have
+
+#### More about Method Count
+
+When changing `.java code`, the change in method count is
+[shown in code reviews][size_trybot]. The count is the number of method
+references added/removed after optimization.  Which methods are added/removed
+can be seen in the "APK Breakdown" link by checking "Method Count Mode".
+
+Method count is a useful thing to look at because:
+
+* Each method reference has overhead within the dex file format, and for smallish methods, contributes more to binary size than its corresponding executable code.
+* Method references that survive R8 optimization show how optimizable your abstractions are. Try to use low-overhead (or zero-overhead) abstractions. If you find that you're adding a lot of methods, you should see whether a different abstraction would result in fewer methods.
+
+### Android: Resources
+
+#### resources.arsc
+
+All files within `res/`, as well as individual entries with `res/values` files
+contribute to this file.  It consists of a string table, plus one 2D array
+for each resource type (strings, drawable, etc).  The overhead (not included
+actual data) for each table is: `# [unique configs] * # of resources * sizeof(entry)`.
+
+* **RAM:** _Clean Memory_, with poor locality (most is paged in after a short
+  amount of time)
+* **Start-up:** No effect beyond page faults.
+* Its table-based file format means it's important to keep the number of unique
+  configs as small as possible.
+
+[unique configs]: https://developer.android.com/guide/topics/resources/providing-resources#QualifierRules
+
+#### res/... (drawables/layouts/xml)
+
+Files that are packaged within the `res/` directory of the `.apk`.  These also
+have an entry within `resources.arsc` that maps to them from a resource ID.
+
+* **RAM:** None unless resources are accessed.
+* **Start-up**: None unless resources are accessed.
+
+
+### Other Assets
+
+ICU data, V8 snapshot, etc.
+
+* **RAM:** _Clean Memory_
+* **Start-up:** No effect beyond page faults.
diff --git a/chromium/docs/speed/binary_size/metrics.md b/chromium/docs/speed/binary_size/metrics.md
index 0ec41ce24bf..6d5f2e52966 100644
--- a/chromium/docs/speed/binary_size/metrics.md
+++ b/chromium/docs/speed/binary_size/metrics.md
@@ -39,7 +39,8 @@ For Googlers, more information available at [go/chrome-apk-size](https://goto.go
    * With all native code as the sum of section sizes (except .bss), uncompressed.
      * Why: Removes effects of ELF section alignment.
    * With all dex code as if it were stored uncompressed.
-     * Why: Dex is stored uncompressed on newer Android versions.
+     * Why: Best practice is to store dex uncompressed on Android P and above.
+     * On prior versions, or when stored compressed, dex is extracted upon installation.
    * With all zipalign padding removed.
      * Why: Removes effects of file alignment (esp. relevant because native libraries are 4k-aligned).
    * With size of apk signature block removed.
diff --git a/chromium/docs/speed/binary_size/optimization_advice.md b/chromium/docs/speed/binary_size/optimization_advice.md
index 66156ee1e2c..700869ef7c4 100644
--- a/chromium/docs/speed/binary_size/optimization_advice.md
+++ b/chromium/docs/speed/binary_size/optimization_advice.md
@@ -1,7 +1,6 @@
-# Optimizing Chrome's Image Size
+# Optimizing Chrome's Binary Size
 
-The Chrome image size is important on all platforms as it affects download
-and update times.
+Read first: [binary_size_explainer.md](binary_size_explainer.md)
 
  >
  > This document primarily focuses on Android and Chrome OS where image size
@@ -113,22 +112,6 @@ There are two mechanisms for compressing Chrome l10n files.
 
 ## Android Focused Advice
 
-Googlers: See also [go/abp-performance/apk-size].
-
-[go/abp-performance/apk-size]: https://goto.google.com/abp-performance/apk-size
-
-### How To Tell if It's Worth Spending Time on Binary Size?
-
- * Binary size is a shared resource, and thus its growth is largely due to the
-   tragedy of the commons.
- * It typically takes about a week of engineering time to reduce Android's
-   binary size by 50kb.
- * As of 2019, Chrome for Android (arm32) grows by about 100kb per week.
- * To get a feeling for how large existing features are, refer to the
-   [milestone size breakdowns] and group by "Component".
-
-[milestone size breakdowns]: https://storage.googleapis.com/chrome-supersize/index.html
-
 ### Optimizing Translations (Strings)
 
  * Use [Android System strings](https://developer.android.com/reference/android/R.string.html) where appropriate
@@ -229,6 +212,12 @@ Practical advice:
          a single `base::StringPiece`.
 
 #### Optimizing Java Code
+ * If you're adding a new feature, see if it makes sense for it to be packaged
+   into its own [feature split]. E.g.:
+   * Has a non-trivial amount of Dex (>50kb)
+   * Not needed on startup
+   * Has a small integration surface (calls into it must be done with
+     reflection).
  * Prefer fewer large JNI calls over many small JNI calls.
  * Minimize the use of class initializers (`<clinit>()`).
    * If R8 cannot determine that they are "trivial", they will prevent
@@ -236,8 +225,6 @@ Practical advice:
    * In C++, static objects are created at compile time, but in Java they
      are created by executing code within `<clinit>()`. There is often little
      advantage to initializing class fields statically vs. upon first use.
- * Use `String.format()` instead of concatenation.
-   * Concatenation causes a lot of StringBuilder code to be generated.
  * Try to use default values for fields rather than explicit initialization.
    * E.g. Name booleans such that they start as "false".
    * E.g. Use integer sentinels that have initial state as 0.
@@ -248,12 +235,17 @@ Practical advice:
      `onFinished(bool)`.
    * E.g. rather than have `onTextChanged()`, `onDateChanged()`, ..., have a
      single `onChanged()` that assumes everything changed.
- * Ensure unused code is optimized away by ProGuard / R8.
-   * Add `@CheckDiscard` to methods or classes that you expect R8 to inline.
-   * Add `@RemovableInRelease` to force a method to be a no-op when DCHECKs
-     are disabled.
+ * Ensure unused code is optimized away by R8.
    * See [here][proguard-build-doc] for more info on how Chrome uses ProGuard.
-
+   * Add `@CheckDiscard` to methods or classes that you expect R8 to inline.
+   * Guard code with `BuildConfig.ENABLE_ASSERTS` to strip it in release builds.
+   * Use [//third_party/r8/playground][r8-playground] to figure out how various
+     coding patterns are optimized by R8.
+   * Build with `enable_proguard_obfuscation = false` and use
+     `//third_party/android_sdk/public/build-tools/*/dexdump` to see how code was
+     optimized directly in apk / bundle targets.
+
+[feature split]: /docs/android_dynamic_feature_modules.md
 [proguard-build-doc]: /build/android/docs/java_optimization.md
 [size-trybot]: /tools/binary_size/README.md#Binary-Size-Trybot-android_binary_size
 [diagnose_bloat]: /tools/binary_size/README.md#diagnose_bloat_py
@@ -261,6 +253,7 @@ Practical advice:
 [template_bloat_one]: https://bugs.chromium.org/p/chromium/issues/detail?id=716393
 [template_bloat_two]: https://chromium-review.googlesource.com/c/chromium/src/+/2639396
 [supersize-console]: /tools/binary_size/README.md#Usage_console
+[r8-playground]: /third_party/r8/playground
 
 ### Optimizing Third-Party Android Dependencies
 
diff --git a/chromium/docs/speed/metrics_changelog/2021_05_fid.md b/chromium/docs/speed/metrics_changelog/2021_05_fid.md
new file mode 100644
index 00000000000..778c0de1b0d
--- /dev/null
+++ b/chromium/docs/speed/metrics_changelog/2021_05_fid.md
@@ -0,0 +1,19 @@
+# First Input Delay Changes in Chrome 91
+
+### Disable double-tap-to-zoom on mobile viewports
+
+Double-tap-to-zoom (DTZ) is a gesture used to zoom into text. Previously, DTZ
+was disabled when either zooming was disabled (min-zoom equal to max-zoom) or
+when the content width fits the viewport width. After this change, we also
+disable DTZ when the viewport meta tag specifies `width=device-width` or
+`initial-scale>=1.0`, even when implicitly doing so, like for example in
+`minimum-scale=1.5, maximum-scale=2`.
+
+Because DTZ negatively impacts FID and the amount of pages where DTZ is disabled
+is increased, we expect some sites to see better FID scores.
+
+[Relevant bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1108987)
+
+## When were users affected?
+
+Chrome 91 is currently scheduled to be released the week of July 20, 2021.
diff --git a/chromium/docs/speed/metrics_changelog/fid.md b/chromium/docs/speed/metrics_changelog/fid.md
index 68b1a494acd..d81a7dcea41 100644
--- a/chromium/docs/speed/metrics_changelog/fid.md
+++ b/chromium/docs/speed/metrics_changelog/fid.md
@@ -2,9 +2,11 @@
 
 This is a list of changes to [First Input Delay](https://web.dev/fid).
 
+* Chrome 91
+  * Chrome change affecting metric: [Disable double-tap-to-zoom on mobile viewports](2021_05_fid.md)
 * Chrome 83
   * Metric definition improvement: [First Input Delay includes inputs with delays &lt; 1ms in Chrome User Experience Report](2020_05_fid.md)
 * Chrome 77
   * Metric exposed via API: [First Input Delay](https://web.dev/fid/) available via [Event Timing API](https://github.com/tdresser/event-timing#first-input-timing)
 * Chrome 75
-  * Metric definition improvement: [First Input Delay includes input events that had previously been filtered](2019_07_fid.md)
\ No newline at end of file
+  * Metric definition improvement: [First Input Delay includes input events that had previously been filtered](2019_07_fid.md)