GitLab

This reverts commit b828d53c.

Reason for revert: Causing a build failure on Google Chrome Linux x64
https://ci.chromium.org/buildbot/chromium.chrome/Google%20Chrome%20Linux%20x64/29741

/b/c/b/Google_Chrome_Linux_x64/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: duplicate symbol: exp2f@GLIBC_2.2.5
>>> defined in obj/third_party/swiftshader/src/OpenGL/compiler/swiftshader_opengl_compiler/Intermediate.o
>>> defined in obj/third_party/swiftshader/src/Renderer/swiftshader_renderer/Context.o
/b/c/b/Google_Chrome_Linux_x64/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: duplicate symbol: exp2f@GLIBC_2.2.5
>>> defined in obj/third_party/swiftshader/src/OpenGL/compiler/swiftshader_opengl_compiler/Intermediate.o
>>> defined in obj/third_party/swiftshader/src/Renderer/swiftshader_renderer/Sampler.o
/b/c/b/Google_Chrome_Linux_x64/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: duplicate symbol: powf@GLIBC_2.2.5
>>> defined in obj/third_party/swiftshader/src/Renderer/swiftshader_renderer/Surface.o
>>> defined in obj/third_party/swiftshader/src/Shader/swiftshader_shader/Constants.o
/b/c/b/Google_Chrome_Linux_x64/src/out/Release/../../third_party/llvm-build/Release+Asserts/bin/ld.lld: error: duplicate symbol: powf@GLIBC_2.2.5
>>> defined in obj/third_party/swiftshader/src/Renderer/swiftshader_renderer/Surface.o
>>> defined in obj/third_party/swiftshader/src/Common/swiftshader_common/Math.o

Original change's description:
> Add more unbundle packages to sysroots
> 
> The new packages are necessary to test unbundling of flac, libxslt, and zlib.
> 
> BUG=800977
> R=​thestig
> TBR=mark
> 
> Change-Id: I2c5f88b3819ce000e906cf303fdffa30bdde84cb
> Reviewed-on: https://chromium-review.googlesource.com/981451
> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#549303}

TBR=thakis@chromium.org,thestig@chromium.org,thomasanderson@chromium.org,mark@chromium.org

Change-Id: I90188d22140d7cdd60f8bbea5b0e88705e498988
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 800977
Reviewed-on: https://chromium-review.googlesource.com/1003532Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549314}

* Updates the ContextualSuggestionsBridge to provide the policy check.

Bug: 829458
Change-Id: I941ce0b5bf0776ced410813d238bc9d6712be6fa
Reviewed-on: https://chromium-review.googlesource.com/1000142Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Filip Gorski <fgorski@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549313}

Guard the callback ServiceWorkerClientCompat.shouldInterceptRequest with
a feature flag to ensure that if we ever remove/replace that callback
from the support library in the future, existing WebView APKs won't call
into it.

Bug: 819595
Change-Id: Id9796f695cc9fd66caf5739efeb77dd02e215821
Reviewed-on: https://chromium-review.googlesource.com/998164Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Gustav Sennton <gsennton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549312}

This fixes a "net::ERR_FAILED" (-2) error. That error was being
silently ignored because Device::SetUp was not returning the status
of ForwardDevtoolsPort. Since the bug is fixed, we can re-enable
returning the status.

This change is setup for a future change to send port 0 to adb server
to avoid a race condition.

Change-Id: Ic0aece82cd0ff0a413f32bd5587d12998be64a21
Reviewed-on: https://chromium-review.googlesource.com/1000846
Commit-Queue: Caleb Rouleau <crouleau@chromium.org>
Reviewed-by: John Chen <johnchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549311}

Removes line in VideoFrameResourceProvider indicating that it is a
placeholder class. This is now incorrect, as it has been filled in.

Bug: 746182
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Id7be5af35c6ded2aca95e9721c33c961b171efc7
Reviewed-on: https://chromium-review.googlesource.com/1000524
Commit-Queue: CJ DiMeglio <lethalantidote@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549310}

BUG=

Change-Id: I458e270f5740451e4898040077474d318c0cddc2
Reviewed-on: https://chromium-review.googlesource.com/1003280Reviewed-by: Filip Gorski <fgorski@chromium.org>
Commit-Queue: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549309}

Also ensure throttling state is conditioned on keep_active.
Clean up a TODO in FS.

Bug: 820634
Change-Id: I553fd6331593d3a3ee4fd408373926eaedfb749d
Reviewed-on: https://chromium-review.googlesource.com/996914
Commit-Queue: Shubhie Panicker <panicker@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549308}

Gaia id is provided together with username in PolicyData
for user policy.
It should be used instead of username for validation of
these policies to be resilient to user rename.
For other policies old username check is still used.

BUG=780792
TEST=New unit tests covering gaia id check + browser tests
are updated to use the new check though PolicyBuilder update.

Change-Id: I81ef8953a4a079341b70ab75aeb2d157c65067e5
Reviewed-on: https://chromium-review.googlesource.com/980873
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Reviewed-by: Gayane Petrosyan <gayane@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Drew Wilson <atwilson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549307}

Bug: 734095
Change-Id: I0bac9ecbaedad6d39a16b04442a361b22d45fcfd
Reviewed-on: https://chromium-review.googlesource.com/1002542Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Xi Cheng <chengx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549306}

When using a virtual keyboard, focusing an editable element scrolls it
into view and potentially zooms in to make it legible. This is done via
the WebFrameWidget method ScrollFocusedEditableElementIntoView. This
eventually ends up in WebViewImpl::ZoomAndScrollToFocusedEditableRect.
This method then creates an animated "PageScaleAnimation" that scrolls
and zooms the layout and visual viewports smoothly into the editable
Element.

However, it currently only scrolls the viewports. When a keyboard is
shown it may resize the page causing the layout to change. In some cases
the focused Element may end up obscured/clipped by non-viewport ancestor
elements. Thus, it may not be possible to show the element simply by
scrolling the viewport; in fact, the viewport may not even be
scrollable.

This patch fixes the issue by calling LayoutObject::ScrollRectToVisible
on the focused element before the PageScaleAnimation tries to show it
in the viewport. Because the PageScaleAnimation will smoothly scroll the
viewport, this CL adds a param to the ScrollRectToVisible methods to
make them stop once we reach the main frame's viewport. This just
ensures the element is unobstructed by page content. We do this both for
local and remote frames as the calls take a slightly separate path.

We also modify the ScrollRectToVisible methods to return the transformed
rect (after scrolling is applied) so that we can use the modified rect
in PageScaleAnimation.

Bug: 270018
Change-Id: Iedd0397e9e3ca481a9f87724e870645c92dae654
Reviewed-on: https://chromium-review.googlesource.com/982506
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Sandra Sun <sunyunjia@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549305}

This is used as a workaround to get profiling using Valgrind working.

BUG=830706

Change-Id: Ie502f78681b686ea595c06255b7be712e32c8322
Reviewed-on: https://chromium-review.googlesource.com/1002921
Commit-Queue: Ryan Harrison <rharrison@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549304}

The new packages are necessary to test unbundling of flac, libxslt, and zlib.

BUG=800977
R=thestig
TBR=mark

Change-Id: I2c5f88b3819ce000e906cf303fdffa30bdde84cb
Reviewed-on: https://chromium-review.googlesource.com/981451
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549303}

Currently, the current_offset and target_offset returned from layer_tree_host_impl are in the
coordinate of the page, but the parameters passed in ScrollBy() are in the coordinate of the
device. This inconsistency would cause the scroller to never reach the desired scroll offset if the
page is scaled.

This patch makes sure that all the scroll_offset returned from layer_tree_host_impl are in the
coordinate of the device, so that the snap_fling_controller can decide the correct value to scroll.

Bug: 827187
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I300a61f1fc2af9d7221d2d6f5f201fc461ada23f
Reviewed-on: https://chromium-review.googlesource.com/984902Reviewed-by: Ali Juma <ajuma@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sandra Sun <sunyunjia@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549302}

This change implements StackAbove in MacViews. Whether StackAbove is "sticky" or not is undocumented
but it appears to be not sticky on Linux or Windows, which is fortunate since
non-sticky is the only implementable behavior on Mac.

Bug: 825937
Change-Id: Idaa4e90fd123b0d6c5bab60de3fb24417a488de1
Reviewed-on: https://chromium-review.googlesource.com/986552Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549301}

This CL adds a URLLoaderThrottle to renderer subresource requests
that delays the navigation by a fixed amount (default 50ms) if it
detects that the resource request is an insecure (e.g. http) ad
request.

The URLLoaderThrottle will be re-used in the browser process for
subframe navigations, so care has been made to fit it in the
content/common layer.

Some other misc changes to make this happen / testable:
 - Add IsAdResource() to blink::WebURLRequest
 - URLLoaderThrottleProvider changed to take a full blink::WebURLRequest
   instead of a blink::WebURL.
 - TestURLLoaderFactory extended to support redirects.
 - ThrottlingURLLoader partly exposed to content/public/test.

Bug: 829042
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: Ia98891ed8c07a3c85e1f9986c29d841698ed9228
Reviewed-on: https://chromium-review.googlesource.com/994152
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549300}

Just one more step in Removing the Physical Web from Chrome.

BUG=826540

Change-Id: I617bfd3d82acae53f3654a59f51a03ff8c6b5f96
Reviewed-on: https://chromium-review.googlesource.com/988835Reviewed-by: Bernhard Bauer <bauerb@chromium.org>
Reviewed-by: Matt Reynolds <mattreynolds@chromium.org>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Commit-Queue: Conley Owens <cco3@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549299}

These should have been removed when the WebVR URL toast moved in with
its indicator friends.

BUG=
R=tiborg

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;master.tryserver.chromium.linux:linux_vr;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I414ce7ecd01762d9e84607635fbb5e490c27fa26
Reviewed-on: https://chromium-review.googlesource.com/998407Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org>
Commit-Queue: Christopher Grant <cjgrant@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549298}

logic is triggered by the task queue selector.

Change-Id: I7944632f176a325505fb2e2c3ea4d1690c792092
Reviewed-on: https://chromium-review.googlesource.com/995774
Commit-Queue: Farah Charab <farahcharab@chromium.org>
Reviewed-by: Brian White <bcwhite@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549297}

The old AppList behavior dismissed the Applist when a tap or click was
not within the AppsGridView bounds. Instead we would like to dismiss the
AppList if a tap or click lands on an empty region.

Bug: 829473
Change-Id: Iafa4753f917aef6839b151e83b314a6b036dc906
Reviewed-on: https://chromium-review.googlesource.com/998521
Commit-Queue: Alex Newcomer <newcomer@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549296}

This makes thumbnails show up in downloads home and notifications
for prefetched pages.

Bug: 794828
Change-Id: I77a1dd34d71c6b56531e31325ee7a13edc992229
Reviewed-on: https://chromium-review.googlesource.com/990201
Commit-Queue: Dan H <harringtond@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Reviewed-by: Carlos Knippschild <carlosk@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Reviewed-by: Shakti Sahu <shaktisahu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549295}

Change-Id: I380b39df681abf1940db33fcbbff9ff3a7b2bc55
Reviewed-on: https://chromium-review.googlesource.com/1000030Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549294}

See blink-dev thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/kPli8ZCUeok

A browser test is moved to be a tentative WPT due to this change.

Bug: 772515
Change-Id: Icf99c8c303c5055dcbcdace6ae94e3fcd1a01921
Reviewed-on: https://chromium-review.googlesource.com/980599Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Jonathon Kereliuk <kereliuk@chromium.org>
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549293}

https://pdfium.googlesource.com/pdfium.git/+log/6058efdbdc18..d45f9980995a

$ git log 6058efdbd..d45f99809 --date=short --no-merges --format='%ad %ae %s'
2018-04-09 tsepez Make StringViewTemplate be based on pdfium::span<>.
2018-04-09 dsinclair Revert "Remove CXFA nodes instead of CFX_XML nodes"
2018-04-09 tsepez Make pdfium::span<> be based off of UnownedPtr<>.
2018-04-09 thestig Sort test cases in test_runner.py.
2018-04-09 dsinclair Move the CFX_XMLParser out of CXFA_SimpleParser
2018-04-09 hnakashima Remove m_pOldFocusWidget from CXFA_FFDocView.
2018-04-09 dsinclair Remove CXFA nodes instead of CFX_XML nodes
2018-04-09 dsinclair Move code to set XML value to CXFA_Node

Created with:
  roll-dep src/third_party/pdfium
BUG=chromium:813155,chromium:813155,chromium:813155


The AutoRoll server is located here: https://pdfium-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.


TBR=dsinclair@chromium.org

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

Change-Id: I5f87147e3bfe872377d425c648ceaf3f585f38b1
Reviewed-on: https://chromium-review.googlesource.com/996496Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549291}

CommitPendingItem may be called more than once. For example, when a
navigation fails after it is committed, |webView:didFailNavigation|
calls |loadNativeViewWithSuccess|, which calls CommitPendingItem a
second time even though it was already called once in
|webView:didCommitNavigation|.

NavigationAndLoadCallbacksTest.FailedLoad is failing because of this
reason. This CL fixes the test and the occasional crash observed in
WKBasedNavigationManagerImpl::CommitPendingItem.

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

Bug: 734049
Change-Id: Id44d3f31149bd0d301577c2fd06ec414c4254f84
Reviewed-on: https://chromium-review.googlesource.com/1001726Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Commit-Queue: Brian White <bcwhite@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549289}

BUG=internal b/77658409
TEST=Manual. New tests pass.

Change-Id: Ie2062ae47b025327bd7d4a16624ee9125082db32
Reviewed-on: https://chromium-review.googlesource.com/999097
Commit-Queue: Bailey Forrest <bcf@chromium.org>
Reviewed-by: Stephen Lanham <slan@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549288}

Some navigations, such as to NTP or extensions, require passing
command-line flags to the renderer process at process launch time, but
this cannot be done for spare RenderProcessHosts, which are started
before it is known which navigation might use them.  So, a spare
RenderProcessHost should not be used in such cases.

Bug: 808114
Change-Id: Idf780ecd02419c1f7b03b38ca1627197422b9113
Reviewed-on: https://chromium-review.googlesource.com/980576
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549287}

Mac's accessibility API doesn't have a way for us to expose the
active descendant of a control. For something like a list box or grid,
we just pretend that the active descendant is actually focused and that
basically works.

For a combobox, we need VoiceOver to announce the selected option
while keeping focus on the text box. Fix this by exposing the
AXOwns relationship, which VoiceOver uses to find a list box owned
by a combo box.

Rather than plumbing through aria-owns, instead we just expose the
parent of the activeDescendant target. That way things just work if
the author uses aria-activedescendant correctly even if they forget
aria-owns.

Also implements AXHasPopup to match Safari.

Bug: 829945
Change-Id: I7f670ecb8af1056e14e889d31aa52a9917719964
Reviewed-on: https://chromium-review.googlesource.com/999958
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549286}

Remove NativeViewHost::SetPreferredSize since it is implemented in
View now. The View impl notifies parent only when the preferred
size really changes.

Bug: 830093
Change-Id: I3887b3103e45fc06771f68c469258fb4e53bf4e0
Reviewed-on: https://chromium-review.googlesource.com/1002918Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549285}

BUG=830885

Change-Id: Ie04ce7147d6e89e56d2608c928a49f89681829ef
Reviewed-on: https://chromium-review.googlesource.com/1003223Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549284}

This patch refactors the function, so that it uses distinct return paths
for in-bound and out-of-bound end offsets, so that the code flow logic
is cleaner.

Bug: 828719
Change-Id: I5c4553b4e5480a2fcf0b2496e0153f648c002bb3
Reviewed-on: https://chromium-review.googlesource.com/999160
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549283}

Bug: 819875
Change-Id: Ia2aa791fdc170121b3f2e7d5e43e4b79f5da33bb
Reviewed-on: https://chromium-review.googlesource.com/1003147Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Biao She <bshe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549282}

Since the size is always updated using update method, the listener
is not needed. Moreover, the listener might have wrong width and
height information that can't be used for updating the buffer size.

The listener can get called during the updating the autofill
options with invalid Width() and Height() values. As a result,
buffer size would be wrong and Chrome crashes.

Bug: 830471
Change-Id: Ie634241a591f60e2680e291b6fbdf65c9186093b
Reviewed-on: https://chromium-review.googlesource.com/1002871Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Amirhossein Simjour <asimjour@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549281}

When ARC session is restarted or closed, OnTaskDestroyed()
callback is not necessary send for all apps. Because of that
ArcKioskAppService continued to think that kiosk app is still running,
while it's not true.
Perfectly, instead of |if (!app_launcher_)| check in line 193,
it should check whether kiosk app is already running (and update taskid)
but there is no such function, so just re-setting internal state
on restart/close should work too.

BUG=830640

Change-Id: I8097e03000d0d9e21b672672cddaf3a91a1d3214
Reviewed-on: https://chromium-review.googlesource.com/1000455Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Yury Khmel <khmel@chromium.org>
Commit-Queue: Sergey Poromov <poromov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549280}

because we may be during changing the layer tree and
HasSelfPaintingLayerDescendant() may traverse the descendants.

Bug: 830179
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I091c60343d81a4286eb4ebada91bd1f8e3dd6289
Reviewed-on: https://chromium-review.googlesource.com/1002891Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549279}

Ensuring proper cleanup of the spare during browser shutdown
============================================================

To properly cleanup the spare renderer we need to:

1. Make sure it is subject to the fast shutdown path (even if it is
   still starting).  This way the spare will be subject to the
   fast shutdown initiated from chrome/browser/browser_shutdown.cc:

      void OnShutdownStarting(ShutdownType type) {
        ...
        // Call FastShutdown on all of the RenderProcessHosts.  This will be
        // a no-op in some cases, so we still need to go through the normal
        // shutdown path for the ones that didn't exit here.
        g_shutdown_num_processes = 0;
        g_shutdown_num_processes_slow = 0;
        for (content::RenderProcessHost::iterator i(
                content::RenderProcessHost::AllHostsIterator());
             !i.IsAtEnd(); i.Advance()) {
          ++g_shutdown_num_processes;
          if (!i.GetCurrentValue()->FastShutdownIfPossible())
            ++g_shutdown_num_processes_slow;
        }
        ...

2. Make sure the SpareRenderProcessHostManager calls CleanUp on the
   spare for which RenderProcessHostObserver::RenderProcessExited is
   called.


Enabling fast shutdown for currently-starting renderers
=======================================================

This CL removes the code that avoids fast shutdown for renderers that
are currently starting.  This code comes from
https://codereview.chromium.org/397031/patch/2029/2041 by jam@.

I feel confident that fast shutdown will be handled correctly for
renderers that are currently starting.  During the fast shutdown
RenderProcessHostImpl::ProcessDied will be called and reset
|child_process_launcher_| - this will correctly terminate the process
regardless of whether the process 1) has already been started or 2) is
in currently starting:

1. If the process has already been launched, then the destructor of
   ChildProcessLauncher will ensure process termination by eventually
   calling ForceNormalProcessTerminationSync.  This platform-specific
   method will kill the process.

2. If the process is being started, then ChildProcessLauncherHelper will
   eventually (once the process really starts) get the
   PostLaunchOnClientThread callback.  In the PostLaunchOnClientThread
   method we will check if the weak pointer to |child_process_launcher_|
   is still valid and if not, we will also terminate the process via
   ForceNormalProcessTerminationAsync.

   I realize that the above explanation depends on
   PostLaunchOnClientThread method being actually called.  I understand
   that this call might not happen if the browser process crashes.  The
   problem of ensuring child process termination in this case seems like
   an orthogonal, separate problem.

Supporting fast shutdown for currently-starting renderers means that
RenderProcessHostObserver::RenderProcessExited may be called earlier
(it is called by ProcessDied which is used on the fast shutdown path).
I think that such an earlier call is okay - I've tweaked the comments
for RenderProcessHostObserver::RenderProcessReady accordingly (removing
the mention of RenderProcessExited callback).


NOT enabling fast shutdown for not-yet-started or crashed renderers
===================================================================

This CL retains the behavior of NOT enabling fast shutdown for
not-yet-started or crashed renderers.  Such change would break tests
like ChromeRenderProcessHostTest.CloseAllTabsDuringProcessDied
on mac_chromium_rel_ng:

    [render_process_host_impl.cc(3743)]
    Check failed: !within_process_died_observer_.
        base::debug::StackTrace::StackTrace(...)
        logging::LogMessage::~LogMessage()
        content::RenderProcessHostImpl::ProcessDied(...)
        content::RenderProcessHostImpl::FastShutdownIfPossible(...)
        CloseWebContentses(...)
        TabStripModel::InternalCloseTabs(...)
        TabStripModel::CloseAllTabs()
        WindowDestroyer::RenderProcessGone(...)
        content::WebContentsImpl::RenderViewTerminated(...)
        content::RenderProcessHostImpl::ProcessDied(...)
        non-virtual thunk to content::RenderProcessHostImpl::OnChannelError()
        ...

Additionally, supporting fast shutdown for previously-crashed renderers
would also introduce a risk that RenderProcessExited might be called
twice - once when the process crashes and a second time when the process
is subject to the fast shutdown path.


Proper clean-up of a killed spare RenderProcessHost
===================================================

SpareRenderProcessHostManager holds the only reference to a spare
RenderProcessHost* (which otherwise has no IPC routes and a zero
ref-count).  Before this CL, SpareRenderProcessHostManager would
respond to RenderProcessHostObserver::RenderProcessExited call by
dropping the only reference to the spare - this would result in a leak
of the RenderProcessHost object.  After this CL,
RenderProcessHost::Cleanup is called, ensuring proper destruction of the
object in case of a crash or in case of a fast shutdown.


Consistent termination status during fast shutdown
==================================================

To ensure consistent termination status during fast shutdown
(i.e.  TERMINATION_STATUS_STILL_RUNNING) we need to tweak
ChildProcessLauncher::GetChildTerminationStatus to account for processes
that have not yet started.  Without this change Windows would see the
default termination status set in the constructor of
ChildProcessLauncher which would lead to a change in prerender final
status seen in the following callstack:

        prerender::PrerenderContents::SetFinalStatus
        prerender::PrerenderContents::Destroy
        prerender::PrerenderContents::RenderProcessGone
        content::WebContentsImpl::RenderViewTerminated
        content::RenderProcessHostImpl::ProcessDied
        content::RenderProcessHostImpl::FastShutdownIfPossible
        browser_shutdown::OnShutdownStarting
        Browser::OnWindowClosing
        BrowserView::CanClose
        views::Widget::Close
        BrowserCloseManager::CloseBrowsers
        BrowserCloseManager::TryToCloseBrowsers
        chrome::CloseAllBrowsers
        chrome::AttemptExitInternal

and consequently would lead to failures of the following browser tests
on Windows:

    PrerenderBrowserTest.PrerenderQuickQuit
    PrerenderBrowserTest.PrerenderInfiniteLoop


Bug: 808114
Change-Id: I0e1cb47eac0b59866d87b5b3c76aae95e6223760
Reviewed-on: https://chromium-review.googlesource.com/994290Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549278}

I can't figure out what the justification for this is.  Mac infobars are not 2
DIP different in size than views infobars.

BUG=none
TEST=none

Change-Id: Ib54e240c9bc529f3793714012c7317524b0aea71
Reviewed-on: https://chromium-review.googlesource.com/996899Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549277}

This allows us to control the final binary size by optionally including features.

We only want clients to import one umbrella header:
  #import <ChromeWebView/ChromeWebView.h>
To accomplish this, we generate the umbrella header based on the feature flags.

Binary size for Release-iphoneos with Cronet included:
+signin and +autofill: 20MB
-signin and -autofill: 15.5MB
+signin and -autofill: 16.7MB
-signin and +autofill: 19.6MB

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I2981b06812495d9b24b1d9630f010247a7ab1331
Reviewed-on: https://chromium-review.googlesource.com/980737
Commit-Queue: John Wu <jzw@chromium.org>
Reviewed-by: Hiroshi Ichikawa <ichikawa@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549276}

Currently, the frame/border around the VR browsing content window starts
off opaque, and later becomes transparent due to bindings. This makes
it start off transparent.

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;master.tryserver.chromium.linux:linux_vr;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Iaaec76ef7b7ba4c8c54a55fc5a591327bb98d9f3
Reviewed-on: https://chromium-review.googlesource.com/1000517
Commit-Queue: Ian Vollick <vollick@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549275}