GitLab

TBR=vmpstr

Bug: skia:2664
Change-Id: I736158e11434fdf561328e20fee6bef01ba43ae9
Reviewed-on: https://chromium-review.googlesource.com/c/1337827
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608837}

Bug: chromedriver:2663
Change-Id: I62c16df01d2f775cff86a26ef1e9acc5e95a09ce
Reviewed-on: https://chromium-review.googlesource.com/c/1338573Reviewed-by: John Chen <johnchen@chromium.org>
Commit-Queue: Tatiana Buldina <buldina@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608836}

This reverts commit c5612605.

Reason for revert: Breaking 11 autorollers into Chromium. See https://bugs.chromium.org/p/chromium/issues/detail?id=906114

Original change's description:
> Remove workaround made unnecessary by https://chromium-review.googlesource.com/c/1312234
> 
> Bug: 875037
> Change-Id: Ia4a6393237602b88bb0130d9f916972e930d95b3
> Reviewed-on: https://chromium-review.googlesource.com/c/1339339
> Reviewed-by: Hans Wennborg <hans@chromium.org>
> Commit-Queue: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#608783}

TBR=thakis@chromium.org,hans@chromium.org,martiniss@chromium.org,ehmaldonado@chromium.org

Change-Id: Ib8984eb1b295f9695758fc9700024927ba75d9ed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 875037
Reviewed-on: https://chromium-review.googlesource.com/c/1340521Reviewed-by: Ravi Mistry <rmistry@chromium.org>
Commit-Queue: Ravi Mistry <rmistry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608835}

This CL fixes IdentityService#getRuntimeHostBrowserPackageName(). In some
scenarios (like the default browser supporting WebAPKs for an unbound WebAPK),
calling HostBrowserUtils#getHostBrowserPackageName() updates the host browser
in shared preferences. This CL changes the call so that when the
IdentityService changes the host browser in Shared Preferences the identity
service also clears that WebAPK's shared preferences and data directory.

This CL:
- Splits HostBrowserUtils#getHostBrowserPackageName() into 2 functions:
  HostBrowserUtils#getCachedHostBrowserPackage()
    which returns the host browser cached in shared preferences if it is still
    installed. HostBrowserUtils#getCachedHostBrowserPackage() does not update any
    state.
  HostBrowserUtils#computeHostBrowserPackageClearCachedDataOnChange()
    which computes the new host browser. If the computed host browser is
    different than the cached host browser in shared preferences, the WebAPK's
    shared preferences and data directory are cleared.
- Reduces the number of functions with hidden calls to
  HostBrowserUtils#getHostBrowserPackageName().
  HostBrowserUtils#getHostBrowserContext() and
  HostBrowserUtils#getHostBrowserUid() are changed to take a package name
  parameter and are moved to WebApkUtils.

BUG=900464
TEST=HostBrowserUtilsTest.*

Change-Id: Ie6dea7de5eaca770d8a1261c2742308bc1165419
Reviewed-on: https://chromium-review.googlesource.com/c/1310569
Commit-Queue: Peter Kotwicz <pkotwicz@chromium.org>
Reviewed-by: Xi Han <hanxi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608834}

https://webrtc.googlesource.com/src.git/+log/7dbb7c311f00..645a3afceae0


git log 7dbb7c311f00..645a3afceae0 --date=short --no-merges --format='%ad %ae %s'
2018-11-16 solenberg@webrtc.org Remove unused/unnecessary things from ChannelSend.
2018-11-16 nisse@webrtc.org Add default values for PlayoutDelay in RTPVideoHeader.


Created with:
  gclient setdep -r src/third_party/webrtc@645a3afceae0

The AutoRoll server is located here: https://autoroll.skia.org/r/webrtc-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:linux_chromium_archive_rel_ng;luci.chromium.try:mac_chromium_archive_rel_ng

BUG=chromium:none,chromium:None
TBR=webrtc-chromium-sheriffs-robots@google.com

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

To help the server team distinguish better the traffic coming from
Chrome this CL adds a "Chromium" prefix to all Gaia sources in Chrome.
A lot of sources already had this prefix, but some did not.

This CL also removes the source parameter from ListAccounts calls.
This source was not consistently used (because ListAccounts often
returns a cached response), and was not really meaningful.
ListAccounts now always use the generic GaiaSource::kChrome.

TBR=treib, xiyuan, isherman, poromov, eugenebut

Bug: 895010
Change-Id: I8b3837d6ddf1d04cae252f382c2dee7b99f93c75
Reviewed-on: https://chromium-review.googlesource.com/c/1329971
Commit-Queue: David Roger <droger@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608832}

This change:
* removes COLOR_TAB_TEXT_INACTIVE and instead simply alpha-blends
  COLOR_TAB_TEXT
* removes disabled unit test that uses COLOR_TAB_TEXT_INACTIVE
* uses COLOR_BACKGROUND_TAB_TEXT_INACTIVE directly if a theme
  provides it

Bug: 901610, 859243
Change-Id: I7db13a7719284ac3e27ec3bfc122d6381430df26
Reviewed-on: https://chromium-review.googlesource.com/c/1334419
Commit-Queue: Collin Baker <collinbaker@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608831}

This is a reland of 04f43afb

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}

Bug: 806868
Change-Id: I419ac2bb513f6fdd496fba40162c92b839952df9
Reviewed-on: https://chromium-review.googlesource.com/c/1340329Reviewed-by: Stephane Zermatten <szermatt@chromium.org>
Commit-Queue: Lukasz Suder <lsuder@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608830}

post_task.h is now preferred over using dedicated base::Threads.

Furthermore, this code is preventing PlatformThread::Join() called by
Thread::Stop()) from being marked as a blocking operation in
https://chromium-review.googlesource.com/c/chromium/src/+/1324370.

This code was really only spinning up a thread to run a single task in
an MTA environment. All threads in the TaskScheduler (in the browser
process) are in an MTA.

R=grt@chromium.org

Bug: 707362
Change-Id: I5defbaeefc291f4b417c142cda60918a4cfd471d
Reviewed-on: https://chromium-review.googlesource.com/c/1338221
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608829}

Visually this doesn't change anything and makes autofill_assisant Chrome
UI style compliant.

Bug: 903508
Change-Id: I42cd48c8be5994aa2a3da877ba023a9228ad0eec
Reviewed-on: https://chromium-review.googlesource.com/c/1340160Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Mathias Carlen <mcarlen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608828}

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}