GitLab

Bug: 891442
Change-Id: Ib173d99becdfc8924ddf382aeb0687c2bde1a145
Reviewed-on: https://chromium-review.googlesource.com/c/1317899
Commit-Queue: Kevin Strohbehn <ginko@google.com>
Reviewed-by: Weidong Guo <weidongg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605569}

The system salt is no longer needed for authentication.
Also remove unused PendingDoAuthenticateUser declaration.

Bug: 902161
Change-Id: I7920f2975cf4b547149caa2d0c7056085d6dab2a
Reviewed-on: https://chromium-review.googlesource.com/c/1318632
Commit-Queue: Quan Nguyen <qnnguyen@chromium.org>
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605568}

This adds a FidoDiscoveryBase class to instantiate the Windows
authenticator. Instantiatiation of the new Discovery at request time is
conditioned on a newly added feature flag and availability of the
Windows WebAuthn API (which acts as our proxy signal for whether USB
devices are blocked). For requests where the discovery is enabled, the
existing FidoHidDiscovery is disabled.

Bug: 898718
Change-Id: I2048e179bd3987ed3703b3818870253fe2a50e2c
Reviewed-on: https://chromium-review.googlesource.com/c/1313733
Commit-Queue: Martin Kreichgauer <martinkr@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605567}

This CL migrates NetworkMetricsProvider from NetworkChangeNotifier to
NetworkConnectionTracker, which works with the network service enabled.

The "Initial upload" patch of this CL is the same as:
https://chromium-review.googlesource.com/c/chromium/src/+/1222918

Bug: 883121
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs;luci.chromium.try:linux_mojo
Change-Id: Ic6879e48b9515d2281dc9da7c9437bad4c044a99
Reviewed-on: https://chromium-review.googlesource.com/c/1274585Reviewed-by: Olivier Robin <olivierrobin@chromium.org>
Reviewed-by: Tao Bai <michaelbai@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Commit-Queue: Jun Cai <juncai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605566}

Rather than manually iterating over the vector and removing elements,
use the base::EraseIf() helper function.

Bug: 882346
Change-Id: If7c608239ae5081b6e4750dc5a4c33439a18b0a6
Reviewed-on: https://chromium-review.googlesource.com/c/1316978Reviewed-by: Yoshiki Iguchi <yoshiki@chromium.org>
Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605565}

Bug: None
Change-Id: I97e0cccfc77d51bbf738bfab307b8b98d34040be
Reviewed-on: https://chromium-review.googlesource.com/c/1318797Reviewed-by: Xiaoqian Dai <xdai@chromium.org>
Commit-Queue: Min Chen <minch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605564}

https://chromium.googlesource.com/catapult.git/+log/6b1f256782eb..9a5dbc6f4454


git log 6b1f256782eb..9a5dbc6f4454 --date=short --no-merges --format='%ad %ae %s'
2018-11-05 benjhayden@chromium.org Remove new_points from docs/pages-and-endpoints.md
2018-11-05 benjhayden@chromium.org Fix logUrls type-check in add_histograms_queue.


Created with:
  gclient setdep -r src/third_party/catapult@9a5dbc6f4454

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

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

- Rename Mojom traits to indexeddb_mojom_traits.{cc,h}, from
  https://crrev.com/c/1265900/9/third_party/blink/renderer/modules/indexeddb/indexed_db_struct_traits.h.

- Update some non-built-in type return values to const-ref, from
  https://crrev.com/c/1265900/26/third_party/blink/renderer/modules/indexeddb/indexed_db_mojom_traits.h@30.

- Add a mojom_modules build target to allow a future Blink variant
  of the IndexedDB Mojo types to access symbols in the modules layer,
  from https://crrev.com/c/1265900.

Bug: 717812
Change-Id: I40f123cdee5bc7ac3102316d6cf20a191b8252a4
Reviewed-on: https://chromium-review.googlesource.com/c/1318374
Commit-Queue: Chase Phillips <cmp@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605562}

Much of the AutocompleteCoordinator should move into
the mediator, but this moves generating the model outside
of the adapter.

BUG=898522

Change-Id: I1d5bff329c078b616db03873145fb4dd180aa034
Reviewed-on: https://chromium-review.googlesource.com/c/1313736
Commit-Queue: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Pedro Amaral <amaralp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605561}

Bug: 874153
Change-Id: Ib83df9d655ed113084d058e846101b8ddb548b52
Reviewed-on: https://chromium-review.googlesource.com/c/1313283
Commit-Queue: Scott Chen <scottchen@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605560}

This reverts commit 4bf9d01d.

Reason for revert: crbug.com/900373

Original change's description:
> viz: Fix wrong uv_rect calculation
> 
> CL:1045256 calculates |uv_rect| of the primary plane in wrong way. It causes
> drmModeAtomicAddProperty failure. This CL fixes it.
> 
> BUG=896945
> 
> Change-Id: I6e914707cb961e8294e8ddd160b75e48ae5a2b64
> Reviewed-on: https://chromium-review.googlesource.com/c/1291590
> Commit-Queue: Dongseong Hwang <dongseong.hwang@intel.com>
> Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
> Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
> Reviewed-by: Dongseong Hwang <dongseong.hwang@intel.com>
> Cr-Commit-Position: refs/heads/master@{#601392}

TBR=dongseong.hwang@intel.com,dcastagna@chromium.org,hoegsberg@chromium.org

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

Bug: 896945, 900373
Change-Id: Ibab22a4fafb7be1ea0921f0cf774b5973d92b0b2
Reviewed-on: https://chromium-review.googlesource.com/c/1318796Reviewed-by: Wenzhao (Colin) Zang <wzang@chromium.org>
Commit-Queue: Wenzhao (Colin) Zang <wzang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605559}

This makes chromium.fyi/linux-code-coverage run the full set of gtests.

R=stgao,liaoyuke,jbudorick

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

Currently, cc image decode caches support multiple color spaces in the
same decode cache.  However, during rasterization there is only one
color space.  Additionally, each canvas that uses an image decode cache
in Blink also has only one color space (and there is only one canvas
active at once).

This patch is in support of that goal, by refactoring the canvas image
provider to use one image decode cache per color space (split in two
places because of provider dependency issues for gpu).  Once this is
done, then color space can be moved from cc::DrawImage to the image
decode cache.

Although there are now multiple active image decode caches, after
the use of each one they clean up and unlock all decodes via the
CanvasResourceProvider::CleanupLockedImages function.  This is posted
as a task, so it's possible that if there are multiple canvases
being rastered to with multiple color spaces that there may be a
higher watermark of memory usage before the cleanup tasks run.
This patch punts on this possibility for now.

Bug: 902022
Change-Id: I2a079c4ae9383986dffd6939f7ab31a5a45ed196
Reviewed-on: https://chromium-review.googlesource.com/c/1315962
Commit-Queue: enne <enne@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605557}

R=hansberry@chromium.org

Bug: 899324
Test: none
Change-Id: I50f48538f781edde9489e7067bdd3558d7b5525c
Reviewed-on: https://chromium-review.googlesource.com/c/1315955Reviewed-by: Ryan Hansberry <hansberry@chromium.org>
Reviewed-by: Michael Giuffrida <michaelpg@chromium.org>
Commit-Queue: James Hawkins <jhawkins@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605556}

https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/f742ea814813..2f08425d51e7


Created with:
  gclient setdep -r src-internal@2f08425d51e7

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: If6abb1701dd28ce4388ba0f7e1868a4234b78e5f
Reviewed-on: https://chromium-review.googlesource.com/c/1318652Reviewed-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@{#605555}

If a surface is offscreen, then stop sending it OnBeginFrame messages.
This avoids doing unnecessary work in the client. If an OOPIF, video,
etc. are offscreen because the main-page has been scrolled too far (or
not enough, or for some other reason), then they don't need to be
submitting new frames. Not sending the begin-frame messages to the
oopif etc. stops it from continuing to generate and submit new frames.
The side effect of this is that once the oopif becomes visible again,
its first frame can still be old content. This can resolved (e.g. by
throttling the messages, instead of stopping them outright), but I
think it's worth experimenting with this approach first. I think of
this as being a bit similar to how we do not trigger rAF callbacks on
background tabs.

One exception is that a begin-frame is always sent to a surface when
it is first embedded, even if it is offscreen. This allows the clients
to determine correctly when their embedding is complete.

BUG=884876

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
Change-Id: I5c58a0fc956338b470b2fbfe30079d661927c894
Reviewed-on: https://chromium-review.googlesource.com/c/1278535
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605554}

This reverts commit 82ef3377.

Implements this change:
https://github.com/w3c/csswg-drafts/commit/5b5db39d21f3658ae2f4d7992daaf822aca178d8

external/wpt/css/css-flexbox/percentage-heights-003.html ostensibly tests
this, but I don't think the test is correct (and we don't pass it)

To fix the regression from the original change, I updated the devtools code
to specify a flex-basis of auto. It previously defaulted to 0%, which
used to be resolved to auto, but with this change resolves to 0px,
which is not what the code wants.

TESTED=css3/flexbox/definite-main-size.html

Bug: 784059,900459
Change-Id: I773877f34b281dd6bfe4ac02b9aad90451c3acf9
Reviewed-on: https://chromium-review.googlesource.com/c/1247184Reviewed-by: Joel Einbinder <einbinder@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605553}

Attempt to fix crash for which the cause is unknown but could be
because of a broken service pointer.

Bug: 899206
Change-Id: Icf4e644165cd35678f0fbd9d1a9a08838f0e51dd
Reviewed-on: https://chromium-review.googlesource.com/c/1316729
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605552}

This reverts commit 126a1168.

Reason for revert: Broke compile: https://logs.chromium.org/logs/chromium/bb/chromium.chrome/Google_Chrome_Win/39908/+/recipes/steps/compile/0/stdout

Original change's description:
> Make XR FrameData and Environment mojo associated
> 
> The XRFrameDataProvider now returns an associated
> XREnvironmentDataProvider interface so that the
> two share callback queues and thus allow strict
> ordering of the two interfaces. This is critical
> for frame synchronization between frames and the
> associated environment data.
> 
> Note: We can't just mark the interfaceptrs for
> XRFrameDataProvider and
> XREnvironmentIntegrationProvider as associated
> in the XRSession struct. XRDevice implementations
> mostly live on separate threads from the
> XRFrameDataProviders, so we'd have extra thread
> hopping. For the VR headsets we explicitly live
> off the main thread to avoid latency, and because
> we do some work that may block the thread the
> XRFrameDataProvider lives on (for example waiting
> for vsync, or submitting frames to headset APIs).
> 
> Bug: 867057, 876135, 843376
> Change-Id: If2fb62fcd185825209dec08e421df05f34d41c30
> Reviewed-on: https://chromium-review.googlesource.com/c/1171794
> Commit-Queue: Max Rebuschatis <lincolnfrog@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Bill Orr <billorr@chromium.org>
> Reviewed-by: Klaus Weidner <klausw@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#605545}

TBR=dcheng@chromium.org,klausw@chromium.org,billorr@chromium.org,lincolnfrog@chromium.org

Change-Id: I7a2408629460f456bf1189acdb0837f7d22a7919
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 867057, 876135, 843376
Reviewed-on: https://chromium-review.googlesource.com/c/1318805Reviewed-by: Dmitry Titov <dimich@chromium.org>
Commit-Queue: Dmitry Titov <dimich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605551}

BUG=900749

Change-Id: Ib83ba2c50723a89f412d6c5a14cecd93b57cbe5b
Reviewed-on: https://chromium-review.googlesource.com/c/1312133
Commit-Queue: Anand Mistry <amistry@chromium.org>
Reviewed-by: Oliver Chang <ochang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605550}

https://chromium.googlesource.com/chromium/tools/depot_tools.git/+log/7e0b0c498a5c..459aaba03456


git log 7e0b0c498a5c..459aaba03456 --date=short --no-merges --format='%ad %ae %s'
2018-11-05 recipe-roller@chromium.org Roll recipe dependencies (trivial).


Created with:
  gclient setdep -r src/third_party/depot_tools@459aaba03456

The AutoRoll server is located here: https://autoroll.skia.org/r/depot-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=agable@chromium.org

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

Currently, the SlotMetadata records the allocation offset in the
returned page; however, it's only ever used to calculate the final
allocation address. Instead, just store the allocation address.

Bug: 896019
Change-Id: Id14a15e4a7c9afdeb4a517b85a90ddb9f30f7a9f
Reviewed-on: https://chromium-review.googlesource.com/c/1318404
Commit-Queue: Vitaly Buka <vitalybuka@chromium.org>
Reviewed-by: Albert J. Wong <ajwong@chromium.org>
Reviewed-by: Vitaly Buka <vitalybuka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605548}

viz::LocalSurfaceIdAllocation bundles a viz::LocalSurfaceId and an
allocation time for that viz::LocalSurfaceId. The purpose of this allocation
time is to determine how long it takes for a surface to get embedded once
an ID has been allocated for it.

There was some concern raised about drift between LocalSurfaceIds and allocation
times and so a previous CL bundled the two together in a class. This CL plumbs
LocalSurfaceIdAllocation to more places to ensure the two quantities remain
in sync with one another.

Change-Id: I4d0ebf74c0a7825a61c133052a1dbfc5fbd37430
Bug: 655231
Reviewed-on: https://chromium-review.googlesource.com/c/1313408
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605547}

This fixes a DCHECK in browser_about_rewriter.cc because it is triggered
on about:blank?for=chrome://newtab in all egtests with
SlimNavigationManager enabled. Although this is not the root cause, it
is still more correct to skip URL rewriting altogether on placeholder
URLs than reverting the rewrite.

Bug: 902097
Change-Id: I50b0848f0589f24398fb01a8c625b899ab8336f7
Reviewed-on: https://chromium-review.googlesource.com/c/1318790Reviewed-by: Eugene But <eugenebut@chromium.org>
Commit-Queue: Danyao Wang <danyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605546}

The XRFrameDataProvider now returns an associated
XREnvironmentDataProvider interface so that the
two share callback queues and thus allow strict
ordering of the two interfaces. This is critical
for frame synchronization between frames and the
associated environment data.

Note: We can't just mark the interfaceptrs for
XRFrameDataProvider and
XREnvironmentIntegrationProvider as associated
in the XRSession struct. XRDevice implementations
mostly live on separate threads from the
XRFrameDataProviders, so we'd have extra thread
hopping. For the VR headsets we explicitly live
off the main thread to avoid latency, and because
we do some work that may block the thread the
XRFrameDataProvider lives on (for example waiting
for vsync, or submitting frames to headset APIs).

Bug: 867057, 876135, 843376
Change-Id: If2fb62fcd185825209dec08e421df05f34d41c30
Reviewed-on: https://chromium-review.googlesource.com/c/1171794
Commit-Queue: Max Rebuschatis <lincolnfrog@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Bill Orr <billorr@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605545}

I'd like to add comments to the GN args of some bots. This will let us
do that without mb or simplechrome SDK crashing.

Bug: 901471
Change-Id: I7f49434e02591639a02ef9cfd0f026680f6b9de1
Reviewed-on: https://chromium-review.googlesource.com/c/1318188Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605544}

Initialize the cached display device scale factor before usage.
Otherwise, the scale factor is 1 and the window is misplaced/sized.

I'll land a unit test separately, to make merging easier.

Bug: 899084, 665965
Test: KSV (Ctrl-Alt-/) search context menu supports display & UI scales.
Change-Id: Ie74cb70af33110aa09022d4dbb5c6d0069b6cc7c
Reviewed-on: https://chromium-review.googlesource.com/c/1311080
Commit-Queue: Michael Wasserman <msw@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605543}

https://webrtc.googlesource.com/src.git/+log/ee49f7087f93..a9bbd8684936


git log ee49f7087f93..a9bbd8684936 --date=short --no-merges --format='%ad %ae %s'
2018-11-05 mellem@webrtc.org Add a configuration parameter for using the media transport for data channels.
2018-11-05 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision c26ff44a..bf7ad46d (605286:605401)


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

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
TBR=webrtc-chromium-sheriffs-robots@google.com

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

This old behaviour changes the shutdown order for RenderWidget/WebWidget
depending if the browser or renderer initiated the close.

In the browser case, a WidgetMsg_Close IPC arrives which posts a Close()
task. That task then does WillCloseLayerTreeView().

In the renderer case, we post a task to ask for a WidgetMsg_Close, but
in that task we also immediately WillCloseLayerTreeView(). This means
that once the WidgetMsg_Close IPC arrives and is handled, the
WebLayerTreeView has already been removed from blink, changing the
shutdown order.

It also means that in between sending a request for WidgetMsg_Close and
receiving it, other IPCs can arrive, which modify state in blink. All
these code paths can run after WillCloseLayerTreeView() and must check
if we are closing, but only for renderer-initiated close.

Instead we can be more consistent, allow those IPCs to run normally,
and never use those codepaths in blink after close. To do so we remove
WillCloseLayerTreeView() from RenderWidget::DoDeferredClose() and just
do it from RenderWidget::Close().

This also makes RenderWidget::CloseWebWidget() only called once,
instead of calling it twice when closing a child local root widget.

Last we make "are we compositing" a constant state on WebViewImpl,
and check that instead of |layer_tree_view_| to disambiguate and
clearly state that the code path is not run after closing the
connection to the compositor.

R=enne@chromium.org

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

Deregistering the handlers avoids them being called once the packing
operation is done, and an unrelated future pack operation is in
progress. It also frees up a bit of memory.

BUG=791895

Change-Id: I52b8382d18b95637c868c1cdb91fed4b0f6fd276
Reviewed-on: https://chromium-review.googlesource.com/c/1317208Reviewed-by: Luciano Pacheco <lucmult@chromium.org>
Commit-Queue: Anand Mistry <amistry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605540}

Add generator_script and modify BUILD to generate a wrapper script that runs layout tests with build target prefilled

Bug: 897803
Change-Id: I21c00b8924e38304903cf10840fdf5bea1ebb864
Reviewed-on: https://chromium-review.googlesource.com/c/1296990
Commit-Queue: Ned Nguyen <nednguyen@google.com>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605539}

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

https://android.googlesource.com/platform/external/perfetto.git/+log/4c7f72c9764e..c8ac03930c6d


git log 4c7f72c9764e..c8ac03930c6d --date=short --no-merges --format='%ad %ae %s'
2018-11-05 primiano@google.com Merge "UI: Minor fix to prebaked query on cpufreq"


Created with:
  gclient setdep -r src/third_party/perfetto@c8ac03930c6d

The AutoRoll server is located here: https://autoroll.skia.org/r/perfetto-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=perfetto-bugs@google.com

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

The test fails when non-English locale is used, or even when there is a
secondary language set in the language preferences.

Nougat introduced local lists, so checking the default locale isn't
enough to ensure that there isn't any secondary locale, and setting
the default locale does not remove the secondary locale.

This CL provides a separate code path for multiple locale check in N+.

Bug: 901230
Change-Id: I181378e79888a36d47db7c1c3ca360573fdec235
Reviewed-on: https://chromium-review.googlesource.com/c/1318670Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Commit-Queue: Changwan Ryu <changwan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605536}

TBR=inferno@chromium.org,metzman@chromium.org

Bug: 539572
Change-Id: Ia8904c035a4a5342bed95763be2fb3d64e168c0f
Reviewed-on: https://chromium-review.googlesource.com/c/1318653
Commit-Queue: Max Moroz <mmoroz@chromium.org>
Reviewed-by: Jonathan Metzman <metzman@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605535}

This CL re-enables
virtual/threaded/fast/scroll-behavior/wheel-and-touch-scroll-use-count.html
on Linux since it doesn't seem to be flaking anymore.

Bug: 766357
Change-Id: I58be5caa2263282d167e12a6543520ee05ca9ebe
Reviewed-on: https://chromium-review.googlesource.com/c/1313575
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Dmitry Titov <dimich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605534}

BUG=900749

Change-Id: Ia2429113cc5b2bef49e25643fa2176e883029e2b
Reviewed-on: https://chromium-review.googlesource.com/c/1311854
Commit-Queue: Anand Mistry <amistry@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605533}

Bug: 888755
Change-Id: I428409372cf99d527db0da7771198cdd14cacea7
Reviewed-on: https://chromium-review.googlesource.com/c/1318181Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605532}

Some tab-dragging test cases never finishes on SingleProcessMash,
and it turns out that WindowEventDispatcher thinks some
TOUCH_RELEASED events can be invalid; it won't generate any
gestures and does not do anything. In that case, OnEvent()
won't be called and any other methods are not called, therefore
InjectedEventHandler couldn't notify it's done.

This CL adds a new method to WindowEventDispatcherObserver to
catch such cases and allow handling it's done.

BUG=890071
TEST=see the filter update

Change-Id: I6dcda9af52e5cbd4013b8d228bda2e9b1f14bdd6
Reviewed-on: https://chromium-review.googlesource.com/c/1316767
Commit-Queue: Jun Mukai <mukai@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605531}

Bug: 817981
Change-Id: I13fe128e6771600f135e0a8e9cde00c456305c81
Reviewed-on: https://chromium-review.googlesource.com/c/1317301Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Commit-Queue: Makoto Shimazu <shimazu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605530}