GitLab

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}

A better fix would be fix PhysicalDisplayAndroid.java, but given this is
fixed in JB MR1, I don't think it's worth the extra effort.

Bug: 829318
Change-Id: Ibe03c8392bf86b69322ff01f9ddf3c63396a161f
Reviewed-on: https://chromium-review.googlesource.com/1001707
Commit-Queue: agrieve <agrieve@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549274}

Bug: 830820
Change-Id: I80da487af6c8b8738dea00f13f2e3f782ec7150a
Reviewed-on: https://chromium-review.googlesource.com/1003138Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Michael Thiessen <mthiesse@chromium.org>
Commit-Queue: Tibor Goldschwendt <tiborg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549273}

https://chromium.googlesource.com/angle/angle.git/+log/6c59e4a156c3..bb52c523556e

$ git log 6c59e4a15..bb52c5235 --date=short --no-merges --format='%ad %ae %s'
2018-04-06 oetuaho Invariant declaration doesn't make a variable active

Created with:
  roll-dep src/third_party/angle
BUG=chromium:829553


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

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
TBR=ynovikov@chromium.org

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

Specifically, this includes metrics reported by ChromeOSMetricsProvider
in the system profile for UKM. The following fields will now be included:
- hardware.hardware_class
- hardware.internal_display_supports_touch
- hardware.bluetooth (and all the sub-fields)
- multi_profile_user_count

A note on the implementation: This reports the new short hardware class
field that is now reported to UMA (as of M67), as enabled by the kUmaShortHWClass
feature. This CL also improves this logic (both for UMA and UKM) by doing it
synchronously which is possible with the new implementation. The bluetooth data
is still retrieve asynchronously however - which is new for UKM service.

In addition, this CL fixes MetricsProvider initialization order in UkmService,
where previously the Init() call on providers was happening before providers were
added. This was not a problem before because the existing providers did not do
anything in Init().

This change also improe

Bug: 807663, 810872
Change-Id: I4b0dcb848e40a467a26feaf757f43aaf442be050
Reviewed-on: https://chromium-review.googlesource.com/996175
Commit-Queue: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549271}

Bug: 830853

Change-Id: I893b5d205d6f3e033e0d5cc7f95d4acc4391fd23
Reviewed-on: https://chromium-review.googlesource.com/1001475Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Dmitry Skiba <dskiba@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549270}

Better enterprise management detection. Detect additional OpenDirectory nodes and alternative identities. Filture out iCloud users.

Change-Id: I36e71f89928e180cfe257cae079a303fd8d7db74
Reviewed-on: https://chromium-review.googlesource.com/999263Reviewed-by: Sorin Jianu <sorin@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Boris Vidolov <borisv@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549269}

These tests cannot invoke Print via the share menu on iOS11, so they
are redundant with the tests in JSPrintTestCase.

BUG=825431,683280

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I0e9965dfddf1e49d583a5304d7392cd59ac63bca
Reviewed-on: https://chromium-review.googlesource.com/990533Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Rohit Rao <rohitrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549268}

In monochrome webview mode onResourceLoaded currently rewrites all
resource ids inside resource arrays including system resource IDs. This
is a bug.

The first try to fix the bug (cl/952097) caused a performance regression
in webview startup so this is a different idea to fixing the same bug
that should hopefully not suffer from the same performance regression as
the previous.

Since resource IDs are sorted (so system resources are at the beginning
of the array).  This CL finds the index of the first non-system resource
ID and starts rewriting at that point.

NOTRY=true #win7_chromium_rel_ng extremely flakey

Bug: 821425
Change-Id: I9f6f3c517a8c09cbbefb9b584ab6f5bfc9c8477b
Reviewed-on: https://chromium-review.googlesource.com/999003
Commit-Queue: Mohamed Heikal <mheikal@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549267}

As per steimel@'s comment in crrev.com/c/991293 we should always
create the play button as we use it when the video element is
very small.

BUG=821961,821414

Change-Id: Icec781d0cd49529c72dd21c88d54727e81236890
Reviewed-on: https://chromium-review.googlesource.com/1000722
Commit-Queue: Becca Hughes <beccahughes@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549266}

https://chromium.googlesource.com/external/khronosgroup/webgl.git/+log/da5abe6..aef0b3a

Bug: 806557, 829541, 830046
Change-Id: I2c1b6f58e8005094f3174b7c9a228a67ee2d379b
Cq-Include-Trybots: master.tryserver.chromium.win:win_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_angle_rel_ng;master.tryserver.chromium.angle:win_angle_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/996896
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549265}

We have evidence of DownloadCurrentCandidateOrAskFaviconService()
crashing due to current_candidate() being null, at least until recent
fixes.

Temporarily and as a precaution, we return early in case the problematic
scenario is reproduced. We suspect this condition is not reached in
trunk, but it's a simple workaround to cherry-pick.

Bug: 828196
Change-Id: I41e2236f341a9ed9e18a950540f096e9de42df0b
Reviewed-on: https://chromium-review.googlesource.com/1002093Reviewed-by: Peter Kotwicz <pkotwicz@chromium.org>
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549264}