GitLab

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}

Bug: 901488
Change-Id: I7c98a48ab86533ee206ef7302e085e39be76cd7c
Reviewed-on: https://chromium-review.googlesource.com/c/1318669
Commit-Queue: Filip Gorski <fgorski@chromium.org>
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605529}

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

On Android, Navigation.LoadIfNecessaryType.kRequestedByClient counts
number of tab restore loads after switches back to a tab with a dead
renderer process.

Bug: 841572

Change-Id: I753bedf1f0acfbe5bafe286b7cabfa2cf5c31fcf
Reviewed-on: https://chromium-review.googlesource.com/c/1316361
Commit-Queue: Bo <boliu@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605527}

Add docs on reproducing libFuzzer crashes on Windows.
Make it clearer that reproduce tool is not for Windows.
Fix a command to work on cmd.exe

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

Changes to SadTabView:
 - messageTextView and actionButton are now public
   for testing (http://go/unit-test-practices#public-apis)
 - _messageTextView and _actionButton ivars are not
   synthesized anymore, because properties belong to a
   category

SadTabViewController will be owned by SadTabCoordinator
which will be landed in a follow up CL. Using view controller
for UI presentation will allow to avoid using Transient View
for Sad Tab and will follow New Architecture patterns.

Bug: 901563
Change-Id: If84d89e9bc3d991e743f3420406881292b345579
Reviewed-on: https://chromium-review.googlesource.com/c/1312684
Commit-Queue: Eugene But <eugenebut@chromium.org>
Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605525}

When assistant controllers init and receives an assistant status of
NOT_READY, it tries to hide non-exist Assistant, which will eventually
cause a segfault.

Bug: 901720
Test: locally build and test
Change-Id: I4bf7247c175906167436849b4514c450c763c79f
Reviewed-on: https://chromium-review.googlesource.com/c/1318680Reviewed-by: Tao Wu <wutao@chromium.org>
Commit-Queue: Xiaohui Chen <xiaohuic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605524}

Root cause https://bugs.chromium.org/p/chromium/issues/detail?id=898842
has been fixed for flaky tests
gpu_tests.depth_capture_integration_test.DepthCaptureIntegrationTest.DepthCapture_depthStreamToRGBAFloatTexture
and
gpu_tests.depth_capture_integration_test.DepthCaptureIntegrationTest.DepthCapture_depthStreamToRGBAUint8Texture.
Remove their flaky suppressions on Android and Win.

TBR=kbr@chromium.org

Bug: 899748
Change-Id: Ida2212bc191a1c5e060cb19b5d6d52d04b377bd2
Reviewed-on: https://chromium-review.googlesource.com/c/1318673Reviewed-by: Ria Jiang <riajiang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Ria Jiang <riajiang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605523}

R=mmoroz@chromium.org
TBR=erikchen@chromium.org

Bug: 900812
Change-Id: I1e7cac38d9d705179aeff95d438a6932febe8cd4
Reviewed-on: https://chromium-review.googlesource.com/c/1317868Reviewed-by: Abhishek Arya <inferno@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Commit-Queue: Abhishek Arya <inferno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605522}

Code in chrome/browser/browsing_data queries storage back-ends for
origins and the size on disk and last modified time of each origin's
data. This is done for each storage backend by unique plumbing between
a BrowsingDataXXXHelper and the corresponding XXXContext via the
BrowsingContext's StoragePartition. The same data (list of
origin/size/time tuples) is reported for each storage backend.

Replace structs specific to each type (e.g. XXXUsageInfo) with a
generic StorageUsageInfo struct. This removes several nearly identical
classes from content/public/browser (for Indexed DB, Cache Storage
API, Local Storage, Service Worker). Follow ons can remove similar
classes (e.g. PendingXXXUsageInfo) and do other code deduplication.

One functional change: The list of scopes registered for Service
Workers is no longer displayed in the "cookies tree"
(chrome://settings/siteData); this is not useful for end users and
developers should use devtools instead.

Change-Id: Ibd759c3e303188580aea8bfcaa450b44183bc100
Reviewed-on: https://chromium-review.googlesource.com/c/1308074
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605521}

This reverts commit 93ee1837.

Reason for revert:

Findit (https://goo.gl/kROfz5) identified CL at revision 605481 as the
culprit for failures in the build cycles as shown on:
https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtLzkzZWUxODM3MDA2NDAwYTRmZGU3ODk3ODdkNzBhN2YwOTkwNWNjZTgM

Sample Failed Build: https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-dbg/8731

Sample Failed Step: compile

Original change's description:
> [Media Session] [1/4] Move MediaMetadata to service
> 
> This CL moves the MediaMetadata and MediaImage mojo types
> from Blink to the Media Session service along with their
> mapped types in content.
> 
> This is the first of four parts.
> 
> BUG=875004
> 
> Change-Id: Ie862229bbeb474a60ccc4d2f82d8c4e1f8017b74
> Reviewed-on: https://chromium-review.googlesource.com/c/1227401
> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Ken Rockot <rockot@google.com>
> Commit-Queue: Becca Hughes <beccahughes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#605481}

No-Presubmit: true
No-Tree-Checks: true
No-Try: true
BUG=875004

Change-Id: Ica72191d2b5700c793fbdcf61ce680faa938f0d5
Reviewed-on: https://chromium-review.googlesource.com/c/1318747
Cr-Commit-Position: refs/heads/master@{#605520}

On built-in resolver failures, we sometimes fallback and try again with
the system resolver. This is not desirable when the source is explicitly
set to DNS as we should then only resolve using the built-in resolver.

Also changed the "disabling" of DnsClient after errors that succeed on
fallback. Should only opportunistically affect requests that can
fallback.  When we cannot fallback (e.g. due to being a DNS request),
DnsClient will still be used.

Also changed the behavior of requesting DNS with the DnsClient disabled.
Subsequent requests match that behavior and return an error instead of
DCHECKing.

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