GitLab

Use full classpath for desugar as a temporary measure against the desugaring issue in tests.

Bug: 860018, 885273
Change-Id: I0d314dceb31c7df2176bfa6fab452afaa541e22c
Reviewed-on: https://chromium-review.googlesource.com/1236434Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Commit-Queue: Pavel Shmakov <pshmakov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593742}

https://chromium.googlesource.com/catapult.git/+log/64f2ed4bb2f1..c51eb628dd91


git log 64f2ed4bb2f1..c51eb628dd91 --date=short --no-merges --format='%ad %ae %s'
2018-09-24 chiniforooshan@chromium.org Telemetry: UI frame time metrics in TBMv2
2018-09-24 chiniforooshan@chromium.org Telemetry: surface flinger metrics in TBMv2


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

The AutoRoll server is located here: https://autoroll.skia.org/r/catapult-autoroll

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

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

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel

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

Change-Id: I62e4f3af9d10e032a30122d510b0dac2438842e7
Reviewed-on: https://chromium-review.googlesource.com/1241528Reviewed-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@{#593741}

Bug: 884070
Change-Id: I0b7355c29f1c699091537a75ba2f300cff8d7e00
Reviewed-on: https://chromium-review.googlesource.com/1226524
Commit-Queue: Andrew Luo <aluo@chromium.org>
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593740}

https://chromium.googlesource.com/chromium/tools/depot_tools.git/+log/aaf2cc09c687..482d615b83e1


git log aaf2cc09c687..482d615b83e1 --date=short --no-merges --format='%ad %ae %s'
2018-09-24 gab@chromium.org Revert "my_activity: Add review.coreboot.org as a source"
2018-09-24 ajp@chromium.org Revert "git cl upload: print response headers on 404 Gerrit RPC status."


Created with:
  gclient setdep -r src/third_party/depot_tools@482d615b83e1

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.



BUG=chromium:888641,chromium:881860
TBR=agable@chromium.org

Change-Id: Ie6fea307792db8a9e8d4c06cd509e991985269c4
Reviewed-on: https://chromium-review.googlesource.com/1241595Reviewed-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@{#593739}

This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/win.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=gab@chromium.org

Bug: 874080
Change-Id: Icf9c25f614e296b069ce76297ba85b3b8b6e1197
Reviewed-on: https://chromium-review.googlesource.com/1191663
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593738}

https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/fb85aabf9a15..b2070a13fbde


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

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: Id7647b0e35b14522e6b33e6f4cd4db47e7670c19
Reviewed-on: https://chromium-review.googlesource.com/1241527Reviewed-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@{#593737}

This allows for another forced retry point for when installation fails.
If a user goes into multidevice settings and clicks the "set up" button
for Android Messages, it should install the PWA if it hasn't already
been installed before trying to launch it.

Bug: 874605
Change-Id: I319067d100712b84b4161f5ee281179bd8acbf12
Reviewed-on: https://chromium-review.googlesource.com/1240205
Commit-Queue: Jeremy Klein <jlklein@chromium.org>
Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593736}

Change-Id: I086c920a77cb3bdd5c99d9b7bed6bd790076c469
Reviewed-on: https://chromium-review.googlesource.com/1241933Reviewed-by: John Chen <johnchen@chromium.org>
Commit-Queue: Tatiana Buldina <buldina@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593735}

Bug: 887381
Change-Id: I2f0ac7465772e09bf00af224e61ace0a791129fe
Reviewed-on: https://chromium-review.googlesource.com/1241278Reviewed-by: Chong Zhang <chongz@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593734}

Changes a DCHECK to a PCHECK in an attempt to help sort out some crashes
we see in the wild where the broker process apparently receives handles
but doesn't attempt to duplicate them to itself. This should only be
possible if it doesn't know a valid handle for the remote (sending)
process, which points to potential application raciness in ownership of
the process handles passed into Mojo.

Bug: 887576
Change-Id: I1f8786af8170b7db03804a98125365eeb44fc598
Reviewed-on: https://chromium-review.googlesource.com/1241197
Commit-Queue: Ken Rockot <rockot@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593733}

Eliminates text rendering artifacts resulting from launching Chrome
browser with Windows Text Zoom enabled.

----------
Background
----------

The new Windows Text Zoom accessibility feature scales small text on
the screen by an amount in addition to normal DPI scaling. In
consultation with MS accessibility engineers, we have decided that
rather than doing complex and extensive scaling math in Chrome, we are
just going to have the browser scale additionally by that factor.
Chrome now scales dynamically with the zoom factor.

When we read default system fonts (such as those used by the
views::Label class - used by tabs, menu items, bookmarks, etc.), Windows
reports the logical size of the font. This does not take DPI into
account, but it *does* take the Windows Text Zoom amount into account
(for backwards-compatibility with apps that don't read it directly).

When the UI renders the text, it scales by the overall browser scale
factor (which includes both DPI and Windows Text Zoom). So effectively,
if the Text Zoom is set before Chrome starts, all system-default text
ends up scaled *twice*.

Correct text size (current behavior only if Text Zoom is changed *after*
launching Chrome):
 Text Scale 100% 150% 200%
DPI 100%     12   18   24
DPI 150%     18   27   36
DPI 200%     24   36   48

Current text size if Text Zoom is enabled prior to launching Chrome:
 Text Scale 100% 150% 200%
DPI 100%     12   27   48
DPI 150%     18   39   72
DPI 200%     24   54   96

-------------
Patch Details
-------------

This change captures the situations in which we ask Windows for a system
font (for menus and captions), and removes the additional scaling done by
the OS, since we are already taking this into account when rendering
text.

We already apply scaling for localization in most of these places for
similar reasons, so there is a precedent.

Chrome still scales appropriately when Text Scale Factor or DPI is set
prior to Chrome launch or changed dynamically while Chrome is running.

----------
Follow-Ups
----------

We call GetNonClientMetrics() in a number of plces, and use LOGFONT*
structs as well. These are Windows implementation details and should
ideally be hidden away from browser code. We should consolidate to a
single cache of system fonts, which will internally ensure that the fonts
are scaled appropriately (preferably in gfx::PlatformFontWin or similar).

Bug: 866513
Change-Id: Ideb248e2f196bb93d46a3f60780c68cf31446097
Reviewed-on: https://chromium-review.googlesource.com/1235313
Commit-Queue: Dana Fried <dfried@chromium.org>
Reviewed-by: Robert Liao <robliao@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593732}

makesdk.go was deprecated and removed; use artifact tarballs generated
from the supported GN/ninja-based SDK build methods instead.

Change-Id: I6c3e3eb38451f2d0fbfc8940f3c4d4b5c6e89fef
Reviewed-on: https://chromium-review.googlesource.com/1237534Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Kevin Marshall <kmarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593731}

We always end up using DBusThreadManagerLinux on Linux and
DBusThreadManager on Chrome OS. Rather than having clients pass
these when initializing BluezDBusThreadManager, have
BluezDBusThreadManager choose which one to use based on the OS.

This puts the logic for choosing which one to use in a single place.

Bug: 882771
Change-Id: I9c36eb9de8419fd5ac4bc6fbab3ded2738b33d91
Reviewed-on: https://chromium-review.googlesource.com/1237694Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Michael Giuffrida <michaelpg@chromium.org>
Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593730}

We have a few different "features" namespaces, which can collide in
subtle and confusing ways, particularly in jumbo builds.

The Google C++ Style Guide advises avoiding collisions between nested
namespaces and well-known top-level namespaces, and I think "features"
qualifies.

Let's therefore rename app_list::features to app_list_features.

Change-Id: I4fbad5a33b6e5d217924cd008b0f8d9374cf1a43
Reviewed-on: https://chromium-review.googlesource.com/1215023Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#593729}

Bug: 832676
Change-Id: I1a7c9f0834789bbf67692edcd5317d0487905b9f
Reviewed-on: https://chromium-review.googlesource.com/1241713Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593728}

Change-Id: I2d5955ad226d16428cc28cc8e0c908663b9346f8
Reviewed-on: https://chromium-review.googlesource.com/1237866Reviewed-by: Joe Mason <joenotcharles@chromium.org>
Commit-Queue: Chris Sharp <csharp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593727}

Issue can be triggered by running Chrome with testing/xvfb.py.  The check looks
like the following:

[130960:130960:0921/173814.814345:FATAL:color_utils.cc(356)] Check failed: (((base) >> 24) & 0xFF) == SK_AlphaOPAQUE (0 vs. �)
0 0x7f05478f815d base::debug::StackTrace::StackTrace()
1 0x7f05475ff9ac base::debug::StackTrace::StackTrace()
2 0x7f054766f47a logging::LogMessage::~LogMessage()
3 0x7f0545ec4e19 color_utils::GetBlendValueWithMinimumContrast()
4 0x7f0545ec4d25 color_utils::GetColorWithMinimumContrast()
5 0x7f05319ec298 libgtkui::GtkUi::LoadGtkValues()
6 0x7f05319eb2ae libgtkui::GtkUi::Initialize()
7 0x55847d44a79b ChromeBrowserMainExtraPartsViewsLinux::ToolkitInitialized()
8 0x558478c10b15 ChromeBrowserMainParts::ToolkitInitialized()
9 0x558478c0a9c5 ChromeBrowserMainPartsLinux::ToolkitInitialized()
10 0x7f0540a4b64d content::BrowserMainLoop::InitializeToolkit()
11 0x7f0540a4e7b5 content::BrowserMainRunnerImpl::Initialize()
12 0x7f0540a39a6b content::BrowserMain()
13 0x7f05428fefe4 content::RunBrowserProcessMain()
14 0x7f05429018cb content::ContentMainRunnerImpl::Run()
15 0x7f05428f67cc content::ContentServiceManagerMainDelegate::RunEmbedderProcess()
16 0x7f0547ba37fa service_manager::Main()
17 0x7f05428fca23 content::ContentMain()
18 0x558476d46246 ChromeMain
19 0x558476d46152 main
20 0x7f051c7152b1 __libc_start_main
21 0x558476d4602a _start

R=pkasting

Change-Id: Ib6d421dc3cd0f8fb9a41afd4b1487548404f58f0
Reviewed-on: https://chromium-review.googlesource.com/1238487Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593726}

Bug: 832676
Change-Id: Ib83450567e95f83f819980fccb2ea81c6be2a326
Reviewed-on: https://chromium-review.googlesource.com/1241496Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593725}

Bug: 888675
Change-Id: I511958c73dec8caf1c04daf582f7cc4e0752b745
Reviewed-on: https://chromium-review.googlesource.com/1241016Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593724}

Bug: 881922
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
Change-Id: I9298701a3790ca2b7c9aaf43a6c9ce6c1abaa74c
Reviewed-on: https://chromium-review.googlesource.com/1241556
Commit-Queue: Ted Meyer <tmathmeyer@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593723}

Most of the observed crashes are enumeration (aka "linear") ones for
"cast" that are apparently differences between extensions. Behave in
the expected fashion (return dummy histogram) for those so as to not
impact users unnecessarily.

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

TabModelTest.AddWithOrderControllerAndGrouping is converted into
TabOrderTestCase/testChildTabOrdering.

TabModelTest.AddWithLinkTransitionAndIndex is removed because the
behavior it tests, i.e. child tabs being inserted before parent tab, is
not possible using public interfaces. Child tabs are always inserted
after the parent tab.

The original tests use NavigationManager::CommitPendingItem() with a
test server. This is no longer possible with WKBasedNavigationManagerImpl.
Updating the original tests to use embedded test server was rejected
because TabModel is a deprecated class. Converting them to EG test allows
the behavior to be tested with WKBasedNavigationManager and during a
future removal of TabModel.

Bug: 863026
Cq-Include-Trybots: luci.chromium.try:ios-simulator-cronet;luci.chromium.try:ios-simulator-full-configs
Change-Id: Ia8f2b604cab93cba38142cac384a356153e95d9b
Reviewed-on: https://chromium-review.googlesource.com/1240741
Commit-Queue: Danyao Wang <danyao@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593721}

In RTL HitTestbingBidiTest test cases, the hit test locations are
wrong. For example:

<div dir=rtl>ABC</div> is rendered as:

+-------------------------+
|                      ABC|
+-------------------------+
^                      ^
|                      |
div->OffsetLeft()      text left edge

The current test cases misuse |div->offsetLeft()| as text left edge,
which is fixed by this patch.

Test expectations are updated by script jsfiddle.net/tLwhcv9u/39/

Bug: 877263
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I4fd1f855a5e97fa9c2ce69c68a1d30036bef652b
Reviewed-on: https://chromium-review.googlesource.com/1240854Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593720}

Currently BrowserActionsBarIncognitoTest.IncognitoMode crashes when the
RuntimeHostPermissions feature is enabled since the test calls
ExtensionActionViewController::GetIcon with a null web-contents. This ends up
calling ExtensionActionViewController::GetPageInteractionStatus() which accesses
the null web-contents.

Fix this by using InProcessBrowserTest::CreateBrowser which waits for the
browser to have a valid tab.

BUG=888158

Change-Id: I7b763ff54f2a0d65e199582a9ab00549e549f8c0
Reviewed-on: https://chromium-review.googlesource.com/1239458
Commit-Queue: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593719}

The IsLayoutBlock() condition is now consistent with the floating object
locationing logic (which is based on its containing block), and the
condition covers display:-webkit-box.

No new test for the deprecated feature -webkit-box.

Bug: 888534
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iafb4fe1f61b007209f7be8963686996b5a50dbf7
Reviewed-on: https://chromium-review.googlesource.com/1240742
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593718}

This CL removes a chunk of code that modifies UrlBar's scrollX
unnecessarily when displaying RTL text. From what I can tell, this is
no longer necessary.

Bug: 878960
Change-Id: I603a050a7eda437695ff90129eac55467e376dcf
Reviewed-on: https://chromium-review.googlesource.com/1238717Reviewed-by: Theresa <twellington@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Troy Hildebrandt <thildebr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593717}

This CL lays out the scaffolding for adding a footer to the Android
Autofill dropdown. The general goal is to wrap the ListView used by the
existing dropdown in new XML, which will later be expanded to
contain the footer items.

This is accomplished by adding a new XML layout to define the
relationship between the existing list and its footer, and by adding a
new setFooterView method to the popup interface which injects a View
into the designated spot in the layout.


Change-Id: I144580c15be4b204b86b85b3d6e44d11fc9f9acf
Bug: 874077
Reviewed-on: https://chromium-review.googlesource.com/1195894
Commit-Queue: Tommy Martino <tmartino@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Reviewed-by: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Reviewed-by: Fabio Tirelo <ftirelo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593716}

changes in this cl,
- Added overview exit type kWindowDragged for ending overview on window
  drag.
- Set the dragged window as active window on window drag ended, this will
  make sure the dragged window will not lost its activation on overview
  ended.
- Update the non-dragged windows' bounds at the end of animation. Since
  we want no animation if overview ends on window drag, including the
  update bounds animation. Set the animation type to ZERO for all the
  other windows except the dragged window. Then we can only see the update
  bounds animation of the dragged window. All the other windows' bounds
  will be updated at the end of the animation, which can not be seen by
  users.

Bug: 883579
Change-Id: I6a523e6be7caf32757299462cdf6197574768be2
Reviewed-on: https://chromium-review.googlesource.com/1232957
Commit-Queue: Min Chen <minch@chromium.org>
Reviewed-by: Xiaoqian Dai <xdai@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593715}

Bug: 887808
Change-Id: I6ed08f68c1c4b059c412b91c2a6f7952fd44aea4
Reviewed-on: https://chromium-review.googlesource.com/1241493Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593714}

Also fix a bug where enter still leads to print if one of the
paper-buttons on the page is focused (should open dialog instead).
Previously print preview did not have paper-buttons, so  did not check
this case.

Bug: 887844, 888465
Change-Id: Ie041ace8ea0fd5d62096331efba727af55e935f5
Reviewed-on: https://chromium-review.googlesource.com/1239365
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Hector Carmona <hcarmona@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593713}

The entire test suite should be parameterized for legacy and LayoutNG,
but there are some leftover legacy-only tests due to search-and-replace
errors.

This patch parameterizes all such leftovers.

Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: Ia3979861c4213142c4361d1d9d45250e5c9a1772
Reviewed-on: https://chromium-review.googlesource.com/1241153Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Xiaocheng Hu <xiaochengh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593712}

This is a reland of d4d1506d

Original change's description:
> [X11] Don't clear WM state bits when a window is unmapped
> 
> _NET_WM_STATE holds the window state which may be eg: maximized, fullscreen,
> minimized, etc.  In shutdown, Chrome queries this state so that it can restore
> browser windows to the correct state on the next launch.  The problem is that
> Chrome queries this state (hundreds of times, in fact) after the window has
> already gone away.  The EWMH spec requires window managers to delete the
> _NET_WM_STATE property when a window is unmapped [1], so the state that Chrome
> was getting was invalid.
> 
> This CL saves the state when a window becomes unmapped, and includes some small
> cleanups.
> 
> [1] https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336
> 
> BUG=882258
> R=sky
> 
> Change-Id: Iacc43563cd54ade77ac83a580ed24434b6802c91
> Reviewed-on: https://chromium-review.googlesource.com/1226645
> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
> Reviewed-by: Scott Violet <sky@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#592570}

Bug: 882258
Change-Id: I0b68e0d386949f3fe458381a640af7358b7c2269
Reviewed-on: https://chromium-review.googlesource.com/1239252
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593711}

Specifically, if in applying a property from a client another
property changed, then client would not be notified.

BUG=none
TEST=covered by test

Change-Id: Ie0f28eb07a7874a9acdcb4fd4f94b2eda03a040b
Reviewed-on: https://chromium-review.googlesource.com/1240197Reviewed-by: Evan Stade <estade@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593710}

This CL is to fix the crash caused by invalid web_contents access in
safe_browsing::SafeBrowsingUIManager::MaybeReportSafeBrowsingHit

Bug: 888159
Change-Id: I6e7beaa5cd4d7c249d03465e3924635bead0d283
Reviewed-on: https://chromium-review.googlesource.com/1241314
Commit-Queue: Jialiu Lin <jialiul@chromium.org>
Reviewed-by: Daniel Rubery <drubery@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593709}

Instead of ScopedBlockingCall or AssertBlockingAllowed(),
AssertLongCPUWorkAllowed is used in FinalizeLauncherIconInBackground()
and in CreateLauncherIconFromFaviconInBackground().

Original CL intention was:
This CL uses ScopedBlockingCall to mark blocking calls in /chrome/browser/android/webapps.

This CL was created by replacing calls to AssertBlockingAllowed()
with instantiations of ScopedBlockingCall(MAY_BLOCK).
I kindly ask the reviewer to make sure of the following:
  - ScopedBlockingCall is instantiated in a scope with minimal CPU usage.
    If this is not the case, ScopedBlockingCall should be instantiated
    closer to the blocking call. See scoped_blocking_call.h for more
    info. Please let me know when/where the blocking call happens if this needs
    to be changed.
  - Parameter |blocking_type| matches expectation (MAY_BLOCK/WILL_BLOCK). See
    BlockingType for more info. While I assumed MAY_BLOCK by default, that might
    not be the best fit if we know that this callsite is guaranteed to block.
  - The ScopedBlockingCall's scope covers the entirety of the blocking operation
    previously asserted against by the AssertBlockingAllowed().

This CL was uploaded by git cl split.

R=dominickn@chromium.org

Bug: 874080
Change-Id: I31ed4164dbd93d424b7a3a69f833519d13c6fbf1
Reviewed-on: https://chromium-review.googlesource.com/1191185Reviewed-by: Dominick Ng <dominickn@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593708}

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)

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

Bug: 784059
Change-Id: I8ee0ee797b54a8166849ab6e9b9f019b9e43760b
Reviewed-on: https://chromium-review.googlesource.com/1240871
Commit-Queue: Christian Biesinger <cbiesinger@chromium.org>
Commit-Queue: Emil A Eklund <eae@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593707}

This reverts commit 267cb8af.

Reason for revert:

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

Sample Failed Build: https://ci.chromium.org/buildbot/chromium.linux/linux-jumbo-rel/7066

Sample Failed Step: compile

Original change's description:
> Remove SkColorSpaceXform usage from Canvas code
> 
> This is the last CL to remove SkColorSpaceXform call sites from
> third_party/blink. This change also does some refactoring in
> ImageBitmap unit tests, etc.
> 
> TBR=fserb@chromium.org
> 
> Bug: 774520
> Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: I8279f1687ef096ae9aa2179c74d5d6cf2364ce9b
> Reviewed-on: https://chromium-review.googlesource.com/1237140
> Reviewed-by: Mohammad Reza Zakerinasab <zakerinasab@chromium.org>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Mohammad Reza Zakerinasab <zakerinasab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#593674}

Change-Id: I8fd0d3dcd6e2e5e4eb8251485ce07451bf8f11e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 774520
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/1241762
Cr-Commit-Position: refs/heads/master@{#593706}

Change-Id: Ie9594e5ee6b01ff2f940119dcf77f0ba7503693b
Reviewed-on: https://chromium-review.googlesource.com/1239420Reviewed-by: agrieve <agrieve@chromium.org>
Commit-Queue: Aiden Benner <abenner@google.com>
Cr-Commit-Position: refs/heads/master@{#593705}

Bug: 880973
Change-Id: Ic92339a48740e4e18781d81861252c9fc6424d2a
Reviewed-on: https://chromium-review.googlesource.com/1239629
Commit-Queue: Stephen Martinis <martiniss@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593704}

The problem was that the old sign-in flow didn't work with networking service. This hasn't been converted to use DICE, which already works.

There were two causes:
-webRequest interception wasn't enabled for the few internal webui pages that are whitelisted for webRequest API
-webRequest users don't see Set-Cookie headers for responses (since these were sent to the interceptor from the network process, and the IPC serialization removes Cookie headers)

Bug: 887381
Change-Id: I4f0b598c1610cd3b11dcf01cdd4d43425f218a4f
Reviewed-on: https://chromium-review.googlesource.com/1238720Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593703}