GitLab

This also removes the dependency on the Floating Action Button
and sets the accessibility text for the Select All, Undo and
Search buttons.

Bug: 876823, 860467
Change-Id: I1fc2758ddb72db133bf489ef7a0f71783b5d2ac9
Reviewed-on: https://chromium-review.googlesource.com/1190342Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Finnur Thorarinsson <finnur@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586734}

When dragging a tab out of a snapped browser window to drop into
overview, it should be able to merge the tab window into the overview.
However, with the recent change to always update the dragged window's
bounds before adding it to overview, it's possible that the dragged
window is merged back into its source window due to its bounds change.
To avoid this, we temmrarily disable the dragged window's ability to
merge into another window when updating the dragged window's bounds and
restore its ability after adding it to overview.

Bug: 878191
Change-Id: I219517b19f42395ca8a0c095d7313734358e159e
Reviewed-on: https://chromium-review.googlesource.com/1192357Reviewed-by: Min Chen <minch@chromium.org>
Commit-Queue: Xiaoqian Dai <xdai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586733}

This CL ensures that any access to the ManualFillingCoordinator checks
whether the latter exists in the first place. Because its initialization
happens after the native initialization, this is a possible source of
crashes.

Also, this CL handles that cases in which the bottom control space
changes even if there is no accessory to fill it.

Bug: 876215, 877687
Change-Id: I713ab1343742c858d6ab0277b94cf3190e88e5e2
Reviewed-on: https://chromium-review.googlesource.com/1189805
Commit-Queue: Friedrich Horschig [CEST] <fhorschig@chromium.org>
Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586732}

TBR=martiniss@chromium.org
NOTRY=true

Bug: 855319
Change-Id: Ia760d2ff0e5c7bfe6cf1508464d0c1e5bc1e2026
Reviewed-on: https://chromium-review.googlesource.com/1194325Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586731}

This CL makes the tests run for both the directory-based implementation
and the new USS based implementation.

Bug: 876301
Change-Id: Id613f23514b52bf01d1d0ed3bdc73b87e758a03b
Reviewed-on: https://chromium-review.googlesource.com/1189963Reviewed-by: Jan Krcal <jkrcal@chromium.org>
Commit-Queue: Florian Uunk <feuunk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586730}

This change also simplifies the approach to getting the profiler callback
across CallStackProfileMetricsProvider and ChildCallStackProfileCollector
by directly calling ChildCallStackProfileCollector::Collect() or
CallStackProfileMetricsProvider::ReceiveCompletedProfile() from
CallStackProfileBuilder::OnProfileCompleted().

Bug: 851163
Change-Id: Ia9a39510342cf6f4f1e43464b4c54345ba5e4d63
Reviewed-on: https://chromium-review.googlesource.com/1185854Reviewed-by: Mike Wittman <wittman@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Xi Cheng <chengx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586729}

This allows using //base/task/post_task.h for posting tasks to a
BrowserThread by specifying a BrowserThread::ID as a task trait.

Also adds a content::NonNestable task trait to support non-nestable
tasks in base::PostTaskWithTraits.

In the future, we will add further traits to facilitate scheduling
tasks onto different SequenceManager queues on the UI thread, see:
https://docs.google.com/document/d/1z1BDq9vzcEpkhN9LSPF5XMnZ0kLJ8mWWkNAi4OI7cos/edit?usp=sharing

Bug: 867421, 863341, 878356
Change-Id: Id8b7bc2e374917ceb421c7f6139790e6f1457511
Reviewed-on: https://chromium-review.googlesource.com/1181364
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Alex Clarke <alexclarke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586728}

Bug: 878309
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I961a8c962ca3b77b86a4cca37fdda81333ad8a88
Reviewed-on: https://chromium-review.googlesource.com/1194028Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586727}

Height of sliders were wrong. 40dip -> 32dip
It affected both slider bubble and main bubble.

TEST=manual
BUG=877558

Change-Id: I7b2822e263c4e335b845f0ea40a9b52866ced60e
Reviewed-on: https://chromium-review.googlesource.com/1192374Reviewed-by: James Cook <jamescook@chromium.org>
Commit-Queue: Tetsui Ohkubo <tetsui@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586726}

SyncAuthManager has a supposed invariant that only one of an access token,
an access token request, or a pending retry can exist at any one time.
However, it didn't properly enforce this, so in some cases the invariant
could be violated. This CL fixes that, and adds a bunch of DCHECKs to make
sure.

Bug: 877440
Change-Id: I756e41d5045edb36fcfaa53104092a4f299a1e20
Reviewed-on: https://chromium-review.googlesource.com/1188472
Commit-Queue: Marc Treib <treib@chromium.org>
Reviewed-by: Mohamed Amir Yosef <mamir@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586725}

Send a histogram value from UpgradeDetector when the device did
install a rollback image and shows a notification before reboot.

The metric records whether the rollback is happening because of a
channel switch or because of an admin-initiated enterprise
rollback.

Bug: 871759
Change-Id: I38fad1792ba87b6bdbd788b3cd0f736dfa2d363c
Reviewed-on: https://chromium-review.googlesource.com/1190703
Commit-Queue: Marton Hunyady <hunyadym@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586724}

This fixes the issue that we're showing a misleading "Your
administrator rolled back this device" notification on non-enrolled
devices too if they switch the channel to a more stable version.

Bug: 871759
Change-Id: I75e9e3faacaed0499fedef1aafda290cf0b87e19
Reviewed-on: https://chromium-review.googlesource.com/1188665Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Marton Hunyady <hunyadym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586723}

This test apparently:
- Tries to use something called "objCPlugin" for Obj-C bindings,
  which doesn't exist in Blink
- Then adds /etc/passwd as the canonical "local file" URL
- Then attempts to instantiate an NSPasteboard Objective-C object
- So that it can try to read the "NSFilenamesPboardType" obsolete
  data type off of it.

This is not a useful test in any way.

BUG=none

Change-Id: If7b17055536eda22d401bed1b48ab4f35b53c3f5
Reviewed-on: https://chromium-review.googlesource.com/1192262Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586722}

Allows passing in a precomputed border+padding struct to various
length util functions.

No-Try: True
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I330dfc77e7392928f2475a05ecfdb6c643c9a5f4
Reviewed-on: https://chromium-review.googlesource.com/1193403
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586721}

This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/shell_integration_linux.cc.

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=thomasanderson@chromium.org

Bug: 874080
Change-Id: I64920670d2ccb62299815969d324003f462d8ecd
Reviewed-on: https://chromium-review.googlesource.com/1191801Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586720}

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}