GitLab

FileUtilTest.ReadFileToStringWithNamedPipe has been flaking since
http://crrev.com/c/1298024 landed.

I believe FileUtilTest.ReadFileToStringWithNamedPipe was failing because
it creates 6 processes one after another. We only have 5 test processes,
so in some cases one was not available to be reused for the 6th process.
Doubling the number of test processes to 10 should fix this.

Bug: 902674
Change-Id: I7e6204b5fda28155de8d501ccb5e0e5d2754849e
Reviewed-on: https://chromium-review.googlesource.com/c/1338393Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608827}

We don't need it and it doesn't work. It's probably been ok up
until now because we have never had more than one S file per
build target.

See errors at
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Jumbo%20Win%20x64/22538

R=fs@opera.com

Change-Id: Idde99aba83e01c0111e5a50590e319993e0effaa
Reviewed-on: https://chromium-review.googlesource.com/c/1340312
Commit-Queue: Daniel Bratell <bratell@opera.com>
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#608826}

- Remove redundant |web_contents_|.
- Initialize them in the header when possible.
- Mark them const when possible.

Change-Id: Id7d709c128762e69e56b729a59e5481aaa8b44e1
Reviewed-on: https://chromium-review.googlesource.com/c/1339464Reviewed-by: Tommy Li <tommycli@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608825}

base::AssertBlockingAllowedDeprecated is deprecated in favor of
ScopedBlockingCall, which serves as a precise annotation of
the scope that may/will block.

Please 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: The call might block (e.g. file I/O that might hit in memory cache).
      WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging
        server synchronously).
    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().
  - Calls to blocking //base APIs don't need to be annotated
    with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read,
    base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their
    own internal annotations.

Refer to the top-level CL if necessary :
https://chromium-review.googlesource.com/c/chromium/src/+/1338391

Please CQ if LGTY!

This CL was uploaded by git cl split.

R=avi@chromium.org

Bug: 903957
Change-Id: I86f204337a4137c79f85eb73e5601b9a02fe578a
Reviewed-on: https://chromium-review.googlesource.com/c/1338489Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608824}

base::AssertBlockingAllowedDeprecated is deprecated in favor of
ScopedBlockingCall, which serves as a precise annotation of
the scope that may/will block.

Please 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: The call might block (e.g. file I/O that might hit in memory cache).
      WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging
        server synchronously).
    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().
  - Calls to blocking //base APIs don't need to be annotated
    with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read,
    base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their
    own internal annotations.

Refer to the top-level CL if necessary :
https://chromium-review.googlesource.com/c/chromium/src/+/1338391

Please CQ if LGTY!

This CL was uploaded by git cl split.

R=sadrul@chromium.org

Bug: 903957
Change-Id: I350657e7c0760b9ce1e4ff33a74a0e8e007d5e21
Reviewed-on: https://chromium-review.googlesource.com/c/1338409Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608823}

Currently linux-jumbo-rel, the CQ bot, builds with the default
jumbo chunk size, and since it uses goma that is 8. Building
with relatively small chunks (8) means that it doesn't notice
symbol clashes that happen with larger chunks so it's better to
build with the non-goma default, 50.

This will slightly reduce parallelism of builds, and might trigger
more files to be recompiled for changes, but it will also bring
along with it the benefits of larger jumbo chunks (less CPU cycles
spent per compiled cc file, faster linking) so it's not obvious
how it will affect performance, if at all.

Bug: 905588
Change-Id: I950ef63093f60580e98891aa0f556fa57b5d6628
Reviewed-on: https://chromium-review.googlesource.com/c/1337496Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Daniel Bratell <bratell@opera.com>
Cr-Commit-Position: refs/heads/master@{#608822}

This is no longer used.

R=tbarzic@chromium.org

Bug: 904892
Test: none
Change-Id: Iac3088bdc2b198d0d5b37ab9cf18fba5c4c704c8
Reviewed-on: https://chromium-review.googlesource.com/c/1334331Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Toni Baržić <tbarzic@chromium.org>
Commit-Queue: James Hawkins <jhawkins@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608821}

Migrate HandoffCollectionViewController from CollectionViewController to ChromeTableViewControllerStyleWithAppBar.

This CL migrates the HandoffCollectionViewController from
CollectionViewController, which is based on MDCCollectionViewController,
to ChromeTableViewController, which is based on UITableViewController.

Bug: 894791
Change-Id: I4b6e25e3729ad2150fbc49fd6c71c54229f76f31
Reviewed-on: https://chromium-review.googlesource.com/c/1340326Reviewed-by: edchin <edchin@chromium.org>
Commit-Queue: Yi Su <mrsuyi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608820}

https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/7893fd8c43b1..fe9b104421c3


Created with:
  gclient setdep -r src-internal@fe9b104421c3

The AutoRoll server is located here: https://autoroll-internal.skia.org/r/src-internal-chromium-autoroll

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

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


TBR=mmoss@chromium.org

Change-Id: Iddf93095c8a8ca2e453cbe7fddf71c2cba38b400
Reviewed-on: https://chromium-review.googlesource.com/c/1340147Reviewed-by: chromium-internal-autoroll <chromium-internal-autoroll@skia-corp.google.com.iam.gserviceaccount.com>
Commit-Queue: chromium-internal-autoroll <chromium-internal-autoroll@skia-corp.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#608819}

Chrome can see multiple hints from the server that a field is a
new-password field. This happens, in particular, if two fields
have the same name and hence the same signature -- because server
hints are keyed by the signature, there is no way to specify two
different types for two fields with the same name.

If there is no other explicitly hinted confirmation field, then it
is likely that in reality one of the new-password fields was supposed
to be a confirmation field.


Knowing which field is the confirmation field will be useful for
Chrome to understand where to copy the generated password to.

Therefore, this CL makes sure that the second hinted same-signature
new-password field is marked as a confirmation field, unless the server
also explicitly hints that some field is a confirmation field.

This is analogous to what the parser already does in case of two
fields with the autocomplete="new-password" attribute.

Bug: 902700
Change-Id: I06e75a6d1059976c68d04903351d9bd207de2ee9
Reviewed-on: https://chromium-review.googlesource.com/c/1326511
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608818}

base::ThreadRestrictions::ScopedAllowWait is deprecated in favor of its more
explicit counterpart.

It should have been replaced by :
 * base::ScopedAllowBaseSyncPrimitivesForTesting in test files.
 * base::ScopedAllowBaseSyncPrimitives in non-test files
 * base::ScopedAllowBaseSyncPrimitivesOutsideBlockingScope when it's used on threads
   that don't allow blocking
The last one is strongly frowned upon but this CL aims to document existing
behavior rather than address it. Owners are encouraged to follow-up by fixing
unnecessary waits and more particularly unnecessary waits
outside-blocking-scope.

Note: The non-for-testing versions require friend'ing in thread_restrictions.h
but care was taken to add these friends ahead of git cl split (since it wasn't
possible to do a line-by-line associated CL split).
Refer to the top-level CL if necessary :
https://chromium-review.googlesource.com/c/chromium/src/+/1288533

Please CQ if LGTY!

This CL was uploaded by git cl split.

R=rmcilroy@chromium.org

Bug: 766678
Change-Id: Ibed489dd8ea6d845199f91081f3e986f3014cf67
Reviewed-on: https://chromium-review.googlesource.com/c/1325196
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608817}

Replace usage of PO2TS APIs with calls to IdentityManager's methods.

Bug: 905280
Change-Id: I5ea837b30e2ca44ca3e44ef012d81aff57acc636
Reviewed-on: https://chromium-review.googlesource.com/c/1338105Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Mario Sanchez Prada <mario@igalia.com>
Cr-Commit-Position: refs/heads/master@{#608816}

Because it is actually an Android-only function. Update the caller in
chrome/common and fix a random nit there.

Change-Id: I4b488987cf4bb245c1665abefc24285aa6192b2a
Reviewed-on: https://chromium-review.googlesource.com/c/1338886Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608815}

base::AssertBlockingAllowedDeprecated is deprecated in favor of
ScopedBlockingCall, which serves as a precise annotation of
the scope that may/will block.

Please 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: The call might block (e.g. file I/O that might hit in memory cache).
      WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging
        server synchronously).
    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().
  - Calls to blocking //base APIs don't need to be annotated
    with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read,
    base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their
    own internal annotations.

Refer to the top-level CL if necessary :
https://chromium-review.googlesource.com/c/chromium/src/+/1338391

Please CQ if LGTY!

This CL was uploaded by git cl split.

R=kinuko@chromium.org

Bug: 903957
Change-Id: I55e70c8b849dd626cc9f51d03d4e2fd15d7d2e8c
Reviewed-on: https://chromium-review.googlesource.com/c/1338123Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608814}

Previously upon setting the local time beyond its duration we assumed
the behavior should be the same as we set it to the end point. However,
it's only true if the effect has fill mode: fowards specified. Otherwise
the animation should be deactivated. The expected behavior for the test
is updated.

Added a new test to cover the animation behaviors with fill modes.

Bug: 897167
Change-Id: Iecbf9e86e137ff2b98cdc0f2602222c49470e21e
Reviewed-on: https://chromium-review.googlesource.com/c/1308084
Commit-Queue: Yi Gu <yigu@chromium.org>
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608813}

base::AssertBlockingAllowedDeprecated is deprecated in favor of
ScopedBlockingCall, which serves as a precise annotation of
the scope that may/will block.

Please 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: The call might block (e.g. file I/O that might hit in memory cache).
      WILL_BLOCK: The call will definitely block (e.g. cache already checked and now pinging
        server synchronously).
    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().
  - Calls to blocking //base APIs don't need to be annotated
    with ScopedBlockingCall. All blocking //base APIs (e.g. base::ReadFileToString, base::File::Read,
    base::SysInfo::AmountOfFreeDiskSpace, base::WaitableEvent::Wait, etc.) have their
    own internal annotations.

Refer to the top-level CL if necessary :
https://chromium-review.googlesource.com/c/chromium/src/+/1338391

Please CQ if LGTY!

This CL was uploaded by git cl split.

R=pwnall@chromium.org

Bug: 903957
Change-Id: I81021e9c637e588b0cdcc464218df1770cedc635
Reviewed-on: https://chromium-review.googlesource.com/c/1338128Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608812}

In addition to migrating the QR scanner coordinator
from BVC to BrowserCoordinator, this CL does a little
refactoring on QR scanner coordinator.

Previously, presentation/dismissal was delegate out to
the BVC. Since coordinators are created with a baseViewController,
the presentation/dismissal can happen inside the box.
It does not need to be delegated outside the box.

Bug: 905524

Change-Id: I69dbe4eb4387bed7b42fc952dbee2a3af4059c71
Reviewed-on: https://chromium-review.googlesource.com/c/1337635
Commit-Queue: edchin <edchin@chromium.org>
Reviewed-by: edchin <edchin@chromium.org>
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608811}

We found that encountering unknown offsets from profile information may
indicate that the data is seriously offset (pun intended). It does not
happen now on the orderfile bot, and we would like to know when it
happens next. Converting this situation to error.

Bug: 893981
Change-Id: Ibabe4b39886afa4e3a228f9e3910df5d0bcf91cf
Reviewed-on: https://chromium-review.googlesource.com/c/1340328Reviewed-by: Matthew Cary <mattcary@chromium.org>
Commit-Queue: Egor Pasko <pasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608810}

Using wpt-import in Chromium 420f97c4.

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=lukebjerring

No-Export: true
Change-Id: Ie8c05d96805cfd0f6f62877cba8a7d9aceb93724
Reviewed-on: https://chromium-review.googlesource.com/c/1340359
Commit-Queue: WPT Autoroller <wpt-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Reviewed-by: WPT Autoroller <wpt-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#608809}

is swapped out => is frozen
for oopif => for child local root frame

"Swapped out" was used in RenderWidget as the term comes from
RenderViewHost, and RenderFrame. The main frame can be swapped out -
meaning hosted in another process. RenderWidget is a separate layer
of the code however and we would like to delete them but we can't,
so they must enter this state of "inactivity". Thus, frozen. Then
we can more clearly separate frozen RenderWidgets from swapped out
frames and freeze/thaw RenderWidgets more appropriately.

"For oopif" is confusing as it seems to mean the RenderWidget is not
in the same frame tree as the main frame. However it can be when
there is an oopif in between the frame in question and the main
frame. Rename it to be more clear about when it is true.

R=ajwong@chromium.org, piman@chromium.org

Change-Id: I52e31acfbf098bfb993d1aea69b699b7bcbb8cbf
Bug: 905191, 419087
Reviewed-on: https://chromium-review.googlesource.com/c/1336218
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608808}

Bug: 900293
Change-Id: Ibdb90ce9d2777311a1f67cd992f3ae326a9e1f01
Reviewed-on: https://chromium-review.googlesource.com/c/1338463Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608807}

Also includes a .clang_format file in the pup_data dir that was missed,
which caused dummy_signatures.cc to be reformatted.

R=csharp@chromium.org

Bug: 830892
Change-Id: I720c083ee6f8ee2b6f1805392419f43c91d43026
Reviewed-on: https://chromium-review.googlesource.com/c/1338205Reviewed-by: Chris Sharp <csharp@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/master@{#608806}

https://boringssl.googlesource.com/boringssl/+log/384d0eaf1930af1ebc47eda751f0c78dfcba1c03..e6eef1ca16a022e476bbaedffef044597cfc8f4b

Bug: none
Change-Id: I5bab6b11ebe76cf162d8b8ed6eeccd0f10d6c818
Reviewed-on: https://chromium-review.googlesource.com/c/1336209
Commit-Queue: Steven Valdez <svaldez@chromium.org>
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608805}

- Prevent Google Credential Provider for Windows from starting another
instances of Chrome on winlogon screen if one is already running
- Fix DCHECK failure that would crash the GCPW if the user cancels out
of the sign in or selects a different credential to sign into.

Bug: 900966
Change-Id: Ib30b4eff282cb55fa3fe6777dca56ff2051e275c
Reviewed-on: https://chromium-review.googlesource.com/c/1334293
Commit-Queue: Tien Mai <tienmai@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608804}

https://chromium.googlesource.com/angle/angle.git/+log/9e63a8137860..417ac91cdb06


git log 9e63a8137860..417ac91cdb06 --date=short --no-merges --format='%ad %ae %s'
2018-11-16 jmadill@chromium.org Fix typo in perf_test_runner.py.


Created with:
  gclient setdep -r src/third_party/angle@417ac91cdb06

The AutoRoll server is located here: https://autoroll.skia.org/r/angle-chromium-autoroll

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

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

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

Change-Id: Id6b5921477756274f26f6e458eab00f1faed8125
Reviewed-on: https://chromium-review.googlesource.com/c/1340381Reviewed-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@{#608803}

This is a rather small change that will not affect behavior until next
variations limit bump is needed. Code seems to be a little inconsistent
here, either string truncating or returning is redundant.

R=asvitkine@chromium.org, isherman@chromium.org

Change-Id: Idd4c10198026ac81165d921460c07834030b257a
Reviewed-on: https://chromium-review.googlesource.com/c/1339739Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Commit-Queue: Alexei Svitkine <asvitkine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608802}

Everyone will be editing this file and I don't want to destroy the c/b OWNERS'
review queue. Setting the OWNERS to myself and avi@ (aka "flags-team").

Bug: 897809
Change-Id: Ifc0afe1cea365f7398cfb14f5f4556f9bdeb818e
Reviewed-on: https://chromium-review.googlesource.com/c/1340519Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608801}

https://chromium.googlesource.com/external/github.com/KhronosGroup/SPIRV-Tools.git/+log/c37388f1addd..6a7b164f0c0e


git log c37388f1addd..6a7b164f0c0e --date=short --no-merges --format='%ad %ae %s'
2018-11-16 33432579+alan-baker@users.noreply.github.com Add shaderc smoketest configuration (#2057)


Created with:
  gclient setdep -r src/third_party/SPIRV-Tools/src@6a7b164f0c0e

The AutoRoll server is located here: https://autoroll.skia.org/r/spirv-tools-chromium-autoroll

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

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


TBR=dsinclair@chromium.org

Change-Id: I197714c2ff88116f4259e224bf484b3b703ad6f1
Reviewed-on: https://chromium-review.googlesource.com/c/1340379Reviewed-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@{#608800}

The field is true when there is no routing id for the main frame (ie
there is a proxy main frame), and false otherwise. So we can just use
that.

In the browser side it is actually a separate state, is_active_ on the
RenderViewHostImpl. However it is always set to true/false when the
main frame routing id is set as well. So we remove it and have
is_active() report if the main frame routing id is present instead.

R=alexmos@chromium.org
TBR=dcheng

Change-Id: I87c89f9d06ec99e769528e164e0ea0ed3d6fc6bc
Bug: 419087
Reviewed-on: https://chromium-review.googlesource.com/c/1336210
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608799}

TBR=nasko@chromium.org

Bug: 874782
Change-Id: I0ce30b5216b8ea7105f085e71bbb3e7dd1ab663a
Reviewed-on: https://chromium-review.googlesource.com/c/1340362Reviewed-by: Ella Ge <eirage@chromium.org>
Commit-Queue: Ella Ge <eirage@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608798}

Bug: 807399
Change-Id: I7ec3529451a8cd1690a210411ae7120e7223bf9e
Reviewed-on: https://chromium-review.googlesource.com/c/1338234Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Commit-Queue: Carlos IL <carlosil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608797}

|back_and_app_list_background_| is interfering with event targeting and
causing the app list button to be unresponsive, specifically in the
right side of the button. NOTE: This only repros on device, not on the
emulator.

Prevent |back_and_app_list_background_| from recieving events to prevent
this.

Bug: 900632
Change-Id: Ib2cd8e51cb560d84307904c86ae46ecc388e2424
Reviewed-on: https://chromium-review.googlesource.com/c/1338723Reviewed-by: Alex Newcomer <newcomer@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Commit-Queue: Alex Newcomer <newcomer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608796}

This CL moves CommandDispatcher ownership out of BVC
and up into BrowserCoordinator.

This CL migrates these coordinators:
- formInputAccessoryCoordinator
- snackbarCoordinator

The goal is to migrate all coordinators from BVC to
BrowserCoordinator.

Bug: 905524
Change-Id: If7fe78cabbda32a19b2c5420ede55a8e48930563
Reviewed-on: https://chromium-review.googlesource.com/c/1336560
Commit-Queue: edchin <edchin@chromium.org>
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Reviewed-by: edchin <edchin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608795}

Includes a fix to ComputeSHA256DigestOfPath required by the unit test

R=csharp@chromium.org

Bug: 830892
Change-Id: I72e6c1a4fcf21565357e5e6043ee93b480931a4f
Reviewed-on: https://chromium-review.googlesource.com/c/1338659Reviewed-by: Chris Sharp <csharp@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/master@{#608794}

Set params.bounds for widget within FullscreenShellSurface

Bug: 896710
Test: FullscreenShellSurfaceTest.Bounds
Change-Id: I250e99c177a2fd4ad15fab64d5a7929195441cb6
Reviewed-on: https://chromium-review.googlesource.com/c/1336000
Commit-Queue: Shawn Gallea <sagallea@google.com>
Reviewed-by: Daniel Nicoara <dnicoara@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608793}

The locked element attribute is useful on the context since it creates
an easy access point to add elements into.

R=chrishtr@chromium.org

Bug: https://github.com/chrishtr/display-locking/issues/30
Change-Id: I726a1db72373bdde261a808b38ccb17424a21348
Reviewed-on: https://chromium-review.googlesource.com/c/1336507Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: vmpstr <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608792}

And fix luci-milo.cfg to pass the check:

- Add jumbo-rel bots that were on the subwaterfalls to the main waterfall
- Add two Webkit builder bots to main waterfall
- Add Deterministic Linux (dbg) to chromium.linux subwaterfall
- Make sure each bot has a single name

project_pb2.py was created by grabbing the current version of
https://chromium.googlesource.com/infra/luci/luci-go/+/master/milo/api/config/project.proto
(9a3aea9951f) and running

  out/gn/protoc --python_out=. project.proto

I also want to check that the category names are consistent across main and
subwaterfalls, but this CL is already large enough, so let's do that in a
separate change.

Bug: none
Change-Id: I0088621e3b7e7fb9698dd3f0853460105bb8ccd0
Reviewed-on: https://chromium-review.googlesource.com/c/1301795
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Ryan Tseng <hinoka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608791}

This reverts commit 04f43afb.

Reason for revert: Looks like causing compile failure on Android CFI
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Android%20CFI/3645

Original change's description:
> [Autofill Assistant] Displays the difference in Details if there is any.
> 
> If there is a difference between current and new details it's
> highlighted and two chips are displayed; to allow move forward or
> go back (which closes CCT).
> 
> Screenshot: https://screenshot.googleplex.com/kOoC3B1frUp
> 
> Bug: 806868
> Change-Id: I95ff09c379398d5a5858aa3947d4c578f39b14c9
> Reviewed-on: https://chromium-review.googlesource.com/c/1335941
> Commit-Queue: Lukasz Suder <lsuder@chromium.org>
> Reviewed-by: Stephane Zermatten <szermatt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#608759}

TBR=mcarlen@chromium.org,szermatt@chromium.org,lsuder@chromium.org

Change-Id: I1a08ce61aedff0b51c7f71c27cd238e8359c0640
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 806868
Reviewed-on: https://chromium-review.googlesource.com/c/1340368Reviewed-by: Ella Ge <eirage@chromium.org>
Commit-Queue: Ella Ge <eirage@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608790}

This change:

1) Adds every current flag to flag-metadata.json
2) Enables AboutFlagsTest.EveryFlagHasMetadata to ensure that no future flags
   without metadata are added

Note that every flag has been set to expire in M76 per
<https://sites.google.com/a/chromium.org/dev/flag-ownership>.

Bug: 897809
Change-Id: I67ab00e0462a50bb1a1484154f225c6e82d46097
Reviewed-on: https://chromium-review.googlesource.com/c/1335867
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608789}

This is a first step in the migration of the different iOS'
authentication_service_* classes to the IdentityManager API. The
migration cannot be completed at this point as several APIs are not
available yet. This CL is basically passing the IdentityManager to the
different classes and using its API whenever appropiate instead of
directly calling SinginManager and TokenService.

Bug: 890817, 890818, 890819, 890820, 890820
Change-Id: I6df4466cc7f8ff1524e9736cb54376c0ee166070
Reviewed-on: https://chromium-review.googlesource.com/c/1335567Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Commit-Queue: Sergio Villar <svillar@igalia.com>
Cr-Commit-Position: refs/heads/master@{#608788}