GitLab

Manual reland:
Original CL: https://chromium-review.googlesource.com/c/chromium/src/+/2029609
Revert: https://chromium-review.googlesource.com/c/chromium/src/+/2109970
Reset for revert: flaky DCHECK in AssertExpectedConcurrency
Fix: Avoid calling AssertExpectedConcurrency from ShouldYield.
https://chromium-review.googlesource.com/c/chromium/src/+/2112235

Original Description:
Note: This CL enables feature BlinkHeapConcurrentMarking to get
the desired behavior. However, we should land enabling
BlinkHeapConcurrentMarking on its own first.

active_markers + GlobalPoolSize() is used to determine
the desired number of workers.

NotifyConcurrencyIncrease() is called periodically from
ConcurrentMarkingStep() if GlobalPoolSize() > 0,
to make sure enough workers are scheduled.

Bug: 1046343
Change-Id: I4c36044686128b23fc25f45b99334c219a08cffa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2214908Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779969}

This CL does the following:
1- Adds 'cr-view-manager' to the profile picker.
2- Starts the implementation of the main profile picker screen.
3- Adds the 'Add Space' icon, which will be the entry point for the
profile creation flow.

Bug: 1063856
Change-Id: I626b3ecbc22129e0ad1478c2258812286efe5588
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249781
Commit-Queue: Monica Basta <msalama@chromium.org>
Reviewed-by: Samuel Huang <huangs@chromium.org>
Reviewed-by: Esmael Elmoslimany <aee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779968}

Bug: 1007874
Change-Id: I501a90c677b05c87053a42920ed7eabdd9491752
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2230627
Commit-Queue: Danila Kuzmin <dkuzmin@google.com>
Reviewed-by: Denis Kuznetsov [CET] <antrim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779967}

This method has a single user - it also essentially a pure function.
Fold it.

Bug: 634143
Change-Id: I2c0f9cdc615dcd19f8b1a58ea43cd61066bf9cf7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252078
Auto-Submit: Fredrik Söderquist <fs@opera.com>
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779966}

Add img width to settings/content style to properly scale banner

Bug: 1096441
Change-Id: Ia364223860c88f3aab1dbd273037fb6bba49a274
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252001Reviewed-by: Theodore Olsauskas-Warren <sauski@google.com>
Commit-Queue: Sean Harrison <harrisonsean@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779965}

This CL introduces the handling of showing in-session notifications
when update is required as per the policy but the device is
connected to a metered network or has reached end-of-life(EOL).

In case of metered network -
The notification is to be shown when the policy is received and on the
last day of the deadline. Clicking on the notification button starts
update process over metered connection.
For end-of-life devices -
The notification is to be shown when the policy is received, one week
before deadline and on the last day of the deadline. Clicking on the
notification button opens the enterprise/management info page which
would contain details about the end-of-life of the device.

This detail on the settings page will be implemented in subsequent CL.
New browser and unit tests are also included to verify this behavior.

Bug: 1048607
Change-Id: I4c09a00a50ff1673db1b15e4f05a4a29e825f043
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2245612
Commit-Queue: Saurabh Nijhara <snijhara@google.com>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Roman Sorokin [CET] <rsorokin@chromium.org>
Reviewed-by: Sergey Poromov <poromov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779964}

The addition of a handleBar below the omnibox in the toolbar is
useful to indicate the user that the expanded tabstrip can be shown by
pulling the toolbar downwards.

Bug: 1094335
Change-Id: I03c7d8b95c81d11a90afbdf1bac9f3f6eeb9841a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249763
Commit-Queue: Roberto Moura <mouraroberto@google.com>
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Auto-Submit: Roberto Moura <mouraroberto@google.com>
Cr-Commit-Position: refs/heads/master@{#779963}

Bug: 832274, 913173, 956736, 1042205
Change-Id: I2adeec04a28ad4c595ec63af181acf25c40b9ab6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250639Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779962}

No significant build speed changes.

Commits:
  https://github.com/google/turbine/compare/95f6fb6f1e962e8b6ec672905b0b04233f002dc2...1c98ea68543162a33c89c3629ed29c2c46391b7b

Ran:
  tools/android/build_speed/benchmark.py all_incremental && \
  git checkout update_turbine && \
  tools/android/build_speed/benchmark.py all_incremental

Results:
  Summary
  gn args: target_os="android" use_goma=true android_fast_local_dev=true
  gn gen: 6.5s
  chrome_java_nosig: 36.6s avg (36.5s, 36.7s)
  chrome_java_sig: 38.8s avg (38.9s, 38.8s)
  chrome_java_res: 23.1s avg (23.2s, 22.9s)
  base_java_nosig: 41.1s avg (41.1s, 41.0s)
  base_java_sig: 90.9s avg (90.8s, 91.0s)
  Switched to branch 'update_turbine'
  Summary
  gn args: target_os="android" use_goma=true android_fast_local_dev=true
  gn gen: 6.4s
  chrome_java_nosig: 36.5s avg (37.0s, 36.0s)
  chrome_java_sig: 37.8s avg (38.2s, 37.5s)
  chrome_java_res: 22.7s avg (22.9s, 22.4s)
  base_java_nosig: 41.3s avg (41.5s, 41.1s)
  base_java_sig: 91.2s avg (91.1s, 91.3s)

Bug: 1082904
Change-Id: I11d5efe60979a5e5a669366443914dc77da807e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2248581
Auto-Submit: Peter Wen <wnwen@chromium.org>
Commit-Queue: Mohamed Heikal <mheikal@chromium.org>
Reviewed-by: Mohamed Heikal <mheikal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779961}

Ensures OnSampleCompleted(...) is called even if stack unwinding
is failing.

It is common on windows that Unwinding fails when the LdrLock is
taken. This leads to missing trace events in slow-reports. Also,
the LdrLock sampling profiler is not called and the state of the
loader lock is not reported correctly.

Bug: 1093912
Change-Id: Ice050be1df20c3465be54e56de8c0cecd9134ea0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250789Reviewed-by: Mike Wittman <wittman@chromium.org>
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779960}

-Wl,-undefined,dynamic_lookup is deprecated on iOS Simulator, which
prevents us from linking libc++abi into the main executable and
exporting symbols for shared libraries to use. Instead, disallow
export_libcxxabi_from_executables on iOS, since it is effectively
unsupported.

BUG=1095852

Change-Id: I35204f9ccf668941f9e058aa05ab3caa9eaf376b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250218Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Rohit Rao <rohitrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779959}

Roll Chrome Win64 PGO profile from chrome-win64-master-1592474334-e0477f022b6eb5a61c43375c0dcd8da0fde9e8a1.profdata to chrome-win64-master-1592495797-d903a1fb107ff5cf8693e66337654c7b30cfb050.profdata

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/pgo-win64-chromium
Please CC jeffyoon@google.com,liaoyuke@google.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Cq-Include-Trybots: chrome/try:win64-chrome
Tbr: jeffyoon@google.com,liaoyuke@google.com
Change-Id: I654f6ce73b481b14f5e00257bc7fb0910c599c9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252519Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#779958}

BUG=1096196

Change-Id: I92bbcc8659b250500f711ff33ab210a370f42ba6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2251203
Commit-Queue: Toni Baržić <tbarzic@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779957}

Change-Id: Icdf51cb147ca87f22e72d62422d2713d06c3e38d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2248741
Commit-Queue: Charlie Hu <chenleihu@google.com>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779956}

The checks that are necessary to determine if a TabElement moved towards
the start or the end of the tab strip are the same for TabGroupElements,
so this CL prepares the animation for TabGroupElement by moving these
checks to the animation functions.

Bug: 1082344
Change-Id: I9bd9322948c40c61e9324d74c6c0dfba41ea9551
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250950
Commit-Queue: John Lee <johntlee@chromium.org>
Reviewed-by: dpapad <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779955}

This CL is a refactor with no intended behavior change.

Change-Id: I0673487c7bc3a7f4f895c03cff16ef982c8e8cba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252621
Auto-Submit: Erik Chen <erikchen@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779954}

We currently don't attach this tab helper on Android until portal
activation, but this can be attached as soon as the portal's web
contents are created and is, in fact, required for autofill to work
correctly after activation.

Bug: 1083277,894428
Change-Id: Iee35a2433c68fc54d7e4307255cbb7a32ad05683
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2242173
Commit-Queue: Ian Vollick <vollick@chromium.org>
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Reviewed-by: Friedrich [CET] <fhorschig@chromium.org>
Reviewed-by: Lucas Gadani <lfg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779953}

Creating a ScopedObserver<TabStripModel, TabStripModelObserver> is
disallowed since TabStripModelObserver already implements the same
functionality. This was enforced using template specialization with an
empty class body, which gives a very unclear compile error.

Explicitly deleting the constructor gives an error message that can be
traced back to this specialization.

Change-Id: Iee001e45b4014a08c88d4c0bd962ebc3273a5aa1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243716
Commit-Queue: Collin Baker <collinbaker@chromium.org>
Reviewed-by: Connie Wan <connily@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779952}

This reverts commit 65e3049c.

Reason for revert: The root cause was found server-side; this workaround is no longer needed.

Original change's description:
> [DeviceSync v2] Force enrollment after SyncMetadata 404 errors
> 
> This is a mitigation put in place to handle 404 errors returned by the
> CryptAuth server during SyncMetadata requests. A 404 error is returned
> when the server cannot find an enrolled device with the same Instance
> ID.
> 
> Theoretically, this should never occur assuming that 1) we never run a
> v2 DeviceSync until the device has successfully enrolled using v2
> Enrollment and 2) the Instance ID does not rotate. Without this
> mitigation, the user will unsuccessfully try to sync until the next
> enrollment, which could be up to 30 days.
> 
> This fix will be removed when the root cause is uncovered.
> 
> Bug: 1092113, b/155642672
> Change-Id: Ibc766ad21d83d1ace26c5e8c6c45f3eed835da74
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2234126
> Reviewed-by: James Vecore <vecore@google.com>
> Commit-Queue: Josh Nohle <nohle@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#776330}

TBR=nohle@chromium.org,vecore@google.com

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 1092113, b/155642672
Change-Id: I94ac09ca75aba101a800176c644beec4f9ace710
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252622Reviewed-by: Josh Nohle <nohle@chromium.org>
Reviewed-by: James Vecore <vecore@google.com>
Commit-Queue: Josh Nohle <nohle@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779951}

Up until now, it has been complex to accessing an Activity UI Surface
when you have a WebContents. This dependency acquisition has been a pain
point, in particular for the modularization effort.

This CL therefore creates a new UnownedUserData[Host] framework that
allows any UI surface to make itself available through a host that does
not own them. This allows the UI framework to still safely maintain the
ownership model it needs, without being worried about resurrection.

The UnownedUserDataHost stores the UnownedUserData objects using a
WeakRef, allowing the objects to be garbage collected.

The initial use-case for this is to allow objects to attach themselves
to WindowAndroid, since that is available through WebContents.

For usage patterns for this, see the class documentation for
UnownedUserDataHost and UnownedUserDataKey.

Guarantees provided by the framework:
- The UnownedUserDataKey is generically typed to a particular type of
  UnownedUserData.
- One UnownedUserDataKey can be used for multiple UnownedUserData
  instances.
- One UnownedUserDataKey can be attached to multiple UnownedUserDataHost
  instances.
- One UnownedUserDataKey can be attached to a particular
  UnownedUserDataHost only once.
  - This ensures a pair of UnownedUserDataHost and UnownedUserDataKey
    can only refer to a single UnownedUserData.
- When an UnownedUserData object is detached from a particular host
  it is informed of this, except if it has been garbage collected.
- When an UnownedUserData object is replaced with a different
  UnownedUserData using the same UnownedUserDataKey, the former is
  detached.

Bug: 1091584

Change-Id: I4ed5f7f9f86dc28426f85646017e964bf0b1d4e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2189190
Commit-Queue: Tommy Nyquist <nyquist@chromium.org>
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779950}

- Updates relevant chromeos BUILD.gn files
- Add imports and exports to os_route, os_settings_route and
  os_settings.js
- Update bluetooth test files.

Bug: 1045266
Change-Id: I81e52893befe36b4757283428b7844b2de8fe514
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2220218
Commit-Queue: Nnamdi Theodore Johnson-kanu <tjohnsonkanu@google.com>
Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Reviewed-by: Regan Hsu <hsuregan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779949}

If the block-start edge of a float was above the fragmentainer boundary,
and its margin-block-start would take us past the boundary, we'd fail to
detect the need for a break. The bug was that MovePastBreakpoint()
expects a border edge block-start offset, but we were passing the margin
edge from the float code.

We also need to introduce an additional check before deferring to
MovePastBreakpoint(), because in our implementation, float margins are
unbreakable and also don't collapse with the fragmentainer boundaries
(which MovePastBreakpoint() assumes that we can).

Bug: 829028
Change-Id: If7336055df4e90b7cbf313e843d697f5e4c796a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250063Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779948}

This change removes innerHTML usage from chrome://interstitials in
order to be compatible with Trusted Types.

Bug: 41905
Change-Id: I52416bfcf487ef0aba21ccf76e58ae957f479acd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2245937Reviewed-by: Carlos IL <carlosil@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Commit-Queue: Jun Kokatsu <Jun.Kokatsu@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#779947}

Bug: 1096515
Change-Id: I753e4d934b6c92d24f7b4276fc5fa9b716b45ffc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252418
Auto-Submit: Aaron Leventhal <aleventhal@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779946}

WebView depends on viz even when weblayer is not being used; move the
dependency to browser_java to match where the native dependency is, to
fix the case when webview_includes_weblayer=false.

Fixed: 1096081
Change-Id: Ic016657b26dee0d9135f7e0bc5a752823e3134f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250951Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Tim Volodine <timvolodine@chromium.org>
Commit-Queue: Tim Volodine <timvolodine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779945}

Change-Id: I4953ac7ea774fea1f6e96446547d2189b7ec30d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252279Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Reviewed-by: Robert Ma <robertma@chromium.org>
Commit-Queue: Robert Ma <robertma@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779944}

When a bluetooth device is connected that should be the system default or app default we may get a series of device change events that look something like bluetooth device -> system device (previous default) -> bluetooth device.

In these cases if the final transition to bluetooth device occurs within 250ms of the device change notification for the system device we will ignore that change due to the current code that tries to protect against redundant role change notifications.

Since in this case we do want to process the change and transition to the bluetooth device adding an additional check to ensure that the device id has not changed when ignoring a device change due to role timeout.

Bug: 1095667
Change-Id: Ib6518a27f60aa2a0acfa592eb51fffaf375fc407
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2245797Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: William Carr <wicarr@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#779943}

This attempts to detect SameSite cookie "compatibility pairs" and
tag them with a new CookieInclusionStatus::WarningReason.

These are pairs of two similar cookies used to work around incompatible
clients (browsers which do not support SameSite=None), where one has
SameSite=None and Secure and the other has no SameSite attribute
specified. The intention is that browsers which support SameSite=None
and enforce SameSite-Lax-by-default will drop the old-style cookie,
while browsers which do not support SameSite=None will drop the
new-style cookie.

The heuristic used to detect such pairs of cookies is:
 - The cookies cannot be equivalent (same name, domain, path).
 - One must have SameSite=None and Secure, and the other must have
   unspecified SameSite.
 - They must have the same domain, path, and value.
 - One must have a name that is a prefix or suffix of the other's name,
   and the shorter of the two names must have length at least 3.

Such pairs of cookies are tagged if they are included in the same
cross-site access attempt via HTTP request, HTTP response, or
document.cookie read. Setting cookies via writing to document.cookie
does not result in tagging of compatibility pairs.

Additionally, a cookie access in a non-HTTP (i.e. script) context will
not tag or compute cookie pairs from any cookie that has the HttpOnly
attribute.

Bug: 1095192
Change-Id: I43075cb851e6e02a5d2ef3e443e63e13fb21bd4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243255
Commit-Queue: Lily Chen <chlily@chromium.org>
Reviewed-by: Maksim Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779942}

https://webrtc.googlesource.com/src.git/+log/2c9d76a4eb0f..f46902c540c3

2020-06-18 jakobi@webrtc.org Add a simple frame length controller.
2020-06-18 zhaoliang.ma@intel.com vp9_impl: Enable VP9D_SET_LOOP_FILTER_OPT for libvpx vp9 decoder

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/webrtc-chromium-autoroll
Please CC webrtc-chromium-sheriffs-robots@google.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Bug: chromium:1086942
Tbr: webrtc-chromium-sheriffs-robots@google.com
Change-Id: Ia5c370d7284a50e8b5872e4e305ce49d8a360e19
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252579Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#779941}

AFAICT, this was only originally added to avoid a crash on GTK (which
didn't use views at the time) -- see
https://codereview.chromium.org/1528032 .  Views does tooltip eliding
centrally at this point, so this should no longer be necessary.

Bug: 139398
Change-Id: I768234808a6bf6c2b4730462c52927e206252f3a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2249144Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: David Trainor <dtrainor@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779940}

This metric corresponds to the current TBMv2 CPU time metric.
See https://source.chromium.org/chromium/chromium/src/+/master:third_party/catapult/tracing/tracing/metrics/system_health/cpu_time_metric.html

Bug: 1096236
Change-Id: Ib922da8032724992ac243e87d8b5e3497ac3d912
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250946
Commit-Queue: Deep Roy <dproy@chromium.org>
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/master@{#779939}

Fix for `autoninja.py` since otherwise its regex assumes use_goma is not
on.

Bug: 1092528
Change-Id: I12b53e52485ae5750a9588f57b4518a6bf495ac3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252615
Commit-Queue: Peter Wen <wnwen@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Auto-Submit: Peter Wen <wnwen@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779938}

https://chromium.googlesource.com/devtools/devtools-frontend.git/+log/0ca3d7910867..4ca37e4df727

2020-06-18 zhin@chromium.org Update acorn-logical-assignment to 0.1.3

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/devtools-frontend-chromium
Please CC devtools-waterfall-sheriff-onduty@grotations.appspotmail.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Bug: chromium:1080569
Tbr: devtools-waterfall-sheriff-onduty@grotations.appspotmail.com
Change-Id: I8fa313124d0225814ec1bf6e4b97055416a02951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252438Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#779937}

This is the only user of these functions, and they're not
"shelf"-related in any particular way.

(No code changes to the functions themselves.)

Bug: none
Change-Id: Idfd321b09fd9926f27523710cca0a3f209e35835
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2251053
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Xing Liu <xingliu@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779936}

https://swiftshader.googlesource.com/SwiftShader.git/+log/7a1d99d0be42..974cfa9fbbdb

2020-06-18 capn@google.com Optimize out-of-bounds checks with unsigned compare
2020-06-18 capn@google.com Replace instead of add pointer offsets when out of bounds

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/swiftshader-chromium-autoroll
Please CC swiftshader-team+autoroll@google.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_chromium_msan_rel_ng;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;luci.chromium.try:linux-swangle-try-x64;luci.chromium.try:win-swangle-try-x86
Bug: None
Tbr: swiftshader-team+autoroll@google.com
Change-Id: Ie6fa6928b3298e6bc329928add2afd80573b981d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2252518Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#779935}

This makes WebLayer match Chrome's sad frame/plugin bitmap. This
required moving the images into //components.

Bug: 1023811
Change-Id: Ib3dedd7fb7a901bd1a393fac5f39b370c536046e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2250920Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779934}

Here in the migration dialog the expiration date has the format:
"Exp: 06/21" so it may lead to different length when translated.
So here to be safe I just limited the label width directly, and
hopefully will leave enough space for expiration date.

Uploaded screenshot in bug comment #32

Bug: 1082013
Change-Id: I63759412571ac4f163dee779bd3eb98e83952de3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2241647Reviewed-by: Dana Fried <dfried@chromium.org>
Reviewed-by: Jared Saul <jsaul@google.com>
Commit-Queue: Siyu An <siyua@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779933}

This CL is adding a ScopedThreadPriority that save the current
thread priority and restore it when leaving the scope. This is
required since it is possible to run code outside of the Run(...)
scope with Background priority.

On Windows, this is causing shutdown hangs because the LoaderLock
can be held by a background thread while doing TLS destruction.


Without this fix, the DCHECK in the code run with Background priority
and fails:

[9888:28656:0617/210735.064:FATAL:thread_local_storage.cc(331)] Check failed: PlatformThread::GetCurrentThreadPriority() != ThreadPriority::BACKGROUND (0 vs. 0)
Backtrace:
        base::debug::CollectStackTrace [0x00007FF92445E7D2+18] (C:\src\chromium\src\base\debug\stack_trace_win.cc:284)
        base::debug::StackTrace::StackTrace [0x00007FF9243668F2+18] (C:\src\chromium\src\base\debug\stack_trace.cc:203)
        logging::LogMessage::~LogMessage [0x00007FF92437F094+148] (C:\src\chromium\src\base\logging.cc:605)
        logging::LogMessage::~LogMessage [0x00007FF92437FE40+16] (C:\src\chromium\src\base\logging.cc:598)
        base::internal::PlatformThreadLocalStorage::OnThreadExit [0x00007FF9244425FA+170] (C:\src\chromium\src\base\threading\thread_local_storage.cc:333)
        RtlActivateActivationContextUnsafeFast [0x00007FF96440B583+291]
        RtlActivateActivationContextUnsafeFast [0x00007FF96440B67F+543]
        LdrShutdownThread [0x00007FF964408B8C+348]
        RtlExitUserThread [0x00007FF9644436FE+62]
        BaseThreadInitThunk [0x00007FF96240403C+28]
        RtlUserThreadStart [0x00007FF964443691+33]

Bug: 1096203
Change-Id: Ibc011ac370dde4b6a872da6ac81938f52965a5a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2251199
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779932}

This CL adds UMAs and UKMs for the experimental LCP metric, which
considers removed content as valid LCP candidates. The nontrivial logic
to compute the frame merges and image-text merges is done by the
LargestContentfulPaintHandler, so the method parameters are changed to
not explicitly query the non-experimental LCP versions, and the class is
reused to computed the same merges for the experimental version.

UKM collection review:
https://docs.google.com/document/d/1Fdsg8t1d2X3nsE0QiVYnzslBjFA61NGhx0yMJQkZSEo/edit#heading=h.k5jx6iluw4yt

Bug: 1045640
Change-Id: I7d733de0bbdd12c66256b203d735efe2fa825a48
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2241943Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779931}

Currently when Chrome requests a screenshot we send a CopyOutputRequest
from the browser. However while taking this screenshot we need to
transfer it over a mojo pipe. This serialization takes 100-200 ms an
example traces in the linked bug on the VizCompositor thread and then
another 100-200 ms to deserialize it on the CrBrowserMain. This can
block high priority tasks which delay input handling causing visible
jank to users.

We fix this by doing the expensive copies on the ThreadPool, most other
copy tasks only take a couple ms so this removes most of the pain
relatively easily.

Tests had to be updated to know to wait for
CopyOutputResult::SendResult to complete async.


Bug: internal b/152858656
Change-Id: I114d65894c80742309bc2a02fdd2a0a7ad56dae7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2201762
Commit-Queue: Stephen Nusko <nuskos@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Reviewed-by: vmpstr <vmpstr@chromium.org>
Reviewed-by: Mitsuru Oshima (slow:gardening) <oshima@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Reviewed-by: Stephen Nusko <nuskos@chromium.org>
Auto-Submit: Stephen Nusko <nuskos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#779930}