GitLab

This is a fixup after commits related to crbug.com/887148

Tbr: haraken@chromium.org
No-try: true
Bug: chromium:843903
Change-Id: I58530721a40968bd31db08ce5adda9a7b87a9157
Reviewed-on: https://chromium-review.googlesource.com/c/1317898Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605477}

When the URL bar is being actively scrolled out of view, the browser is
exposing a new region of the page at the bottom of the screen. Since the
render/Blink hasn't been resized yet, PictureLayerImpl has some code to
rasterize this new region despite the fact it falls outside the layer's
bounds.

As part of https://crrev.com/77b67445ba6e415e8b41b5b6fd5c016c7195206d, I
changed this code to raster the exact amount the URL bar is hidden.
However, this caused a perf regression as we would now raster the region
in pieces as the URL bar scrolled away, rather than in one go.

So in https://crrev.com/b2d410710e7ea7c5a33798ff6b5d5191b1951b5e I undid
that change and rastered the entire region as before. However, I kept
some the other changes made in the first CL. One of those changes was to
do this only when browser_controls_shrink_blink_size is true (meaning the
renderer has received a resize as a result of the URL bar being shown)
but no longer look if we're in an active scroll. Not looking at whether
we're actively scrolling regresses the metric in the linked bug.

It's more correct to look at both these bits. We should only expand the
raster region when we're going from controls shown to hidden (so look at
browser_controls_shrink_blink_size) but we should also only do this when
we're in a scroll. i.e. If the user isn't hiding the URL bar, there's no
need to raster additional content.

Bug: 900928
Change-Id: I373ebe8879b832616780996f9afdd16092538fdd
Reviewed-on: https://chromium-review.googlesource.com/c/1315699Reviewed-by: enne <enne@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605476}

Major changes:
- The scheduler owns the job controllers. It is also the data manager
/ service worker observer now instead of BackgroundFetchContext.
- The job controller itself is in charge of processing a fetch. This
simplifies the `abort` workflow thanks to weak_ptrs. The scheduler can
still be extended to process multiple requests though.
- The scheduler cleanup process for a job controller handles the
registration cleanup and event dispatching.
- The UpdateUI DB tasks and checks and associated checks were removed
since the UI can only be updated once when the registration
fails/succeeds.
- Scheduler::Controller was removed since it doesn't make sense to have
anymore now that the scheduler directly owns the controllers (also
RequestProvider because it added no value).
- There were some other minor readability cleanups along the way.

Bug: 850512
Change-Id: Icff68da7ccc20d8112d283843dd2ad6c6d1a9a26
Reviewed-on: https://chromium-review.googlesource.com/c/1297412Reviewed-by: Jesse Doherty <jwd@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Commit-Queue: Rayan Kanso <rayankans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605475}

If an adb command fails during profiling, dump logcat through
logging.error. This will aid with debugging.

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

This is a further attempt to determine why two subsequent calls to this
method with the same parameters sometimes produce different outputs.

Bug: 836238
Change-Id: I3960fe0bd27976ae4678a4f96bad61870c22342c
Reviewed-on: https://chromium-review.googlesource.com/c/1314648Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Brian White <bcwhite@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605473}

In some cases I could not find the old keys, so I have created and
checked in new keys. This resulted in ID rotation.

These test CRXs are not signed with publisher proofs - some of them will
likely need to have a publisher proof added in the future.

Bug: 740715
Change-Id: I8534c8bcdc387d9c04e92300480e845819e129f4
Reviewed-on: https://chromium-review.googlesource.com/c/1313551Reviewed-by: David Trainor <dtrainor@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Commit-Queue: Joshua Pawlicki <waffles@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605472}

This is a reland of 1c6f831f

This CL made a number of flaky tests more visibly flaky. We've fixed or
disabled tests as a result of that. (See crbug.com/899073)

TBR=dcheng@chromium.org, piman@chromium.org

Original change's description:
> Don't SetVisible on swapped out RenderWidgets, and drop gpu resources.
>
> When a RenderWidget is created for a RenderViewImpl, it may be
> considered "swapped out". This means the main frame for this
> RenderView's frame tree is not local, the RenderView exists to
> hold some other local subframe, which will be composited and have
> a RenderWidget. Thus the RenderWidget attached to the RenderViewImpl
> is not actually used, there is no output from the remote main frame
> in this tree. I like to refer to these swapped out RenderWidgets as
> zombies.
>
> During navigations, a RenderViewImpl's main frame may change to or
> from being local, in which case the RenderWidget attached to it changes
> to or from being a zombie.
>
> When becoming a zombie, the WebFrameWidget attached to the
> RenderViewImpl (wrapping the WebViewImpl) is destroyed, and this
> marks the compositor as SetVisible(false) on the RenderWidget
> (via the WebViewImpl).
>
> When becoming alive again, a new WebFrameWidget is attached to the
> RenderViewImpl, and the WebFrameWidget marks the compositor as
> SetVisible(true) on the RenderWidget (via the WebViewImpl).
>
> While a zombie, the WebViewImpl is also told not to allow any
> visibility changes to be passed along to the RenderWidget. This is
> because as the local subframe becomes visible with the Page, we'd
> tell the WebView about this, to tell the Page. But since the
> WebView now has a zombie RenderWidget, it shouldn't also tell that.
>
> Note when the RenderViewImpl is created and initially swapped out
> it creates a RenderWidget but nothing tells its compositor about the
> zombie state of affairs, so it becomes visible, which makes it
> acquire a Gpu channel and start its scheduler etc. Woops.
>
> This CL rearranges things a bit.
> - A new RenderWidget does not SetVisible(true) if swapped out.
> - RenderViewImpl directly marks it SetVisible(false) when removing the
> WebFrameWidget.
> - RenderViewImpl *also* removes the LayerTreeFrameSink to drop the
> Gpu channel since we don't need to be fast at becoming visible (the
> RenderWidget is a zombie!)
> - RenderViewImpl directly marks it as SetVisible(true) when getting
> a new WebFrameWidget as the RenderWidget stops being a zombie.
> - WebViewImpl stops calling SetVisible on the RenderWidget when its
> main frame is not visible. In the future the RenderWidget should be
> a member of the main LocalFrame, and thus won't even exist when the
> main frame is not local.
>
> R=dcheng@chromium.org, piman@chromium.org
>
> Change-Id: I87a5d0dfeaaf08cb91c9348b26b4205db55b3a81
> Bug: 894899, 419087
> Reviewed-on: https://chromium-review.googlesource.com/c/1290140
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Antoine Labour <piman@chromium.org>
> Commit-Queue: danakj <danakj@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#602389}

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

This patch stops changing the cc::Layer hierarchy when the
GraphicsLayer hierarchy changes. Instead, we rely on cc::Layers being
updated in PaintArtifactCompositor (PAC).

Bug: 898668
Change-Id: Ib1abb05bc1d8dc7d12ec5f88c8518cf75d077f74
Reviewed-on: https://chromium-review.googlesource.com/c/1313415Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605470}

See https://skia-review.googlesource.com/c/skia/+/168270

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

Bug: 901906
TBR: masonfreed@chromium.org
Change-Id: I51d36872d27bb52db2a56d02edf888a139091ab6
Reviewed-on: https://chromium-review.googlesource.com/c/1318387
Commit-Queue: Dmitry Titov <dimich@chromium.org>
Reviewed-by: Dmitry Titov <dimich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605468}

This reverts commit 4c9f4636.

Reason for revert: Broke build: https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/linux-chromeos-dbg/8728

Original change's description:
> Disable Demo app launch when device is in Dev mode
> 
> Wrote unit test for DemoModeDetector,  accounting for existing behavior,
> and also the new behavior introduced in this CL.
> 
> R=​michaelpg@chromium.org
> TEST=tested manually on dev chromebook, and with demo_mode_detector_unittest.cc
> 
> Bug: 877655
> Change-Id: Ibfd78ec1cf2d87c3acad71a8244e519f70601cec
> Reviewed-on: https://chromium-review.googlesource.com/c/1298417
> Commit-Queue: Danan S <danan@chromium.org>
> Reviewed-by: Dan Erat <derat@chromium.org>
> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
> Reviewed-by: Michael Giuffrida <michaelpg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#605408}

TBR=derat@chromium.org,sadrul@chromium.org,michaelpg@chromium.org,danan@chromium.org

Change-Id: Ia8275a42d27411ce72075b2de83d37dd01ea4924
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 877655
Reviewed-on: https://chromium-review.googlesource.com/c/1318546Reviewed-by: Dmitry Titov <dimich@chromium.org>
Commit-Queue: Dmitry Titov <dimich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605467}

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/fcb0f91c..2b4710f3

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: I43879c168b1976bbf540c7f6f8bd3db1363f8267
Reviewed-on: https://chromium-review.googlesource.com/c/1318388Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#605466}

Tried to fix this in https://chromium-review.googlesource.com/c/1309777
but incorrectly assumed that bogus continuation chains were formed by
direct siblings. But they may also be arbitrary-level cousins. Need to
walk through all non-atomic inlines between one continuation object and
the next in the chain, to figure out whether there is an anonymous block
between two objects in the continuation chain. Only then should we
update the positionedness of anonymous blocks. Only perform this check
if positionedness changed, since it's not for free.

Bug: 901598
Change-Id: I3e49a4ce8081a4a3190cc1569480189cbcccdcc4
Reviewed-on: https://chromium-review.googlesource.com/c/1317627Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605465}

R=creis@chromium.org, nasko@chromium.org

Change-Id: I8dbff259878a72e89efe802a1a4d83b78b394dd9
Bug: 671891
Reviewed-on: https://chromium-review.googlesource.com/c/1318408Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605464}

R=kenrb@chromium.org

Change-Id: I24fcca54fe990bbacc19d892d868b3501739a8f5
Bug: 889002
Reviewed-on: https://chromium-review.googlesource.com/c/1318430Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605463}

https://chromium.googlesource.com/catapult.git/+log/8c035b35abf8..03ce64d28832


git log 8c035b35abf8..03ce64d28832 --date=short --no-merges --format='%ad %ae %s'
2018-11-05 chiniforooshan@chromium.org Telemetry: tasks_per_frame in TBMv2


Created with:
  gclient setdep -r src/third_party/catapult@03ce64d28832

The AutoRoll server is located here: https://autoroll.skia.org/r/catapult-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

BUG=chromium:760553
TBR=sullivan@chromium.org

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

There is currently a CHECK that no more than 1000 BLOCK_SHUTDOWN tasks
are posted during shutdown. The goal of this CHECK is to prevent
shutdown hangs caused by components that behave badly (e.g. a component
that reposts a BLOCK_SHUTDOWN task at the end of each BLOCK_SHUTDOWN
task).

This CL removes this CHECK because:
- It is redundant with the hang watcher.
- Unlike the failures reported by the hang watcher, the failures
  reported by this CHECK aren't necessarily associated with user pain
  (e.g. posting more than 1000 very short BLOCK_SHUTDOWN tasks during
  shutdown will probably not be noticed by the user if it doesn't
  trigger the hang watcher).

Bug: 897334
Change-Id: I6c0ce508c5bd892724a92add3025afe9019a35e7
Reviewed-on: https://chromium-review.googlesource.com/c/1318173Reviewed-by: Gabriel Charette <gab@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605461}

R=piman@chromium.org

Change-Id: Ie3ad9d57c1b078551a0a7e83dc84a3e95958072c
Bug: 898641
Reviewed-on: https://chromium-review.googlesource.com/c/1318385Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605460}

This is a companion cl for:
https://chromium-review.googlesource.com/c/chromium/tools/build/+/1313151

R=liaoyuke,stgao,jbudorick

Change-Id: Ic0d4d3dc9ac92c30b9a8c5c0b018edf604fde750
Reviewed-on: https://chromium-review.googlesource.com/c/1313758Reviewed-by: Shuotao Gao <stgao@chromium.org>
Reviewed-by: Yuke Liao <liaoyuke@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Roberto Carrillo <robertocn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605459}

The reflection was failing because proguard changes the package of the
ArDelegate.

Bug: 900897
Change-Id: I303c8f97f9eaa89f64edce8cab6e912a2bbefe4a
Reviewed-on: https://chromium-review.googlesource.com/c/1318437Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Commit-Queue: Tibor Goldschwendt <tiborg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605458}

Change-Id: I94ade605404051bf0d735b936923c2084bb805bc
Reviewed-on: https://chromium-review.googlesource.com/c/1316436
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605457}

This CL implements the plumbing of page-scale factor to OOPIFs by
including it in the VisualProperties sync pathway. The main frame's
page scale factor is represented in cc/ by |external_page_scale_factor|
and only affects the calculation of raster scale.

The vast majority of this CL is plumbing, with the main logic
change occuring in picture_layer_impl.cc.

Bug: 654917, 698766
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia3f65e45be32c5a6033f3afaccb965dde597eee9
Reviewed-on: https://chromium-review.googlesource.com/c/1286437
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605456}

Bug: 883496
Change-Id: I4981cf288566aed5f95e3ca3b8632e5462203ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1311262
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605455}

https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/d256e043692f..ff3c10197ad5


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

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: Id2ecfbf349b349e73fd86c57dd940a7a82b5cf50
Reviewed-on: https://chromium-review.googlesource.com/c/1318152Reviewed-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@{#605454}

This histogram will track how often the migration before handshake ends
up with success, and how often is not.

Bug: 790547
Change-Id: I8cb9c3dbcbb7262955c69284f1a12d2e11be61eb
Reviewed-on: https://chromium-review.googlesource.com/c/1315933
Commit-Queue: Zhongyi Shi <zhongyi@chromium.org>
Reviewed-by: Ryan Hamilton <rch@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605453}

Automates the manual tests from https://crbug.com/887551, which relate
to the Daydream controller while in a WebXR immersive session and
permissions, e.g. ensuring that in-use permissions are displayed when
long-pressing the app button.

As a side-effect, updates the test code for waiting on a VR UI element
to change visibility to instead wait for a specific visibility state.

Bug: 887551
Change-Id: I0f845231d2242c711a7b8d6f1465105ec8dc6383
Reviewed-on: https://chromium-review.googlesource.com/c/1318063Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605452}

This reverts commit 65f0e20a.

Reason for reland: Fixes crbug.com/900909 and crbug.com/900993

TBR=torne@chromium.org (No changes in webview section)

Original change's description:
> [Android] Remove most resource names in resources.arsc
>
> resource names are stored in the resources.arsc file to allow for
> getIdentifier with the string name of the resource to work. This cl
> obfuscates all of those resources to one name (and thus stored only
> once) for all resources that are not accessed via getIdentifier.
>
> This improves binary size by about 200KB.
>
> Bug: 894208
>
> Change-Id: I28c440c22b90cd045f53017073fdb88c7410d530
> Reviewed-on: https://chromium-review.googlesource.com/c/1265897
> Commit-Queue: Mohamed Heikal <mheikal@chromium.org>
> Reviewed-by: Richard Coles <torne@chromium.org>
> Reviewed-by: agrieve <agrieve@chromium.org>
> Reviewed-by: Ted Choc <tedchoc@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#603229}
Bug: 894208, 900909, 900993

Change-Id: Ie1e8790b392b5cbfff6d207c11e12bed6b8cc765
Reviewed-on: https://chromium-review.googlesource.com/c/1316092Reviewed-by: Mohamed Heikal <mheikal@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Commit-Queue: Mohamed Heikal <mheikal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605451}

Update a few things to make code easier to understand while looking at
another bug related to the class.
1. Reset scoped_refpts via reset() instead of assigning nullptr.
2. Use BindOnce() where possible.

Bug: 874797
Change-Id: I3910aa17e22e880690b49a98285c49d7a483c3af
Reviewed-on: https://chromium-review.googlesource.com/c/1291776Reviewed-by: Jonathan Backer <backer@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605450}

Also the QueuedLoadAPILoadOtherExtension variant of the test.

TBR=fsamuel@chromium.org

Change-Id: I466de3d2236ed71d85136674b6ca2c48569be548
Bug: 810225
Reviewed-on: https://chromium-review.googlesource.com/c/1318436Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605449}

We used to support sync registrations having various types of network
conditions under which they would fire. That's not specced and it's
unused, so removing it.

Bug: 901034
Change-Id: I38fb1cf2779aebe8814f7bb1bf5564f467397149
Reviewed-on: https://chromium-review.googlesource.com/c/1313191
Commit-Queue: Josh Karlin <jkarlin@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605448}

https://chromium.googlesource.com/angle/angle.git/+log/37297a4f1440..3d86e89bce7a


git log 37297a4f1440..3d86e89bce7a --date=short --no-merges --format='%ad %ae %s'
2018-11-05 syoussefi@chromium.org Vulkan: properly handle 0-width or 0-height framebuffers


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

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

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

Explicit registration is needed only when using the custom linker.
Cast shell doesn't use the custom linker, so has no need to jump
through the extra hoops involved with explicit registration.

Change motivated by JNI refactorings, which are made simpler by having
fewer targets use manual JNI registration.

Bug: 898261
Change-Id: I88e92480d355fc0a19ffdd4c816efbf749dd9964
Reviewed-on: https://chromium-review.googlesource.com/c/1317340Reviewed-by: Luke Halliwell <halliwell@chromium.org>
Commit-Queue: agrieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605446}

clang-cl supports #pragma hdrstop as of r341963.

Bug: 505314,504657,750327,826743
Change-Id: Ic90b07114bbb886b7d8345a260863f45eef352b7
Reviewed-on: https://chromium-review.googlesource.com/c/1317607
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Varun Khaneja <vakh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605445}

This change splits the print statement in the imports vs deps check
function into three separate ones, as well as prints the correct filename
instead of the first one in the list.

Change-Id: I81010efa46eeab37847d90df5574cdf34ff4b83f
Reviewed-on: https://chromium-review.googlesource.com/c/1316727
Commit-Queue: Oksana Zhuravlova <oksamyt@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#605444}

This CL renames core => common, updates build deps to be a less
tangled, renames a few classes, and updates imports.

Change-Id: I011f9ec6d704681b50da5be759341e7e3b48d076
Bug: 897463
Reviewed-on: https://chromium-review.googlesource.com/c/1289688
Commit-Queue: Frank Liberato <liberato@chromium.org>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#605443}

Sends LayerTreeFrameSink the hit-test debug state from
LayerTreeDebugState.

R=riajiang@chromium.org

Change-Id: Ie180735f7f61863ac4546516b9991ee529fa99bb
Reviewed-on: https://chromium-review.googlesource.com/c/1314613
Commit-Queue: Alexander Shah <zandershah@google.com>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Min Qin <qinmin@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605442}

Allows network service clients to listen for when changes are detected
to the system DNS configuration. Will be useful for the DnsProbeService
usecase where the probe service needs to use config change as a signal
to clear cached probe results.

Only signals that changes have happenned, not what the changes were, and
there is no current plan for the network service to support retrieving
DNS config or details on changes. Recent work on DnsConfigOverrides has
negated all known service-external usecases for such capabilities.

Bug: 846423
Change-Id: Iee980205a2d3d0ddc80b39fb2a0a043a593db0a4
Reviewed-on: https://chromium-review.googlesource.com/c/1309334Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Eric Orth <ericorth@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605441}

The histogram name in the xml file was different than the one used.

Change-Id: Ibace41bb7d44a22b6cf81850689035f2bcf03f89
Reviewed-on: https://chromium-review.googlesource.com/c/1317631Reviewed-by: Ilya Sherman <isherman@chromium.org>
Commit-Queue: Ilya Sherman <isherman@chromium.org>
Commit-Queue: Rayan Kanso <rayankans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605440}

Read extension policy settings from the `policy_path` as a fallback
in the case where the data directory does not have any extension policy
information.

This allows setting extension policies through client-side autotests.

Bug: 900238
Change-Id: I49204ae22df6633e65ec30bbba9b0e2e40216580
Reviewed-on: https://chromium-review.googlesource.com/c/1307450Reviewed-by: Denis Kuznetsov <antrim@chromium.org>
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Commit-Queue: Max Timkovich <timkovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605439}

The bug manifested itself if you had the downloads page visible
and was the first time you focused the omnibox.  The problem
was caused by two views using the ID toolbar in their XML.

Then findViewById on the root was unpredictable and would return
the first it finds, and when downloads is showing it would be
the downloads toolbar.

This just makes the downloads toolbar use a unique ID.

BUG=901736

Change-Id: I4b67fb828909f1ac443569faa691b953c94e73a1
Reviewed-on: https://chromium-review.googlesource.com/c/1318370Reviewed-by: Shakti Sahu <shaktisahu@chromium.org>
Commit-Queue: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605438}