GitLab

Fix nits as well.

BUG=537099

Change-Id: I55ee7d530ca73e13ae63049f07242853650687b2
Reviewed-on: https://chromium-review.googlesource.com/1188639
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Xiaohui Chen <xiaohuic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586409}

Adds focus and ink drop behaviors to ActionView to be consistent with
other DialogPlate buttons.

Bug: b:112925587
Change-Id: Ia6fa90478a2d28d56e5fda0bfd0988239df64c01
Reviewed-on: https://chromium-review.googlesource.com/1189445Reviewed-by: Xiaohui Chen <xiaohuic@chromium.org>
Commit-Queue: David Black <dmblack@google.com>
Cr-Commit-Position: refs/heads/master@{#586408}

Removing these was an oversight.

BUG=779614
TEST=test only change

Change-Id: I726deff7a1b25319f0b3f8740ddde88daa0262cd
Reviewed-on: https://chromium-review.googlesource.com/1190843
Commit-Queue: Scott Violet <sky@chromium.org>
Reviewed-by: Mohsen Izadi <mohsen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586407}

Previously, when the caret moves in content, we fire two MSAA location
change events for the caret:
1. In the Chrome_RenderWidgetHostHWND (content window)
2. Chrome_WidgetWin_1 (UI window)

The ZoomText screen magnifier application is the primary consumer of
these events, and they've asked that we only fire them for the
Chrome_WidgetWin_1. This keeps their logic simpler and is more
performant from their point of view.

TBR=sadrul@chromium.org
NOTRY=true

Bug: 877487
Change-Id: I05a2d1ba1d6c13c5a5aa4a16c9b91826301eb1f9
Reviewed-on: https://chromium-review.googlesource.com/1188603
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586406}

Include coordinates for the root window and also the TouchMove
(mousemoves) as part of the debugging output.

Bug: 833380
Change-Id: I769bdabefd1fdbaedf43ae5533e097c8da46ae8b
Reviewed-on: https://chromium-review.googlesource.com/1191084Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586405}

The issue happens when the timing of destruction is different from the
usual one. For example, when Dev Tools are open.

Bug: 875621
Change-Id: I734b010a80e6926c5429fec79f93d63612673d09
Reviewed-on: https://chromium-review.googlesource.com/1187002
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: apacible <apacible@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586404}

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

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

Bug: 874080
Change-Id: I0aad6d7dd8dd315323a365f900b9074559bd0a7f
Reviewed-on: https://chromium-review.googlesource.com/1191192
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: proberge <proberge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586403}

This reverts commit 430c8fbe.

Reason for revert: various perf regressions.
This should instead be solved via issue 874680.

Original change's description:
> cc: Finish frame early if main thread is idle regardless of redraw state
>
> This condition was added originally in this patch:
> https://codereview.chromium.org/27200003
>
> That patch was trying to trigger early deadlines when the compositor
> thread had work to do but the main thread had aborted.
>
> In a world where we have begin frame acks even when frames aren't
> produced, it's worth triggering early deadlines even when the compositor
> thread doesn't have any work to do either so that the display compositor
> can go ahead and do work earlier.
>
> This is intended as a short-term fix to solve smoothness issues with
> surface for video with 30fps videos.  Ideally the DisplayCompositor will
> have some followups as well so that one client that is slow to respond
> will not cause smoothness issues with another client.
>
> Bug: 874676
> Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: I8b6663570aba7d135c1f211a21c37b1e17d19577
> Reviewed-on: https://chromium-review.googlesource.com/1176559
> Commit-Queue: enne <enne@chromium.org>
> Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#583908}

TBR=enne@chromium.org,sunnyps@chromium.org

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

Bug: 874676, 875255, 875316, 875323, 875328, 875424, 876099
Change-Id: I4fd531fe07396ec2275bfd9109c8d86c6b4778f5
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/1191326
Commit-Queue: enne <enne@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586402}

https://skia.googlesource.com/skia.git/+log/adb4bfef0cd8..22b21ea25b29


git log adb4bfef0cd8..22b21ea25b29 --date=short --no-merges --format='%ad %ae %s'
2018-08-27 brianosman@google.com Stop blacklisting some critical unit tests on Metal
2018-08-27 reed@google.com textonpath util
2018-08-27 caryclark@skia.org fix pathops unsortable angles
2018-08-27 brianosman@google.com Remove MSAA from Metal caps
2018-08-27 bsalomon@google.com Disable GrTextureOp Chaining
2018-08-27 brianosman@google.com Don't assert trying to make an MSAA surface with Metal, just fail
2018-08-27 scroggo@google.com Reland "Switch SkCodec to use skcms plus fixes""
2018-08-27 halcanary@google.com SkPDF/Type1:  fix BUG:skia:8285
2018-08-27 bsalomon@google.com Make GrGLInterface great for Win32 x86 again
2018-08-27 angle-skia-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com Roll third_party/externals/angle2 8707af516c46..89664843c656 (1 commits)
2018-08-27 reed@google.com use nothingToDraw more often
2018-08-27 kjlubick@google.com Add a renderer key to lottie gold digests
2018-08-27 scroggo@google.com Ignore PLTE chunks in non-palette PNGs
2018-08-27 robertphillips@google.com Always render GPU masks with AA rendering
2018-08-27 brianosman@google.com Add a version of the skbug6653 unit test that disables explicit resource allocation
2018-08-27 ethannicholas@google.com Revert "Revert "added support for sk_Dimensions to SkSL""
2018-08-27 fmalita@chromium.org [skottie] Add support for keyframed text nodes


Created with:
  gclient setdep -r src/third_party/skia@22b21ea25b29

The AutoRoll server is located here: https://autoroll.skia.org/r/skia-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=master.tryserver.blink:linux_trusty_blink_rel;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:877610,chromium:877598
TBR=stephana@chromium.org

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

Change-Id: Ib2365e75f4b0388914689928c862c290264ac4b3
Reviewed-on: https://chromium-review.googlesource.com/1188501Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586400}

BUG=878013

Change-Id: Ieba7e71438fcc684d6ffc2aeaea138a2f062b7f6
Reviewed-on: https://chromium-review.googlesource.com/1191228Reviewed-by: Becky Zhou <huayinz@chromium.org>
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Commit-Queue: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586399}

Previously, Assistant was visibility was either true || false.
Now, Assistant is one of { kClosed, kHidden, kVisible  }.

These visibility states are:
- kClosed: Assistant is not visible. Launching Assistant will start
           a new session with a clean stage.
- kHidden: Assistant is not visible. Launching Assistant will resume
           a paused session with the stage in its previous state.
- kVisible: Assistant is visible and a session is in progress.

Per product requirement:
- We become kClosed when explicitly dismissed by the user.
- We become kHidden when dismissed by auto-navigation.

Still TODO: Implement timer to auto-close if hidden for 5min.

See bug for demo.

Bug: b:113129833
Change-Id: I2f0f5dba3c2d58d55e5e494b69a93cbb8a667d66
Reviewed-on: https://chromium-review.googlesource.com/1188748
Commit-Queue: David Black <dmblack@google.com>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Xiaohui Chen <xiaohuic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586398}

Windows bots need more cores. Mac bot has less cores, will try 4 cores
for now and see if it works.

Bug: 867725
Change-Id: If1b4a1eecc446a75f9047076068a87bae9a648b5
Reviewed-on: https://chromium-review.googlesource.com/1191670Reviewed-by: Ryan Tseng <hinoka@chromium.org>
Commit-Queue: Stephen Martinis <martiniss@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586397}

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

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

Bug: 874080
Change-Id: I2984ff747f7cce7b40f48251c4bdaa21d0b0df93
Reviewed-on: https://chromium-review.googlesource.com/1191582Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586396}

Changes the default internal polling interval for gamepad state from
16 ms (~60 Hz) to 4 ms (~250 Hz).

BUG=855188

Change-Id: I4b791c27330b56519a7484c423ec764a00320e01
Reviewed-on: https://chromium-review.googlesource.com/1191234Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586395}

Check that the embeddedsearch APIs for custom background correctly
update the ThemeBackgroundInfo when called.

Bug: 857256
Change-Id: I7c71ddbbdc30fa9fbcf4a2afc8387affcc39693c
Reviewed-on: https://chromium-review.googlesource.com/1189082Reviewed-by: Kristi Park <kristipark@chromium.org>
Commit-Queue: Kyle Milka <kmilka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586394}

Bug: skia:8155
Change-Id: I83c2c31a0e069598d3584d4059158d70113f63d6
Reviewed-on: https://chromium-review.googlesource.com/1171022Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Cr-Commit-Position: refs/heads/master@{#586393}

Add methods mouse capture methods to the BridgedNativeWidgetPublic
interface that BridgedNativeWidget implements.

Have BridgedNativeWidget pass the mouse capture status to
BridgedNativeWidgetHostImpl, which the NativeWidgetMac will access.

Add NativeWidgetMac::GetBridgeHostImplForNativeWindow method for
unittests, and merge the implementations of GetBridgeForNativeWindow,
GetBridgeHostImplForNativeWindow, and GetNativeWidgetForNativeWindow.

Bug: 859152
Change-Id: I25af661ad487b4f5a89bb02b1c655fb0ab27b8fb
Reviewed-on: https://chromium-review.googlesource.com/1186161Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586392}

This protocol will be use to implement the WebDriver Extension
Command specced here:
https://w3c.github.io/reporting/#generate-test-report-command

Change-Id: Idfe7fc40bc85589b1fc6e79f2d603ed01cf78840
Reviewed-on: https://chromium-review.googlesource.com/1188754Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Paul Meyer <paulmeyer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586391}

This CL uses ScopedBlockingCall to mark blocking calls in /chromecast.

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

Bug: 874080
Change-Id: I57c774dacb924224a77f31a9644242a6931d52cf
Reviewed-on: https://chromium-review.googlesource.com/1191235Reviewed-by: Sergey Volk <servolk@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586390}

Got one new crash over the weekend and the if (!web_contents()) check
that I added was the line that crashed. Seems to me like |this| is a
nullptr.

Bug: 876835
Change-Id: I8ee5f1ebf64a864a9d6fb4dc6e3018a6ef8eca83
Reviewed-on: https://chromium-review.googlesource.com/1190844Reviewed-by: Ryan Sturm <ryansturm@chromium.org>
Commit-Queue: Robert Ogden <robertogden@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586389}

This patch simplifies the code
by using base::Erase() and base::EraseIf()
instead of erase(std::remove) and erase(std::remove_if)

Bug: 875665
Change-Id: I92d02ad090029fb6884b53f05d2de7715a72314a
Reviewed-on: https://chromium-review.googlesource.com/1189583Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Jinho Bang <jinho.bang@samsung.com>
Cr-Commit-Position: refs/heads/master@{#586388}

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

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

Bug: 874080
Change-Id: Ic4c282e65f8d9aa3b9c6d95d8c89c0311b8b712a
Reviewed-on: https://chromium-review.googlesource.com/1191225Reviewed-by: Sean Kau <skau@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586387}

BUG=877916

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

This just adds new policy templates without implementation.

Bug: 853724
Change-Id: Id2e0e9d0a3cbf353893fe96821e646dd0f5795a5
Reviewed-on: https://chromium-review.googlesource.com/1155120
Commit-Queue: Vladislav Kuzkokov <vkuzkokov@chromium.org>
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586385}

Bug: 877437
Change-Id: Id444baf870a3b9b4942f57bedb0d3b275e29ba81
Reviewed-on: https://chromium-review.googlesource.com/1191133Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Pedro Amaral <amaralp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586384}

Bug: 847985
Change-Id: I4c6c004db4f5180200c421b8bc7b6c530a7d653f
Reviewed-on: https://chromium-review.googlesource.com/1189105Reviewed-by: Kim Paulhamus <kpaulhamus@chromium.org>
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Cr-Commit-Position: refs/heads/master@{#586383}

Also clarify the role of the object returned from subscribe() by
aliasing it as "Subscription". Now a reader of the code can look
at the code and say "An Observable can subscribe an Observer and
return a Subscription, which can be closed", just by looking at
the type signatures.

This nomenclature is used in other reactive frameworks like
ReactiveX.

"Subscription" should be much more understandable than "watch()-
scope", which was how the documentation used to refer to it.

Bug: None
Test: cast_base_junit_tests, cast_shell_junit_tests
Test: build downstream counterpart change

Merge-With: eureka-internal/195817

Change-Id: I9c35bfd7fc6524fa5eb7b1c2b5eecf36813310f2
Reviewed-on: https://chromium-review.googlesource.com/1187736Reviewed-by: Luke Halliwell <halliwell@chromium.org>
Commit-Queue: Simeon Anfinrud <sanfin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586382}

This removes the previews piece of verbose status triggering from the
weird security checks that offline uses. Since the preview badge is
shown under all cases expect when a bad SSL page is being shown, make
the code reflect that.

Bug: 871839
Change-Id: If14d110f23a90b36906df7d846c5c1a8ff957baa
Reviewed-on: https://chromium-review.googlesource.com/1191027
Commit-Queue: Robert Ogden <robertogden@chromium.org>
Reviewed-by: Ryan Sturm <ryansturm@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586381}

Change-Id: I45224f299e5ac7fcff88241c7a5e0689603717cf
Reviewed-on: https://chromium-review.googlesource.com/1189545Reviewed-by: Ramin Halavati <rhalavati@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586380}

Bug: 873316
Change-Id: I2d034ad8e7e272b487741eaa40f5318185caff6c
Reviewed-on: https://chromium-review.googlesource.com/1190664
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Robert Kaplow (slow) <rkaplow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586379}

The special properties of ObserverList were not needed because
of how Controller uses a Sequencer to avoid concurrent
modification. This also avoids heap allocation of iterators and
the use of the O(n) memory Itertools.reverse() when closing
scopes.

Bug: None
Test: cast_base_junit_tests
Change-Id: I91ef516caf07de8b9a899c17b015f2e2838fee35
Reviewed-on: https://chromium-review.googlesource.com/1191087Reviewed-by: Luke Halliwell <halliwell@chromium.org>
Commit-Queue: Simeon Anfinrud <sanfin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586378}

Bug: 864194
Change-Id: I84311118bdfc6921875741fa6ba31ba38bcf1fb6
Reviewed-on: https://chromium-review.googlesource.com/1185217Reviewed-by: Robert Kaplow (slow) <rkaplow@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586377}

Cq-Include-Trybots: luci.chromium.try:linux_mojo
Change-Id: I305000589be2e48356c1c7168269edd83cf9a7ec
Reviewed-on: https://chromium-review.googlesource.com/1191284Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586376}

On 32-bit Windows builds where DCHECK is enabled, ComInitCheckHook
hot-patches CoCreateInstance() to DCHECK that it is called in
appropriate circumstances. The hot-patching method can only be used once
(details in base/win/com_init_check_hook.cc), and Chrome's usage may
conflict with other drivers that may want to hot-patch the same method
(example in https://crbug.com/737090).

This CL adds answers to the following questions that may arise when
investigating hot-patch failures.

1) Is hot-patching failing due to a bug where the HookManager singleton
   is instantiated twice? This can happen if base is linked in twice.
   This question is answered by printing the bytes that would be written
   to the hot-patch area, so they can be compared with the current
   values.
2) Is hot-patching failing due to a previous failure to revert the
   hot-patch? This question is answered by DCHECKing that reverting the
   hot-patch never fails. (The code previously just assumed that.)

Bug: 877868
Change-Id: I94f81b3816417447d31fc700c6b81d8325222d1a
Reviewed-on: https://chromium-review.googlesource.com/1189143
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Robert Liao <robliao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586375}

Adds about:flags support for ResourceLoadingHints and fixes an
issue for determining the initial PreviewsState (where we need
to "allow" ResourceLoadingHints preview even if no hints loaded
for it yet (will be checked at commit time).

Bug: 871795
Change-Id: I52529a29dabf6e5be23c49bf7f597783418d053b
Reviewed-on: https://chromium-review.googlesource.com/1187574
Commit-Queue: Doug Arnett <dougarnett@chromium.org>
Reviewed-by: Ryan Sturm <ryansturm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586374}

PatchSet 1 is originally reviewed in
https://chromium-review.googlesource.com/c/chromium/src/+/1142384

On top of the original CL, this updates the following:
1. Notify oobe dialog state based on the visibility of the oobe dialog.
2. Send additional data SetShowGuestButtonForGaiaScreen to login shelf.

Bug: 857514, 869811
Change-Id: Ic8baae2e31d2818f356e7fc79f172e4091053fec
Reviewed-on: https://chromium-review.googlesource.com/1168105
Commit-Queue: Xiaoyin Hu <xiaoyinh@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586373}

https://chromium.googlesource.com/angle/angle.git/+log/89664843c656..22f7aafb44b7


git log 89664843c656..22f7aafb44b7 --date=short --no-merges --format='%ad %ae %s'
2018-08-27 bryan.bernhart@intel.com Add webgl checks in GetActiveUniformsiv.
2018-08-27 syoussefi@google.com Fix dEQP_GLES3.functional.negative_api.shader.program_binary


Created with:
  gclient setdep -r src/third_party/angle@22f7aafb44b7

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

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

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

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
TBR=geofflang@chromium.org

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

Change-Id: I0cf147382da7458f9e63ddfbdec797880a78724e
Reviewed-on: https://chromium-review.googlesource.com/1188827Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586371}

Use base::NoDestructor, range-based for loops, and initialize members in
headers. Also mark some constants as constexpr.

Change-Id: I7cfef2e80f8fc285af560f48cfbcaf264b03513e
Reviewed-on: https://chromium-review.googlesource.com/1189542Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586370}