GitLab

This change enables Dedicated Workers to inherit the Feature Policy of
the context that created the worker.

Bug: 843780
Change-Id: I2afaf7ee8547853a2f1c639961c78260efbd9633
Reviewed-on: https://chromium-review.googlesource.com/1091635
Commit-Queue: Ovidio Henriquez <odejesush@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Chong Zhang <chongz@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568102}

Bug: 850719
Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I63fb963d90fe8b240fce80b52f8b852d5c77f311
Reviewed-on: https://chromium-review.googlesource.com/1101923
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568101}

Change the testing scheme for k-rate panner to verify that the output
is piecewise constant for a constant source when the automation rate
is set to k-rate. Reduce the duration of the test as well; Just a few
render quanta is enough to verify that the output is piece-wise constant
and different from the a-rate output.

Also updated k-rate-constant-source.html to use the same doTest method
since the special case is supported.

Didn't actually figure out the underlying flakiness of the original
test.

Bug: 841856
Change-Id: I8e9807e530fc3b1452bae521a2660be3fbe104f9
Reviewed-on: https://chromium-review.googlesource.com/1076809Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568100}

Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I3c25b29dfbb00edbb179003d17cfe061a32ebce3
Reviewed-on: https://chromium-review.googlesource.com/1100086
Commit-Queue: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568099}

...to standard Chrome icon color.

Bug: 780835
Change-Id: Ie377265d7f50a8598075aca9b7868239750b2c6f
Reviewed-on: https://chromium-review.googlesource.com/1104787
Commit-Queue: Kevin Bailey <krb@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568098}

Change-Id: I840e7e4c5b02b346e7edab78a4264d6b22bb4a9d
Reviewed-on: https://chromium-review.googlesource.com/1103202
Commit-Queue: Rayan Kanso <rayankans@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568097}

This will allow a narrower guestimate at the validity of performance
measurements relating to load events.

Bug: 755840
Change-Id: I7087c5840106102844ef7518c0ad42648f4abe3e
Reviewed-on: https://chromium-review.googlesource.com/1101304
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568096}

Change-Id: I2dcfc3411ba478355a927874cf4b3938276288a5
Reviewed-on: https://chromium-review.googlesource.com/1103154Reviewed-by: Steven Holte <holte@chromium.org>
Commit-Queue: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568095}

This is flaking on Viz/Windows/Intel. Not clear how to select viz
as a config in the GPU expectations module. Suppress this on the
Windows Intel config for now.

Bug: 853762
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I83bc2699d7b7a904eb68b97886d1c91025307d31
Tbr: kbr@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/1104783Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568094}

This reverts commit edb91802.

Reason for revert: Suspecting flaky crashes:
Win10 FYI Release (Intel HD 630) vr_browser_test

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win10%20FYI%20Release%20%28Intel%20HD%20630%29/974

Received fatal exception EXCEPTION_ACCESS_VIOLATION
Backtrace:
	(No symbol) [0x6A3B41A0]
	(No symbol) [0x6A3B174E]
	device::OpenVRRenderLoop::SubmitFrameWithTextureHandle [0x052D8C2F+323]
	device::mojom::VRPresentationProviderStubDispatch::Accept [0x0399C195+1089]
	device::mojom::VRPresentationProviderStub<mojo::RawPtrImplRefTraits<device::mojom::VRPresentationProvider> >::Accept [0x052D9963+19]
	mojo::InterfaceEndpointClient::HandleValidatedMessage [0x03562159+541]
	mojo::FilterChain::Accept [0x0441F4F3+131]
	mojo::InterfaceEndpointClient::HandleIncomingMessage [0x03563006+106]
	mojo::internal::MultiplexRouter::ProcessIncomingMessage [0x0356658A+698]
	mojo::internal::MultiplexRouter::Accept [0x03566111+295]
	mojo::FilterChain::Accept [0x0441F4F3+131]
	mojo::Connector::ReadSingleMessage [0x03560830+364]
	mojo::Connector::ReadAllAvailableMessages [0x03560F0D+87]
<snip>

Bug: 853790

Original change's description:
> Add an interface to communicate between the fake openvr and tests
> 
> This change creates a way for tests to control the behavior of
> the fake OpenVR, and allows devices to send information up to
> tests.
> 
> BUG=801034
> 
> Change-Id: Ie0fe035ada9553114c054717f52788d375d5c62f
> Reviewed-on: https://chromium-review.googlesource.com/1100157
> Commit-Queue: Bill Orr <billorr@chromium.org>
> Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#567725}

TBR=jam@chromium.org,bsheedy@chromium.org,billorr@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 801034
Change-Id: Ie55238c46b1d9c34d92bee2b6324539912b47846
Reviewed-on: https://chromium-review.googlesource.com/1104837Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Bill Orr <billorr@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568093}

https://android-review.googlesource.com/c/platform/system/connectivity/shill/+/181040
replaced the "HostName" property in the shill Manager interface with a new
"DHCPProperty.Hostname" property. However, the migration was partially done,
which has been fixed by CL:1102152. This CL updates the code on the Chrome side
accordingly.

Bug: 852035
Change-Id: Ib0d7fc7e82f13b9f77cda13324702f610d952f61
Reviewed-on: https://chromium-review.googlesource.com/1104312Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Commit-Queue: Ben Chan <benchan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568092}

We would like to start a Finch trial for surface sync on Android soon.
This CL re-enables Android-specific surface invariants violations checks
on Android by removing code in RenderWidgetHostImpl that bypasses those
checks. This CL also ensures that when the background transparency
changes a new LocalSurfaceId is allocated as this matches the behavior
pre-surface-sync.

Bug: 672962, 789259, 801350
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iad2dc6c508770314ea33eb53f05944609f29b0b9
Reviewed-on: https://chromium-review.googlesource.com/1104315Reviewed-by: Saman Sami <samans@chromium.org>
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568091}

NavigationRequest calls ProceedWithResponse if network service
isn't enabled because MojoAsyncResourceHandler depends on this.
Since we want to start using BlobURLLoader before network service
ships, this means BlobURLLoader.ProceedWithResponse can also be
called and thus shouldn't be a NOTREACHED. Replace with an empty
implementation instead since it isn't pausing the response anyway.

Bug: 800901
Change-Id: I7edc6a1b20f5aac2fa312a3a2770424464cf12df
Reviewed-on: https://chromium-review.googlesource.com/1103061
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568090}

While not as common of a pattern as storing base::Time in Prefs, it
does show up in a few places, and is the logical continuation of the
Set/GetTime() methods that we currently have.

Change-Id: Ib38c2f4b431733bc4f40323756ea5fc6f68dfbed
Reviewed-on: https://chromium-review.googlesource.com/1103147
Commit-Queue: Sky Malice <skym@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568089}

Applies a 20% black overlay on a custom background image, uses white font text,
and a white settings icon.

Bug: 850312, 851285
Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: Ia6cab65d08bc6e54a42b78732b42b9cd4d8dc549
Reviewed-on: https://chromium-review.googlesource.com/1098557
Commit-Queue: Ramya Nagarajan <ramyan@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568088}

R=amineer@chromium.org

Cq-Include-Trybots: luci.chromium.try:closure_compilation;luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Ida6455c2902b342a5f1fb9cfab0a3cb9bf17836c
Reviewed-on: https://chromium-review.googlesource.com/1104894Reviewed-by: Krishna Govind <govind@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568087}

Bug: 852922
Change-Id: I2db33fb3dd5f13dda3420965e72d8aa92695ffe5
Reviewed-on: https://chromium-review.googlesource.com/1103539
Commit-Queue: Daniel Rubery <drubery@chromium.org>
Reviewed-by: Varun Khaneja <vakh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568086}

This patch removes CachedRunSegmenter, introduced in
CL:1053346, because CL:1083914 supercedes this improvement
by LayoutNG not invoking RunSegmenter multiple times.

Other recent changes such as pre-allocating are preserved
as they are still valid.

Bug: 636993, 645035
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I83e74a58b79b856df1f046b7fa90b485609cd85a
Reviewed-on: https://chromium-review.googlesource.com/1087191Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568085}

Instead of this ownership model

  LoginDisplayHost owns ExistingUserController owns LoginDisplay
  LoginDisplayHost owns WebUIScreenLocker owns LoginDisplay

switch to

  LoginDisplayHost owns ExistingUserController, LoginDisplay

This makes it clear that the LoginDisplay instance has one owner, and
that it shares the same lifetime as LoginDisplayHost.

Bug: 851012
Change-Id: I80cb56d8fc244ce5331046ba31defba4cd77c45f
Reviewed-on: https://chromium-review.googlesource.com/1093741Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Jacob Dufault <jdufault@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568084}

Bug: none
Test: manual on device
Change-Id: I93f2ce564ac1c519c0769432822f64ee858f03db
Reviewed-on: https://chromium-review.googlesource.com/1104313Reviewed-by: Alex Sakhartchouk <alexst@chromium.org>
Commit-Queue: Ryan Daum <rdaum@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568083}

This is needed for browser-initiated same-document back-forward
navigations. When the context is created it is unknown that navigation
will be a same document navigation, so the flag should be updated
later.

Bug: 853063
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I93b4a7e2cfb9de56bd211d11298073fed28953ab
Reviewed-on: https://chromium-review.googlesource.com/1102116Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568082}

This CL adds tests that verify that Cross-Origin Read Blocking (CORB)
won't block HTTP responses for requests initiated by plugins that have
been granted universal access (like Flash which has its own CORS-like
mechanism - crossdomain.xml).

In addition to running tryjobs, I've also tested this CL by temporarily
editing CrossSiteDocumentResourceHandler::ShouldBlockBasedOnHeaders to
comment out the exception carved out for plugins (the new
TestTrustedCorbEligibleRequest test expectedly failed with such an edit
both with and without NetworkService).

Bug: 846339
Change-Id: I7b7befff3018ed5a7bd834b2bf0507c2e1f6365b
Reviewed-on: https://chromium-review.googlesource.com/1101300
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568081}

We have introduced maxWidthLandscape and maxWidthPortrait, so maxWidth
can be removed, because:

1. Functionality overlap, and unnecessary complexity when using this
widget.

2. maxWidthLandscape/maxWidthPortrait can force people to notice
the difference between landscape and portrait views.

TBR=twellington@chromium.org

Bug: 852545
Change-Id: I3532701b3886969d8232a348ae36738ea3dc4259
Reviewed-on: https://chromium-review.googlesource.com/1099774
Commit-Queue: Xing Liu <xingliu@chromium.org>
Reviewed-by: Becky Zhou <huayinz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568080}

These are the params that we have been using in the server-side field trial.

Bug: 760294
Change-Id: I625e8c41b8acc005edaec8515b617198013b775a
Reviewed-on: https://chromium-review.googlesource.com/1104778Reviewed-by: Ryan Sturm <ryansturm@chromium.org>
Commit-Queue: Tarun Bansal <tbansal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568079}

Also changes some BookmarksTestCase instance methods to class methods to be shared amongst test
cases.

Bug: 853348
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I99f57091ff0a05a9caa90a60074c0da77cf68920
Reviewed-on: https://chromium-review.googlesource.com/1103610
Commit-Queue: Sergio Collazos <sczs@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568078}

Add VLOG for
1) Token status
2) Enrollment process
3) Policy fetch process (not include the one sent after cache loading)
4) Policy cache load request.

The log will be enabled by --vmodule=machine_level_user_cloud_policy_*=1

Bug: 853364
Change-Id: I8fc6a210513bccd55e3b5d4388969ffc713ce27f
Reviewed-on: https://chromium-review.googlesource.com/1103303
Commit-Queue: Owen Min <zmin@chromium.org>
Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568077}

Bug: 844914
Change-Id: Ie38db098ec0e540b4425a42500c43263ed57119f
Reviewed-on: https://chromium-review.googlesource.com/1102492Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Mark Pilgrim <pilgrim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568076}

This patch ensures graphics layers are marked for incremental
invalidation when their size changes. This fixes a regression
from https://crrev.com/564140 where the scrolling contents layer
would not be invalidated when hiding browser controls.

Bug: 851881
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I88885fc389c8a32a19e7aac8a0ff74689ead55a0
Reviewed-on: https://chromium-review.googlesource.com/1103439
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568075}

I found a bug with the incognito toggle animation in the new Android horizontal
tab switcher if you hit the toggle button while on the last or second-to-last
tab and have >= 6 tabs open. On the second-to-last tab, toggling back to the
stack with >= 6 tabs is jerky, and on the last tab, the animation appears to not
run at all. The fix is very simple, but the cause of the bug, and why it only
occurs with >= 6 tabs open, is somewhat involved.

The incognito toggle animation works by sliding the (up to) 3 visible tabs off
the screen. When toggling from normal to incognito mode, the tabs are slid to
the left. If you do this on the second-to-last or last tab, the last tab is one
of the tabs that gets slid off. getMinScroll() normally returns the scroll
offset of the last tab (with a sign flip) as the minimum allowed overall scroll
offset, to prevent you from scrolling past the last tab when we're not running
an animation. During the switch away animation, we set
mSuppressScrollClamping = true to suppress this clamping. It turns out that this
is currently getting reset to false in finishAnimation() before we run the
switch to animation. This means that with enough tabs open (turns out to be 6
on my test device), the clamped overall scroll offset tracks the last tab,
causing the tabs to appear stationary.

The reason the bug does not occur with fewer tabs open is that getMinScroll()
pulls the scroll offset from the last tab on-screen, which turns out to be
negative for the <= 5 tab case, which becomes positive after doing the sign
flip. MathUtils.clamp() flips the min/max arguments if min > max, so for the
<= 5 tab case, we actually end up using the value of getMaxScroll() (0) for the
min scroll for part of the animation, which masks the problem.

The fix is to set mSuppressScrollClamping = true in runSwitchToAnimation() (we
already have logic to set it back to false when the animation ends).

Bug: 853362,831359
Change-Id: I655ae2c2a4a5a58877e463c84c7c42aeb47a4790
Reviewed-on: https://chromium-review.googlesource.com/1103299Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568074}

Unfortunately, it does not appear possible to set RLIMIT_AS such that it will
both (a) be high enough to support V8's and WebAssembly's address space
requirements while also (b) being low enough to mitigate exploits using integer
overflows that require large allocations, heap spray, or other memory-hungry
attack modes.

Bug: 800348
TBR: jln
Change-Id: I4ec234709a4e49abde1c22f9c63a87bac107b8a0
Reviewed-on: https://chromium-review.googlesource.com/1097553
Commit-Queue: Chris Palmer <palmer@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568073}

All of the (direct) subclasses of LayoutSVGModelObject (LayoutSVGImage,
LayoutSVGShape and LayoutSVGContainer) have the same implementation of
this method, so we can push it up to the common base class.

Change-Id: Ief6d4502917c87505ddab436a3c005597615c49b
Reviewed-on: https://chromium-review.googlesource.com/1104344Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#568072}

This goes through a code-path where the blob URL token was incorrectly
dropped, so make sure we copy the token from the old FrameLoadRequest to
the new FrameLoadRequest.

Adds a web-platform-test to verify this behavior, and enables the blob URL browser
tests to also run with MojoBlobURLs enabled. This browser test required another
bug fix in RenderFrameHostImpl.

Cq-Include-Trybots: luci.chromium.try:linux_mojo
Bug: 800901
Change-Id: I87eee70e784dd8cb273f8671f37b00d8a93d9543
Reviewed-on: https://chromium-review.googlesource.com/1102820Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568071}

This reverts commit 798beff1.

Reason for revert: The original bug has been made irrelevant by the
switch to lld, so this workaround is no longer needed. Additionally,
crbug.com/817797 reports a failure sort of *caused* by this
workaround.

Original change's description:
> Check for LNK1201 and retry links when it occurs
>
> LNK1201 seems to be happening increasingly frequently on our debug x64
> builds for no clear reason. Subsequent builds tend to succeed so this
> change updates our link wrapper to retry links when this error is hit.
>
> This retry logic may solve the problem. If not then it gives us more
> evidence about the problem, including a backup copy of the PDB that
> might be helpful in investigating.
>
> Bug: 782660
> Change-Id: Iad60648425a01e07a20d108fcc5b74acaead9ee8
> Reviewed-on: https://chromium-review.googlesource.com/769333
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#516769}

R=dpranke@chromium.org,brucedawson@chromium.org

Bug: 782660,817797
Change-Id: Ifd03fecabdb462328898c7ef5253406cab2c570c
Reviewed-on: https://chromium-review.googlesource.com/1103377
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568070}

https://chromium.googlesource.com/angle/angle.git/+log/50cf2be0758b..f6fd48fd329f


git log 50cf2be0758b..f6fd48fd329f --date=short --no-merges --format='%ad %ae %s'
2018-06-18 lucferron@chromium.org Vulkan: Get uniform for array of matrices fix


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

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

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: Iaefefe6a5b5d89d23257891b836a0b0df6754dd2
Reviewed-on: https://chromium-review.googlesource.com/1104717Reviewed-by: angle-chromium-autoroll <angle-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: angle-chromium-autoroll <angle-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#568069}

Commit b6c4e590 ("Grant generic sensor permission for Android WebView")
started always granting sensors permission requests in
GetPermissionStatus().

However, commit 94c082d4 ("[sensors] Add sensors usage indicator") caused
SensorProviderProxyImpl to query PermissionManager via RequestPermission()
before making a given sensor available.

The Android WebView case was overlooked, and its RequestPermission()
implementation was still denying all requests for sensors. Update the policy
to always-grant, and while at it make CancelPermissionRequest() not show a
"not implemented" error for sensor requests, as the requests are always
granted anyway.

Doing so re-allows the WebView to provide device motion/orientation data to
users, while SensorProviderImpl::GetSensor() still prevents other types of
sensors from being accessed, just like before.

Bug: 852543
Change-Id: I3bd45f955f8ff9dca67b7b9bda940590dce258f1
Reviewed-on: https://chromium-review.googlesource.com/1104417Reviewed-by: Tao Bai <michaelbai@chromium.org>
Reviewed-by: Jun Cai <juncai@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#568068}

Gives the test 5min to finish, and retries up to two more times. I'm
pretty confident this'll cover all current flakes.

Change-Id: I1a706b315f3ee029a6530510facd8b2dfd9de4f5
Reviewed-on: https://chromium-review.googlesource.com/1102121
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Reviewed-by: Marc-Antoine Ruel <maruel@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568067}

We currently have a bug in the Android horizontal tab switcher where if you
close the last tab and then hit "undo," we immediately scroll over so that the
first tab is centered. This is because the StackTab gets an initial scroll
offset of 0 when it's undiscarded, and NonOverlappingStack#getMinScroll()
doesn't account for this case.

This CL fixes the bug by changing NonOverlappingStack#getMinScroll() to ignore
tabs with scroll offsets of 0.

Bug: 852300,831359
Change-Id: Ifface5fbf5025ad3784428663c3b512d390747c6
Reviewed-on: https://chromium-review.googlesource.com/1103452Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568066}

These can cause animations to attempt to update elements which are no longer in
the property tree. It's all duplicate work to what will happen on CC and be
pushed back.

BUG=762717

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I92188f6a61b73274eb9ef1a4608585ae64e56683
Reviewed-on: https://chromium-review.googlesource.com/1091504
Commit-Queue: Peter Mayo <petermayo@chromium.org>
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568065}

https://crrev.com/c/1020942 meant to make sure |DetachedFromWindow| is
invoked upon ViewAndroid destruction. This had a bug when
WindowAndroid is destroyed first, which can happen for Chromecast
where WebContents destruction is delayed by design.

WindowAndroid dtor invokes |GetWindowAndroid| indirectly via its
base dtor (through RemoveAllChildren), but it didn't work as intended
because |GetWindowAndroid| is a virtual function. So it ended up
calling |ViewAndroid::GetWindowAndroid|, not
|WindowAndroid::GetWindowAndroid|.

This CL fixes it by pulling out the task of invoking
|OnDetachedFromWindow| so that the destructor won't use the virtual
function. WindowAndroid can call |OnDetachedFromWindow| in its dtor
since it doesn't need |GetWindowAndroid| - it knows for sure
WindowAndroid (itself) is present.


Bug: b/78251221
Change-Id: I754e45ca3ea61ceb86101ede3b529e75e206689f
Reviewed-on: https://chromium-review.googlesource.com/1102823
Commit-Queue: Jinsuk Kim <jinsukkim@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568064}

Instead just read the blob through the mojom Blob interface directly.
For now still relying on blob UUIDs, but ultimately code calling into
this should already have a BlobPtr rather than having to ever look it
up from a UUID.

Bug: 701851
Change-Id: If267c750368cc4a43d52d239b8462cc65d7214bb
Reviewed-on: https://chromium-review.googlesource.com/1101899Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568063}