GitLab

Currently the shelf is fully transparent when the app
list is open. In thr new UI, we want to make it slightly
darker to distinguish it from the app list.

Bug: 878601
Change-Id: I5167e684e174c2d48334f45fa9b1c66e79ba32b7
Reviewed-on: https://chromium-review.googlesource.com/1194067Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Manu Cornet <manucornet@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587137}

This CL modifies ContentUriUtils::maybeGetDisplayName to catch any
Exception from getDisplayName and return null. Before, we were only
handling SecurityExceptions, but we've hit a couple of other Exception
types.

Bug: 877934
Change-Id: I0b7efa2b72ce7a5af19399e42a3e42d97773297c
Reviewed-on: https://chromium-review.googlesource.com/1194723Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: Tommy Steimel <steimel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587136}

This cl is a follow up to the following cl since mousewheel-scroll.html is
still flaky:
https://chromium-review.googlesource.com/c/chromium/src/+/1169779

This test consists of a few smoothscroll calls per promise_test and the
inaccuracy of each calls propagates to the next one and that's why we need
higher epsilon values for the approximation of scrollTop/Left to make sure
that the test is stable.

TBR=bokan@chromium.org

Bug: 865755
Change-Id: I438c285ef4502bc09450e49d38b0ae31a08594cd
Reviewed-on: https://chromium-review.googlesource.com/1195161Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sahel Sharify <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587135}

Parse responses from the Gaia OAuth multilogin endpoint to create
canonical cookies.

Change-Id: I7e5fdf74211914784dc96c6347751ed7a7120beb
Reviewed-on: https://chromium-review.googlesource.com/1179746
Commit-Queue: Valeriya Sinevich <valeriyas@google.com>
Reviewed-by: David Roger <droger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587134}

This CL is supposed to supersede https://chromium-review.googlesource.com/c/chromium/src/+/1102165

Bug: 849781
Change-Id: I0412f5f921bebe853d8649418ff6fe344e5d5ab2
Reviewed-on: https://chromium-review.googlesource.com/1194227Reviewed-by: vitaliii <vitaliii@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Reviewed-by: Nathan Parker <nparker@chromium.org>
Commit-Queue: Markus Heintz <markusheintz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587133}

Design doc: https://docs.google.com/document/d/1yh_-ayeaFV0EjuR51U641zbrPAB0Baqj6UrC9bT9iqQ/edit#heading=h.y7amr11fn0tb

This CL implements "intrinsicsize" attribute for HTMLImageElement.
The value of "intrinsicsize" overrides the intrinsic size:

1. When no width and (or) height is specified, the value of
"intrinsicsize" will be used to determine the area to layout the image
content.

2. natualWidth and naturalHeight will return the density corrected
value of "intrinsicsize".

See explainer: https://github.com/ojanvafai/intrinsicsize-attribute/blob/master/README.md

BUG: 874629
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I519f01841ee3e761b22874dbecd74f7e6843e2a9
Reviewed-on: https://chromium-review.googlesource.com/1150725
Commit-Queue: Luna Lu <loonybear@chromium.org>
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#587132}

This ExtensionPolicyMigrator uses the CRE's existing policies as a
fallback. That way, existing setups that set those policies will be more
compatible with the new version of Enterprise Reporting.

Bug: 877120
Change-Id: I6e8b8e46450ea8e3ed8e073e7b3a8c545864f0e3
Reviewed-on: https://chromium-review.googlesource.com/1191743Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org>
Reviewed-by: Owen Min <zmin@chromium.org>
Commit-Queue: Nicolas Ouellet-Payeur <nicolaso@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587131}

A normal immersive session shutdown triggers this error handler,
and stopping the render loop lost a pending gamepad_callback_,
so future immersive sessions weren't seeing the controllers
anymore. Instead, keep the render loop running, it'll be cleaned
up when exiting the page entirely.

BUG=875187

Cq-Include-Trybots: luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I89a333a9cd104069d6e228248608957bec665a91
Reviewed-on: https://chromium-review.googlesource.com/1194252Reviewed-by: Bill Orr <billorr@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587130}

[ios] Create new AppBarViewControllerPresenting protocol and ConfigureAppBarViewControllerWithCardStyle methods

This is in preparation of migration from MDCAppBar to MDCAppBarViewController. Classes will slowly be moved over to this protocol and configure method and the old ones will be removed after all have been migrated.

Bug: 874471
Change-Id: I2f43f9fcbf917835d76099700c66ca771d4cf1de
Reviewed-on: https://chromium-review.googlesource.com/1194322Reviewed-by: Mark Cogan <marq@chromium.org>
Commit-Queue: Chris Lu <thegreenfrog@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587129}

The tab grid page control wasn't following the API contract for UIControl touch handling. This was causing some action methods to be called twice for the same event.

This CL fixes this by:

 - Removing the 'dragging' property, which duplicated the superclass 'tracking' property.
 - Calling the superclass touch tracking methods where required.
 - Allowing the superclass to send UIControlEventTouchUpInside actions for normally ended touches.
 - Not triggering the tap gesture handler if the control is currently tracking touches.

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

This queues a report through the Reporting API whenever camera or
microphone access are requested through getUserMedia, in a frame in
which either the 'camera' or 'microphone' features are not allowed
according to feature policy.

Bug: 867471
Change-Id: Id54caf385f710f02b94010e642c7eb395e6a831f
Reviewed-on: https://chromium-review.googlesource.com/1191417Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587127}

This CL modifies SyncPreference.getSyncStatusSummary to return 'Sync off
for accountname@gmail.com' if UNIFIED_CONSENT feature is enabled and the
user is signed in, but Chrome Sync is disabled. This string is used as
the summary for SignInPreference and SyncPreference.

Bug: 814728
Change-Id: I34dda1714e2a283bdec9bdc170faec08f2a8fa15
Reviewed-on: https://chromium-review.googlesource.com/1195486Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Boris Sazonov <bsazonov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587126}

This CL changes strings in SignOutDialogFragment if UNIFIED_CONSENT
feature is enabled.

Bug: 814728
Change-Id: I82020823d381ca7b5c12a32afdd2014a6dd2c145
Reviewed-on: https://chromium-review.googlesource.com/1194365Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Commit-Queue: Boris Sazonov <bsazonov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587125}

Move the composited element check from CanStartAnimationOnCompositor to
CheckCanStartEffectOnCompositor because the effect has sufficient context
to use the correct namespace to map the object ID to the compositor
element ID, whereas the animation does not.

Bug: 855702
Cq-Include-Trybots: 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: Ia490fb07780586ddd5b5059671c3611139a25ce8
Reviewed-on: https://chromium-review.googlesource.com/1170238
Commit-Queue: Peter Mayo <petermayo@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587124}

|filter| is a RepeatingCallback and might still be needed after this point.
There is no other user of |filter| yet but if one would be added, the
filter would not be applied.

Change-Id: Ic0289ec7536cde46ac1e8719157d23a4a79745e7
Reviewed-on: https://chromium-review.googlesource.com/1193894Reviewed-by: Martin Šrámek <msramek@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587123}

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/0b8e71b2..d4c79096

Please follow these instructions for assigning/CC'ing issues:
https://github.com/v8/v8/wiki/Triaging%20issues

Please close rolling in case of a roll revert:
https://v8-roll.appspot.com/
This only works with a Google account.

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_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;luci.chromium.try:android_optional_gpu_tests_rel

TBR=hablich@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

Change-Id: I62b5227643bbb98774fb08ce895adc4851c32c07
Reviewed-on: https://chromium-review.googlesource.com/1195429Reviewed-by: V8 Autoroller <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: V8 Autoroller <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#587122}

Add a function that helps to easily filter out and pick a selection of
builders and test types from shell-style wildcard patterns in the
command line.

Bug: 875251
Change-Id: I5cdae91f02cd2a69980972cc09dfbe319b31432d
Reviewed-on: https://chromium-review.googlesource.com/1188675Reviewed-by: Ned Nguyen <nednguyen@google.com>
Commit-Queue: Juan Antonio Navarro Pérez <perezju@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587121}

When entering fullscreen we shouldn't need to set scroll to 0,0. This
fixes fullscreening an element that has scroll offset.

BUG=693075,684920

Change-Id: I2acf27eb2641731d580865d38e1a1495f6aee7de
Reviewed-on: https://chromium-review.googlesource.com/1191664
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587120}

This reverts commit ed0a1be1.

Reason for revert: Causes a test failure in official builds:
https://uberchromegw.corp.google.com/i/official.desktop.continuous/builders/win%20trunk/builds/91463

Original change's description:
> Fix the issue with 3rd-party DLL blocking and IAttachmentExecute
> 
> Because the IAttachmentExecute interface will invoke registered
> third-party IOfficeAntiVirus provider, it's possible to put Chrome
> in a state where all downloads fail if a DLL needed by one of the
> provider is blocked.
> 
> This CL introduces 2 temporary solutions that aims to separately
> address the issue for enterprise and regular users. The long-term
> solution is to move the call to the attachment services to a
> utility process where third-party DLL injection is explicitly
> allowed.
> 
> For enterprise users, simply never enable the blocking feature on
> domain-joined machines.
> 
> For regular users, add a feature (InvokeAttachmentServices) that
> allows us to no longer invoke the IAttachmentExecute interface and
> instead use the fallback code path that manually sets the Zone
> Identifier (Mark of the Web).
> 
> The fallback code was a bit outdated because Windows 10 now adds the
> HostUrl and ReferrerUrl data into the Zone Identifier. This CL adds
> a new feature that writes this data similarly to how the
> IAttachmentExecute interface does. This change is also behind a new
> feature (AugmentedZoneIdentifier).
> 
> Finally, the chrome.mediaGalleries API
> (https://developer.chrome.com/apps/mediaGalleries) was also using
> the IAttachmentExecute API. A third feature now controls whether
> the mediaGalleries component uses the same function as the download
> manager, in order to benefits from the changes described above.
> 
> Bug: 870998
> Change-Id: I50c5d804c469b2499f1e6ec6998e146baaaace7a
> Reviewed-on: https://chromium-review.googlesource.com/1188864
> Reviewed-by: Asanka Herath <asanka@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Chris Hamilton <chrisha@chromium.org>
> Reviewed-by: Min Qin <qinmin@chromium.org>
> Commit-Queue: Patrick Monette <pmonette@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#586940}

TBR=chrisha@chromium.org,thestig@chromium.org,qinmin@chromium.org,pmonette@chromium.org,asanka@chromium.org

Change-Id: I9dd91dd84df4d7a7eddc8f2f6e264720e26b1e3b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 870998
Reviewed-on: https://chromium-review.googlesource.com/1195436Reviewed-by: Reid Kleckner <rnk@chromium.org>
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587119}

This cleans up the logic for restoring ChromeVox range when exiting from the panel. @Randy as FYI.

The event stream has changed since this was  last visited; focus events can come before and after the blur on the panel), so it's not a reliable signal to start performing our callback. Scheduling the callback on the next event loop seems to work.

Change-Id: Iee49fd489647ae8364722d96284faf9718075205
Reviewed-on: https://chromium-review.googlesource.com/1194987
Commit-Queue: David Tseng <dtseng@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587118}

This CL uses ScopedBlockingCall to mark blocking calls in /base/win.

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

Bug: 874080
Change-Id: I0fa6e881ea4b00d0c31b3c8026e095950764a627
Reviewed-on: https://chromium-review.googlesource.com/1191101Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587117}

Bug: N/A
Change-Id: Ic76b80f16c2dfd94f0615f004ec63a8cfeb6bfe8
Reviewed-on: https://chromium-review.googlesource.com/1194013
Commit-Queue: Markus Heintz <markusheintz@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587116}

In the following case false positive on accounts.google.com happens:

1.Suppose that the user has 2 Gaia credentials (with usernames and passwords
u1/p1 and u2/p2). Let u1 be saved in Password Manager.

2.The user go to accounts.google.com, u1/p1 are autofilled by CPM (a username
field is visible, a password field is invisible).

3.The user is typing u2 in the username field and is clicking next button.

4.At that moment the page removes password form from the DOM and Password
Manager incorrectly thinks that it was successful submission with u2/p1

Video is on bug 764663 (actual_bubble).

This CL fixes this by ignoring accounts.google.com forms with submitted
type DOM_MUTATION_AFTER_XHR, which means that the form disappeared from the
DOM, without any visible submission.

Similar issues might be on different sites, this CL fixes only
accounts.google.com, because
1.A general solution is unlikely without more complex changes and server-side
support.
2.accounts.google.com is crucial for Chrome, in particular because it serves
the Chrome sign-in page.


Bug: 758155, 764663

Change-Id: I44f9878673bf8f419c49f63220335f6c0f26a6e4
Reviewed-on: https://chromium-review.googlesource.com/1194011
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587115}

This is a reland of 16ab50cc
https://chromium-review.googlesource.com/c/chromium/src/+/1184724
The original change was once reverted as it failed on
linux_chromium_chromeos_asan_rel_ng.

Original change's description:
> Add a container view of MessageView to be used for swipe control.
>
> This change adds a new container view between MessageListView and
> MessageView. The new view is intended to host buttons views for swipe
> control.
> This change also returns slided notifications when another notification
> swipe is started, so as to ensure only one swipe control can be opened.
>
> Bug: 840497
> Change-Id: Ica92933a8d3f5d92caa43a5c926252681873ede1
> Reviewed-on: https://chromium-review.googlesource.com/1184724
> Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org>
> Commit-Queue: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#586198}

Bug: 840497,877983
Test: ash_unittests --gtest_filter=MessageCenterViewTest.*:MessageListViewTest.*:ArcNotificationContentViewTest.*
Change-Id: I0c53b727ab317364224894ed8e0853ae10125337
Reviewed-on: https://chromium-review.googlesource.com/1192468Reviewed-by: Stefan Kuhne <skuhne@chromium.org>
Reviewed-by: Evan Stade <estade@chromium.org>
Reviewed-by: Tetsui Ohkubo <tetsui@chromium.org>
Commit-Queue: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587114}

This CL uses ScopedBlockingCall to mark blocking calls in /content/browser/web_contents/web_contents_android.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=tedchoc@chromium.org

Bug: 874080
Change-Id: I83ad9ab928cecc0e1442f76f6036e185d1d5f29a
Reviewed-on: https://chromium-review.googlesource.com/1191785
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587113}

This CL uses ScopedBlockingCall to mark blocking calls in /content/browser/cocoa/system_hotkey_helper_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=tapted@chromium.org

Bug: 874080
Change-Id: I43d6fa7e8f26aea2cfeab0d028ae423b9d31d3ed
Reviewed-on: https://chromium-review.googlesource.com/1191679Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587112}

Direct access to URLRequestContext, including its
net::TransportSecurityState is going away; things should
go through NetworkContext now.

Bug: 873777
Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: Ibfb52cd027f5b417e05a35baf902ad81ba4df24b
Reviewed-on: https://chromium-review.googlesource.com/1183990Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587111}

This CL uses ScopedBlockingCall to mark blocking calls in /components/crash/content/browser/crash_dump_manager_android.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=isherman@chromium.org

Bug: 874080
Change-Id: I45cbb6abf8867f25180b5837640cb3aec0c9d389
Reviewed-on: https://chromium-review.googlesource.com/1191140
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587110}

This queues a report through the Reporting API whenever
[webkit]RequestFullscreen is called from a frame in which fullscreen is
not allowed according to feature policy. Checking
[webkit]fullscreenAllowed does not trigger reports.

Bug: 867471
Change-Id: I4e7077aea66246d712e549b79b6154c1a596d74c
Reviewed-on: https://chromium-review.googlesource.com/1191482
Commit-Queue: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587109}

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

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

Bug: 874080
Change-Id: I002dbf2568e14095e79910d01499623fa2414976
Reviewed-on: https://chromium-review.googlesource.com/1191229Reviewed-by: Robert Kaplow (slow) <rkaplow@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587108}

https://skia.googlesource.com/skia.git/+log/33f34556b5fc..a81c2be75adc


git log 33f34556b5fc..a81c2be75adc --date=short --no-merges --format='%ad %ae %s'
2018-08-29 brianosman@google.com Remove lazy image color space hacks for gray


Created with:
  gclient setdep -r src/third_party/skia@a81c2be75adc

The AutoRoll server is located here: https://autoroll.skia.org/r/skia-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=master.tryserver.blink:linux_trusty_blink_rel;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=stephana@chromium.org

Change-Id: Ib8e4bb496bb0470e24674516bf7cce93307496ec
Reviewed-on: https://chromium-review.googlesource.com/1195428Reviewed-by: skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: skia-chromium-autoroll <skia-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#587107}

Using wpt-import in Chromium 7ee2ff27.

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

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

Directory owners for changes in this CL:
jsbell@chromium.org:
  external/wpt/encoding
worker-dev@chromium.org:
  external/wpt/worklets

NOAUTOREVERT=true
TBR=robertma

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

Bug: 493368
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: Iff0a4e01d2202899927e226886d2d54eee006a29
Reviewed-on: https://chromium-review.googlesource.com/1194223
Commit-Queue: Jérôme Lebel <jlebel@chromium.org>
Reviewed-by: Peter Lee <pkl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587105}

Bug: 878309
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: If8a07e6f04a1b18fa08dcff74fcc32cb37a74022
Reviewed-on: https://chromium-review.googlesource.com/1193879
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587104}

This is possible thanks to tonikitoo@ porting it to newer APIs;
desirable since users of Profile::GetRequestContext may break soon,
so less users of that method is reassuring.

Bug: 844968
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: I2a92cc05d40764f5a1c6358a3a571b2e3cd8f191
Reviewed-on: https://chromium-review.googlesource.com/1191462Reviewed-by: Tatiana Gornak <melandory@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587103}

Change-Id: Ib2a08edb84ef18f0af18ab47b6430f9554b58c51
Reviewed-on: https://chromium-review.googlesource.com/1170715Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Hajime Hoshi <hajimehoshi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587102}

It appears that this test doesn't show up as flaky test anymore so
remove the test expectation.

BUG=848334

Change-Id: I85e6d6cd7bcf700113fa53bd78dac2322c4869a2
Reviewed-on: https://chromium-review.googlesource.com/1194489Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587101}

From a manual review of build 9295.

The tests were changed to testharness that NG's baselines for
different space collapsing are no longer needed.
  fast/spatial-navigation/*

The base expectation is updated, but NG needs rebaseline for
different space collapsing on text dump.
  images/color-profile-munsell-adobe-to-srgb.html

TBR=eae@chromium.org, mstensho@chromium.org
NOTRY=true

Bug: 591099
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I5ee5a54440bf348bd458a5b697d3b03eb2e289b6
Reviewed-on: https://chromium-review.googlesource.com/1195294
Commit-Queue: Koji Ishii <kojii@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587100}

- Created unittest for testing the logic of GetPatternsScopingType.

Bug: 876664
Change-Id: Id320a0783c65466dbe7d08545a60ac1489762d8d
Reviewed-on: https://chromium-review.googlesource.com/1189944
Commit-Queue: Kamila Hasanbega <hkamila@google.com>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#587099}

The AutoRoll server is located here: https://autoroll.skia.org/r/fuchsia-sdk-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:fuchsia_arm64_cast_audio;luci.chromium.try:fuchsia_x64_cast_audio
TBR=cr-fuchsia+bot@chromium.org

Change-Id: I0efc5fb47e10c7fe0ba21c98bf9d55a81a9345a2
Reviewed-on: https://chromium-review.googlesource.com/1195427Reviewed-by: Fuchsia SDK Autoroller <fuchsia-sdk-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: Fuchsia SDK Autoroller <fuchsia-sdk-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#587098}