GitLab

This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/web_applications/components/web_app_shortcut_mac.mm.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=rsesek@chromium.org

Bug: 874080
Change-Id: Iffe2955c934c9a81ffddefd2d42cfb277aec0ddb
Reviewed-on: https://chromium-review.googlesource.com/1191665Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586719}

It is always false and has been for over a year.

Change-Id: Ibd2b6b8c3f6dc5e9e6ba4a877bdec98e0482f9af
Reviewed-on: https://chromium-review.googlesource.com/1193750Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586718}

DrmThread::IsDeviceAtomic currently can cause a SIGSEGV since it assumes
that |drm_device| is a valid pointer.
|drm_device| device can be nullptr if the widget has been disabled.

This patch fixes the issue checking that |drm_device| is a valid pointer
before dereferencing it.

Bug: 875882, 876385
Change-Id: I01527e9d9d294e0f98146ccd5e6d5ef70e0dfdf0
Reviewed-on: https://chromium-review.googlesource.com/1193963Reviewed-by: Michael Spang <spang@chromium.org>
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586717}

Combobox menus support this already, but on Mac all menus should support it
instead of Windows/Linux-style mnemonics for items. This change:

1) Adds a new MenuConfig knob for whether the platform behaves this way;
2) Adds PrefixSelector::WillContinueSelection() to expose whether the
   PrefixSelector search is still "live" (versus having timed out);
3) Adds logic to MenuController to only activate items on VKEY_SPACE when the
   PrefixSelector is not still accumulating a prefix search;
4) Changes SubmenuView::GetTextForRow() to use the accessible name for the row
   instead of the raw title. Not doing this causes prefix searches to fail
   because the raw title includes mnemonic-marking ampersands;
5) Disables MenuRunnerTest.{,Non}LatinMnemonic on Mac;
6) Adds MenuRunnerTest.PrefixSelect to test most of this behavior on Mac.

Bug: 845466
Change-Id: I5d1e2c940026560d1e542263d99911889f52c742
Reviewed-on: https://chromium-review.googlesource.com/1187062
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586716}

This CL uses ScopedBlockingCall to mark blocking calls in /ios/chrome/browser/ui/image_util.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=gambard@chromium.org

Bug: 874080
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I14f3200988ea3482fbccd94e0ff43e46dd192504
Reviewed-on: https://chromium-review.googlesource.com/1191130Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586715}

TBR=beaufort.francois@gmail.com
NOTRY=true

Bug: 878396
Change-Id: I6216c7273e514fde365f591b0607eb8a69ab133e
Reviewed-on: https://chromium-review.googlesource.com/1194243Reviewed-by: Xida Chen <xidachen@chromium.org>
Commit-Queue: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586714}

NOTRY=true
TBR=pasko@chromium.org

Bug: 878175
Change-Id: I399e3e0d905ade42d67985a1808f4b7a7ccd541a
Reviewed-on: https://chromium-review.googlesource.com/1194242Reviewed-by: Ned Nguyen <nednguyen@google.com>
Commit-Queue: Ned Nguyen <nednguyen@google.com>
Cr-Commit-Position: refs/heads/master@{#586713}

Remove the local SkFontMgr and SkTypeface mocks and replace them
with a FakeFontCollection. This makes the test a better representation
of what happens at runtime, makes the test smaller and easier to
understand, and makes it easier for Skia to evolve the API of SkFontMgr
and SkTypeface.

Change-Id: I94866b5e9645e1a461c71807c9349b2e9f612032
Reviewed-on: https://chromium-review.googlesource.com/1185749Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Ben Wagner <bungeman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586712}

[FeatureList] Change GetApplicationLocale() in VariationsServiceClient to be a local function. [2/3]

Before this function uses a pref in Chrome so we need to override it in Chrome
to access that pref value.

As a followup for this cl https://crrev.com/c/1135198,
now we can access the pref directly in componment/ and we no longer need to do that.

This CL comes from https://crrev.com/c/1140356. See previous discussion there.

Bug:729596
TBR=asvitkine@chromium.org

Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I7bf5631b81436344ccb17aaa2a8d6ac4167f5d7f
Reviewed-on: https://chromium-review.googlesource.com/1147481
Commit-Queue: Xi Han <hanxi@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586711}

Bug: 875268
Change-Id: I1b830543820a49b0954814721b359a57469b9e44
Reviewed-on: https://chromium-review.googlesource.com/1191202Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Cr-Commit-Position: refs/heads/master@{#586710}

This class doesn't have broad utility, so doesn't belong in base.

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: Ia877af08d8fd635c738e3c0c2cee588c8cba7be1
Reviewed-on: https://chromium-review.googlesource.com/1191091Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: agrieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586709}

Bug: 849323
Change-Id: If9701534446183c2d9bc78349a2e70e277e46916
TBR: hongjunchoi@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/1194025Reviewed-by: Balazs Engedy <engedy@chromium.org>
Commit-Queue: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586708}

The CSS overscroll-behavior feature controls whether scrolling should
continue to propagate up to the parent scroller.

This CL adds the necessary plumbing to set the correct values on the CC
ScrollNodes when Blink is responsible for creating the property trees
(i.e. with --enable-blink-gen-property-trees is used).

TEST=virtual/threaded/fast/scroll-behavior/overscroll-behavior.html

Bug: 866051
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux-blink-gen-property-trees;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I55938ec5801083e3cdcbf1e3d2da1cb7791d2c43
Reviewed-on: https://chromium-review.googlesource.com/1188647
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Jianpeng Chao <chaopeng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586707}

Bug: 876357
Change-Id: Ia1e67b5c5d3cc20c67841108e6c055bc918f086e
Reviewed-on: https://chromium-review.googlesource.com/1184082Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Henrique Grandinetti <hgrandinetti@google.com>
Cr-Commit-Position: refs/heads/master@{#586706}

This CL stores a vector of URLs in a UkmSource rather than
two separate URL members (final / initial). This will aid in
future changes like storing the entire redirect chain.

This CL should not change behavior.

Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: If762a287601849dbf5c62d3a82477aca4f00fbac
Reviewed-on: https://chromium-review.googlesource.com/1187070
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Reviewed-by: Robert Kaplow (slow) <rkaplow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586705}

Ensures that we don't blindly trust specified buffer size and offset
metadata when deserializing data pipe consumer and producer handles.

Bug: 877182
Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9
Reviewed-on: https://chromium-review.googlesource.com/1192922Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586704}

The server currently sends version_watermark based GC directives in order to
clear the clients entire sync storage for that datatype.

This doesn't work in USS, because the processor only clears the metadata
when receiving a GC directive. This means that the data itself is left
as-is.

This CL changes the expectations on the client when receiving a
version_watermark GC directive to always clear the entire client storage.
This is implemented in USS by handling an update that includes that GC
directive as a full update that replaces any existing client data.

We do this by allowing bridges to specify whether they support incremental
updates or if they require full data updates. The processor then reports a
ModelError when receiving an incremental update for a bridge that doesn't
support incremental updates, or when receiving a full update for a bridge
that supports incremental updates.

When receiving a full update, the processor calls MergeSyncData instead of
ApplySyncChanges on the bridge.

Bug: 876308
Change-Id: I7fc83e75eb039346866cc6ebd7cf5aa4d9546fdb
Reviewed-on: https://chromium-review.googlesource.com/1183902
Commit-Queue: Florian Uunk <feuunk@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586703}

This CL uses ScopedBlockingCall to mark blocking calls in /ash/display.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=afakhry@chromium.org

Bug: 874080
Change-Id: Ibbeed96def34b810b6ed2d2b746f8700d2f4c8d0
Reviewed-on: https://chromium-review.googlesource.com/1191807Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586702}

This CL uses ScopedBlockingCall to mark blocking calls in /components/crash.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=mark@chromium.org

Bug: 874080
Change-Id: I85dff1e7321fcebb76a6fa2ff98046bd78377154
Reviewed-on: https://chromium-review.googlesource.com/1191803Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586701}

This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/ui/webui/print_preview.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=weili@chromium.org

Bug: 874080
Change-Id: Ib9f4215acff0afbbcdac414bf4d5617c09c81078
Reviewed-on: https://chromium-review.googlesource.com/1190931Reviewed-by: Wei Li <weili@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586700}

This CL uses ScopedBlockingCall to mark blocking calls in /components/subresource_filter.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=melandory@chromium.org

Bug: 874080
Change-Id: I23a4bee02df67722e41dc8c0afb4b94073eb8d95
Reviewed-on: https://chromium-review.googlesource.com/1191135Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586699}

This prepares for replacing GetTaskRunnerForThread() inside
HeadlessDevToolsClient::Create() with
base::CreateSingleThreadTaskRunnerWithTraits(), which can only be
called after browser initialization.

Bug: 878356
Change-Id: I851788ee9926cddd4662876c84e98a1fb9d0d47e
Reviewed-on: https://chromium-review.googlesource.com/1193367Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586698}

The MatchRules test had non-deterministic sorting behavior on
different platforms. Fix this by avoiding situations in the test where
there are ties for the number of matches.

Bug: 878328, 877148
Change-Id: I4883141c0c5c8ab02ace9365b4a446f132d6cea1
Reviewed-on: https://chromium-review.googlesource.com/1193902
Commit-Queue: Josh Karlin <jkarlin@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586697}

This CL uses ScopedBlockingCall to mark blocking calls in /components/webrtc_logging.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=grunell@chromium.org

Bug: 874080
Change-Id: I2f3f9d36b4dc8ed464fef884f87b898f06e47555
Reviewed-on: https://chromium-review.googlesource.com/1191098Reviewed-by: Henrik Grunell <grunell@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586696}

This CL uses ScopedBlockingCall to mark blocking calls in /components/password_manager.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=dvadym@chromium.org

Bug: 874080
Change-Id: If6f3ead08018decf2c8a2be44d810f4fa23cc190
Reviewed-on: https://chromium-review.googlesource.com/1191409Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586695}

Change-Id: I970adfa9998f261d1f2d604aa7fe31c73335a80f
Reviewed-on: https://chromium-review.googlesource.com/1188608Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Cr-Commit-Position: refs/heads/master@{#586694}

Bug: 865834
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: If4c9293870035e62828bfa44714a8dec2df673e2
Reviewed-on: https://chromium-review.googlesource.com/1191285Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586693}

This CL uses ScopedBlockingCall to mark blocking calls in /components/drive.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=fukino@chromium.org

Bug: 874080
Change-Id: I9e76b6bb5afde0889cd1b894e36b3f7cd02c484f
Reviewed-on: https://chromium-review.googlesource.com/1191139Reviewed-by: Naoki Fukino <fukino@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586692}

This CL uses ScopedBlockingCall to mark blocking calls in /components/web_restrictions.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=bauerb@chromium.org

Bug: 874080
Change-Id: Ib372aaeeb4db8096b4de5a9d8372cc2c6601d865
Reviewed-on: https://chromium-review.googlesource.com/1191224Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586691}

Bug: 877493
Change-Id: Iba8ba4941c2751fc6a77edc258e066cfc8ecb5ca
Reviewed-on: https://chromium-review.googlesource.com/1191248
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586690}

We're now running against the entire HttpArchive corpus of pages instead
of just the top X sites. We then select the top 1000 rules from the result.

Bug: 877148

Change-Id: I4a19e416592e9f1be12b2371feb6805746d4aee9
Reviewed-on: https://chromium-review.googlesource.com/1191902Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Commit-Queue: Josh Karlin <jkarlin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586689}

Use C++11 syntax to avoid having overloads for the method
CheckEvents (using std::initializer_list).

Bug: none
Change-Id: I99bb6f8b6e24df618fb6faa3d5a9e29e57512043
Reviewed-on: https://chromium-review.googlesource.com/1188663
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: David Roger <droger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586688}

Using wpt-import in Chromium dfc32c00.
With Chromium commits locally applied on WPT:
fbb650b3 "Add WPT serialization tests for wasm modules"


Build: https://ci.chromium.org/buildbot/chromium.infra.cron/wpt-importer/23541

Note to sheriffs: This CL imports external tests and adds
expectations for those tests; if this CL is large and causes
a few new failures, please fix the failures by adding new
lines to TestExpectations rather than reverting. See:
https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md

NOAUTOREVERT=true
TBR=robertma

No-Export: true
Change-Id: I631d125a33da8f5b568fbb6b2bd71372cbeb1cd0
Reviewed-on: https://chromium-review.googlesource.com/1193744
Commit-Queue: Blink WPT Bot <blink-w3c-test-autoroller@chromium.org>
Reviewed-by: Blink WPT Bot <blink-w3c-test-autoroller@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586687}

Added error strings for edit and delete custom links.

Bug: 877290
Change-Id: I6bee0b8804f34cf4760338c4b02ad440c2b4eb9f
Reviewed-on: https://chromium-review.googlesource.com/1188600
Commit-Queue: Mathieu Perreault <mathp@chromium.org>
Reviewed-by: Mathieu Perreault <mathp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586686}

This adds HandlerStarter to encapsulate logic around how the handler
process is started on linux-ish platforms. Follow-up CLs will add
support for launching the handler when it is not available to execv
from the filesystem.

Change-Id: I4c3f311f32971a315d8e675f36e051fc83db66c4
Reviewed-on: https://chromium-review.googlesource.com/1188873Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586685}

This is duplicate and unnecessary code. Removing for chromecast.

Test: Build
Bug: None
Change-Id: I1e0096254a60c55d636d9fdf32a4d530d7791a95
Reviewed-on: https://chromium-review.googlesource.com/1191022Reviewed-by: Alex Sakhartchouk <alexst@chromium.org>
Commit-Queue: Randy Rossi <rmrossi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586684}

This relands commit 0a12bc8f, which was
reverted in https://chromium-review.googlesource.com/c/chromium/src/+/1186781.

This is identical to 0a12bc8f but adds
disable_variants = true to all chrome_cleaner mojo interfaces to prevent
the blink and non-C++ variants from being built.

Original change's description:
> Add chrome_cleaner sandboxed engine Mojo interfaces
>
> R=wfh
>
> Bug: 830892
> Change-Id: I0a4b25b2ba04b65a80e2c03e9151b5ef55912432
> Reviewed-on: https://chromium-review.googlesource.com/1171737
> Commit-Queue: Joe Mason <joenotcharles@chromium.org>
> Reviewed-by: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#585025}

Bug: 830892
Change-Id: Ib476d03e0c3aba44c55bb0b4b26b6c38369e6b12
Reviewed-on: https://chromium-review.googlesource.com/1187004Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586683}

When there are more than six tabs in the tab grid, the animation when
entering the grid will sometimes be missing one or more snapshots. They
will appear a moment after the animation completes, which doesn't look
great.

The reason this happens is that the in-memory cache for snapshots is
capped at six objects. Requests for snapshots that are in the cache
return synchronously, but requests for uncached snapshots (which are
read from the filesystem) return in the next runloop. All of the layout
for the animation is done in the same runloop, so any uncached snapshots
aren't available.

The easiest solution is to increase the size of the snapshot cache, but
the number of snapshots that are needed is quite high in some cases (more
than 30 on a 12" iPad pro).

Instead, this CL implements a "prepare for appearance" mechanism for the
tab grid. This is triggered by a new ApplicationCommand that is sent when
the user touches *down* on a tab grid control. That leaves at least one
event loop for fetching cached resources.

The tab grid image data source (that is, the tab grid mediator) is ulti-
mately responsible for pre-loading the snapshots that might be needed. The
simple heuristic is to fetch the snapshots for each tab whose index is
within |N| of the active tab's index, where |N| is the maximum number of
tabs that will be visible in the grid. This is aggressive, but these pre-
fetched images are discarded as soon as the grid transition is completed,
and it's not as aggressive as just fetching all of the snapshots for the
open tabs.

Bug: 867980
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Ie00e599af50cd01ba002139b017ba2c2ec864db7
Reviewed-on: https://chromium-review.googlesource.com/1190203Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Commit-Queue: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586682}

This reverts commit 7dd4e161.

Reason for revert: Leak tests on Linux are failing since

https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Linux%20Trusty%20Leak/23587

Original change's description:
> Make NGPaintFragment ref-counted
> 
> This patch change |NGPaintFragmet| ref-counted instead of managed by
> |std::unique_ptr<T>| to resolve life time issue between |LayoutText|
> and |NGPaintFragment|.
> 
> Before this patch, paint fragment can live longer than |LayoutText|
> and causes heap-use-after tree in |NGAbstractTextBox::WillDestroy()|.
> 
> 
> Bug: 874588
> Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id2b59d9d8b257e7cf67ad841cd2fe5ad312951b0
> Reviewed-on: https://chromium-review.googlesource.com/1190625
> Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
> Reviewed-by: Koji Ishii <kojii@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#586658}

TBR=yosin@chromium.org,kojii@chromium.org

Change-Id: I2eb89ec4cf7aaf773189437dfe76d76ef49544b9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 874588
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/1193864Reviewed-by: Markus Heintz <markusheintz@chromium.org>
Commit-Queue: Markus Heintz <markusheintz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586681}

This CL extracts CreateSurface() and SurfaceReady() into a new
interface: DecodeSurfaceHandler.  This extraction reduces the
coupling surface (always good) and allows e.g. easier testing in
subsequent CLs.

VaapiVideoDecodeAccelerator is made to implement the said
templatised interface and teaches the Vaapi*Accelerator classes
to use it (instead of the whole VaVDA).

Partial diagram before: https://goo.gl/LBxH3h, after: https://goo.gl/E6sDrc.

Test: v_d_a_unittests and simplechrome on nautilus
Bug: 875005
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Id376a6a25e664b0b6669b202062ebd7179346c50
Reviewed-on: https://chromium-review.googlesource.com/1178340
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586680}