GitLab

mojo::internal::ValidateStruct is not able to fold properly even though
almost 90% of the disassembly of the defined template specializations is
the same because the call to T::Validate is unique.

This change slightly modifies the internals of mojo::internal::Validate*
to call a new helper function which pulls out most of the similar
functionality. While the helper function is also templated, because the
compiled specializations are identical, the compiler is able to fold all
the calls to the same function.

This reduces the overall size of chrome.dll and chrome_child.dll by
24 KB each for a total of 48 KB in disk space savings. If there are
other dlls that compile in mojo, these will experience similar benefits.

Other approaches considered included:
- creating an interface which defined helper functions within
T:Validate. While this did allow all the functions to fold for 400 KB
savings, this also opened us to a security risk because the *_Data
objects are sent via IPC and could be coming from anywhere.
- Including the ScopedDepthTracker call in the helper. This resulted in
bugs since the ScopedDepthTracker takes advantage of deconstructors to
keep track of how far down we've recursed through Validate function.
- Generalize the header validation code generated in T:Validate. This
resulted in a size increase. The reason is that we know the number of
loops at compile time, so the compiler is able to take advantage of loop
unrolling.

Bug: 988151
Change-Id: I80e8d35005dc3ec1a8c09762bf14b0823af7c3bd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1723023Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#682339}

AppsContainerView stops changing its state on closing, which
causes to remain the suggestion chips on inconsistent state with
its view.

I believe it is still good to keep the suppressing the state
change, but we need to reset the suggestion chip state on re-show.

Bug: 988566
Test: manually
Change-Id: Iddb2a4a69c17f601a66e80419ce58f28df4ca18e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725236Reviewed-by: Alex Newcomer <newcomer@chromium.org>
Commit-Queue: Alex Newcomer <newcomer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682338}

Previously this used to crash on a DCHECK. Now we should explicitly
disallow this, since an active window (requested to be moved to
another desk via shortcut for example) might be an always-on-top
window, or a pip.

BUG=988886
TEST=Added new test

Change-Id: Iacb3562e8cb8bd789b9e3a88ac6b977242a79c7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725549
Commit-Queue: Ahmed Fakhry <afakhry@chromium.org>
Reviewed-by: Xiaoqian Dai <xdai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682337}

The LogBuffer had some surprising behavior:

// This would DCHECK;
LogBuffer buf1;
buf1 << "Foo" << Tag{"div"};

// This would create two nested divs instead of a sequence of two divs:
LogBuffer buf2;
buf1 << Tag{"div"} << CTag{} << Tag{"div"} << CTag{};

This CL fixes these problems by introducing fragments - the equivalent to the
DOM DocumentFragment. The root of each LogBuffer is now a fragment that can
host an arbitrary number of children of type text and element.

Some optimizations occur: A LogBuffer with a single child in the fragment will
return this child when LogBuffer::RetrieveResult() is called. Similarly,
streaming a LogBuffer into another one will inline the children of the first
into the second instead of appendin the fragment. Due to these optimizations,
the JavaScript handler in the WebUI can be sure that only the outer most Node
is a fragment.

Bug: 928595
Change-Id: I0eed2f1e900a5aca9511c771d18ee1e264a503e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1724674
Commit-Queue: Dominic Battré <battre@chromium.org>
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682336}

This patch introduces ViewLookupCachingFrameLayout with the intent of
making frequent lookups for views much quicker. The new layout adds a
method "fastFindViewById" that can be used in place of findViewById. Once
the initial lookup has occurred, the view is stored in a map by its ID
until it changes location in the hierarchy, removed, or a view with a
matching ID is added or removed. This class will help accomplish what
was typically done for ViewHolders in RecyclerView.

Bug: 982075
Change-Id: I8f4b4f304649b62dcf15c6af748f9fda02b3f8c6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1696172Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Reviewed-by: Wei-Yin Chen (陳威尹) <wychen@chromium.org>
Commit-Queue: Matthew Jones <mdjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682335}

This change adds an experimental action WaitForDocument for waiting for
the main document or a document in a frame to reach a certain
ready-state. This is similar to what happens implicitly in the click
action, but gives us more control and better understanding of what's
going on.

This is experimental, because it's unknown whether and how much it'll
improve the scripts. The action has been designed to allow extra control
over its operation and report the start and end ready state, for
monitoring and debugging.

Bug: b/137176709
Change-Id: Ief95a5f7644e243625f698385010dfdc08b1aa94
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1713519
Commit-Queue: Stephane Zermatten <szermatt@chromium.org>
Reviewed-by: Clemens Arbesser <arbesser@google.com>
Cr-Commit-Position: refs/heads/master@{#682334}

The usage of R.id.list here causes problems when updating support
library version. Switch to the PreferenceFragmentCompat.getListView()
method instead.

Also add some clarification about when to use
getShowShadowOnScrollListener in preference fragments, and document the
lack of such listener on SearchEnginePreference with a TODO.

Bug: 987748
Change-Id: Ieb76455e6744ec1ed0f300c8fe0914ed630e3562
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725099Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Natalie Chouinard <chouinard@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682333}

This CL reworks the interop mechanism for obtaining version info
from VersionHandler in about:version.  Instead of relying on
chrome.send to result in several asynchronous callbacks, the
parts are requested using cr.sendWithPromise and handlers are
explicitly called by JS.  The original chrome.send mechanism
is left intact for use by platform-specific derived classes.

Bug: 964528

Change-Id: Ia68e95beb68b38201d29d5d51448ee989bdf333f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1717483Reviewed-by: Peter Lee <pkl@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Tommy Li <tommycli@chromium.org>
Commit-Queue: Orin Jaworski <orinj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682332}

This CL is a part of username first flow implementation. The server
sends prediction SINGLE_USERNAME for a field which is a single username
in a form (i.e. the first part of sign-in process).

This CL implements that in case of receiving SINGLE_USERNAME prediction
FormParser chooses this field as a username field, and chooses no other
fields as passwords.

Bug: 959776
Change-Id: I2d62b488c041ace1d525f5627bab8c97aa9ccd20
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726030Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org>
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682331}

This CL changes all methods that obtain the extended AccountInfo
associated with an account with a refresh token to start with
FindExtendedAccountInfoForAccountWithRefreshToken().

TBR=eugenebut@chromium.org

Bug: 970295
Change-Id: Ie76e40d02e88af575686d530879e9119c1bafff2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725634Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Lowell Manners <lowell@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682330}

https://swiftshader.googlesource.com/SwiftShader.git/+log/4c2c8d173f38..fa0175c0988d


git log 4c2c8d173f38..fa0175c0988d --date=short --no-merges --format='%ad %ae %s'
2019-07-30 bclayton@google.com Add missing #include <string>


Created with:
  gclient setdep -r src/third_party/swiftshader@fa0175c0988d

The AutoRoll server is located here: https://autoroll.skia.org/r/swiftshader-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=swiftshader-team+autoroll@google.com

Bug: None
Change-Id: Ie478c02d52c44aa8cd023ae2bcb2528bed202d21
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726292Reviewed-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@{#682329}

Bug: 960513
Change-Id: I2c1782e5e2699ded65939e77b0ce3e90b11ef575
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1684448
Commit-Queue: Sean Harrison <harrisonsean@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Tarun Bansal <tbansal@chromium.org>
Reviewed-by: Robert Ogden <robertogden@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682328}

The timeline uses TimeTicks but animation timestamps use doubles, this
can result in slight imprecision when performing calculations. This
relaxes the currentTime assertions in the playback rate tests to allow
for this.

Bug: 986019,986666
Change-Id: Ie22b0884bd98a4617c3094100897609ab3154bac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1721289
Commit-Queue: Robert Flack <flackr@chromium.org>
Auto-Submit: Robert Flack <flackr@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682327}

The original CL was reverted because one of the content_browsertests
(ScrollLatencyCompositedScrollbarBrowserTest.ScrollbarThumbDragLatency)
got flaky. This failure was not caught because all TryJobs passed the
dry run on retries (crbug.com/988443)

Reason for the flakiness:
This CL exposed a pre existing race condition. The issue only now came
to light because this CL changes how thumb drag takes place.
ScrollbarController::HandleMouseMove now calls ComputeScrollDelta
for calculating the clamped delta. ComputeScrollDelta is where execution
aborts due to the scroll_node being null. The reason the scroll_node is
sometimes null here is because the mousemove reaches ComputeScrollDelta
before GSB has had a chance to set up the scroll_node (due to queueing).
See crbug.com/988308 for more details.

Reverted CL is crrev.com/c/1684532
Reverted CL is in PS2.
New CL is in PS6.

[Description from the original CL]:
Fixes an issue with thumb drags for compositor threaded scrollbar
scrolling. When you click and drag the thumb past the track and then
reverse your drag direction, the pointer no longer sticks to the thumb
and instead, maintains a constant offset with the thumb as it moves.
The reason this happens is because the scroll offset calculation in the
ScrollbarController simply uses 2 factors to calculate the delta. One
of them is the previous_pointer_position_ and the other is the current
pointer location (i.e position_in_widget). There is no logic to check
if the difference between these 2 factors should indeed generate a GSU
or not. The fix is to make the thumb drag delta calculation relative to
the layer and then use LayerTreeHostImpl::CanConsumeDelta to determine
if a scroll should be initiated.

Bug: 1684532
Change-Id: I4a12729ae77725f4a7aac0b02c4b7a3368d8e935
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1722157Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Rahul Arakeri <arakeri@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#682326}

GetAllPolicyValuesAsArray is replaced with ArrayPolicyConversions.
Enable policy value conversion.

Use default settings that includes user policies, disable device data,
enable pretty print and convert policy types to string.

GetAllPolicyValuesAsDictionary is replaced with DictionaryPolicyConversions.
All config is set to defaults. Pretty print, policy type conversion and
user policies are enabled. Device data and policy value conversions are
disabled.

Bug: 983174
Change-Id: I75d8f59a2f268145d762dad6793d8966c0f80592
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725031
Commit-Queue: Owen Min <zmin@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682325}

For now, it will always be an empty array. Populating the array will
come in a later CL.

Bug: 979250
Change-Id: I7dabbec261f280d6937d57a9076033b3b7e09f3a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1724277Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jacob DeWitt <jacde@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682324}

This change exposes the previously-deprecated CSS system color keywords
on Windows that are used for high contrast style overrides. This will
give users the ability to customize their sites with the relevant
system colors for high contrast.

Bug: 970285
Change-Id: I73f746d24f57b494a2f39e7a175715a98bdd4dc6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1689961Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Kevin Babbitt <kbabbitt@microsoft.com>
Commit-Queue: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#682323}

They are required to keep track of whether the Safe Browsing database is
being written to and read back from the disk correctly.

R=mpearson

Bug: 975127
Change-Id: I7464762a40caecd9c95b6be370c6ff9b0d8090a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1721008
Commit-Queue: Varun Khaneja <vakh@chromium.org>
Auto-Submit: Varun Khaneja <vakh@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682322}

If the buffer offset lies outside the boundaries of the AudioBuffer , silently
do nothing instead of throwing an error.

This is a change in behavior where we used to throw an error if the offset was greater
than or equal to the size of the AudioBuffer.

Spec issue: https://github.com/WebAudio/web-audio-api/issues/1884

Bug: 987295
Change-Id: I61955108af0fa3072a2c7174889827781c06747e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1717185Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682321}

Changes in this cl:
- Delete kMenuSeparatorColor, kUnifiedMenuSeparatorColor,
  kUnifiedNotificationSeparatorColor, kUnifiedSystemInfoSeparatorColor
  and kStackingNotificationCounterBorderColor. All of them are colors
  of separators.
  Use kSeparatorOnLightBackgroundColor and
  kSeparatorOnDarkBackgroundColor for colors of separators instead.

- Delete kTrayIconColor, kOobeTrayIconColor, kMenuIconColor,
  kMenuIconColorDisabled, kMobileNotConnectedXIconColor,
  kUnifiedMenuIconColor, kUnifiedMenuIconColorDisabled. All of them are
  colors of icons.
  Use kIconOnDarkBackgroundColor and kIconOnLightBackgroundColor for
  colors of icons.
  kIconOnDarkBackgroundColorDisabled and
  kIconOnLightBackgroundColorDisabled for corresponding disabled icons.

- Rename kUnifiedManagedDeviceIconColor to
  kIconOnDarkBackgroundSecondaryColor.

- Delete kSystemMenuArrowRightIcon, which is not needed now.

Bug: 986911
Change-Id: I94643b80692f65b94fcb93f2398aedc71dcce32d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1721441Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Min Chen <minch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682320}

Include user policies depends on the parameters.
Include device information.

Use default value of no convert value, convert policy type and enable
pretty print.

Bug: 983174
Change-Id: I3882d0f7f5cc0497e9b897c29d0263e7194d09e8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1721377Reviewed-by: Pavol Marko <pmarko@chromium.org>
Commit-Queue: Owen Min <zmin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682319}

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/45872947..11c60ffe

Please follow these instructions for assigning/CC'ing issues:
https://v8.dev/docs/triage-issues

Please close rolling in case of a roll revert:
https://v8-roll.appspot.com/
This only works with a Google account.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux-blink-rel
CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_optional_gpu_tests_rel
CQ_INCLUDE_TRYBOTS=luci.chromium.try:mac_optional_gpu_tests_rel
CQ_INCLUDE_TRYBOTS=luci.chromium.try:win_optional_gpu_tests_rel
CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel

TBR=hablich@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com

Change-Id: I7e27873505ec9658ec9d93a0239942269ff1c804
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725135Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#682318}

Bug: 985201
Change-Id: If3bd3914a758b8b7c79b688a4abd721d3c683850
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726270Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682317}

https://skia.googlesource.com/skia.git/+log/7bacbf71f7d3..4da34bf74723


git log 7bacbf71f7d3..4da34bf74723 --date=short --no-merges --format='%ad %ae %s'
2019-07-30 senorblanco@chromium.org First implementation of GrDawnUniformHandler.
2019-07-30 halcanary@google.com experimental/editor: clean up BUILD.gn


Created with:
  gclient setdep -r src/third_party/skia@4da34bf74723

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=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux-blink-rel;luci.chromium.try:linux-chromeos-compile-dbg;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=benjaminwagner@google.com

Bug: None
Change-Id: I4275a9f42d4fa58692e9c5894397cffc87efba8e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726294Reviewed-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@{#682316}

This CL fixes a race condition where a mousemove is processed before
the renderer has had a chance to set up the scroll state (like the
scroll_node etc). This happens due to the fact that when the renderer
gets a mousedown, it is first "queued" as a GSB. So that meant, the
scroll node was not yet set up. At this point, if a mousemove was sent
from the browser proc before a frame is generated, it gets dispatched
immediately and this can lead to nullptr derefernces.

Bug: 988308
Change-Id: I32d60d33d943a01cb66ce223ea4388de20bc4b64
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725224Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Rahul Arakeri <arakeri@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#682315}

https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/e90f86832eff..42f9ab2813ad


Created with:
  gclient setdep -r src-internal@42f9ab2813ad

The AutoRoll server is located here: https://skia-autoroll.corp.goog/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.

CQ_INCLUDE_TRYBOTS=luci.chrome.try:linux-chromeos-chrome

TBR=jbudorick@google.com

Bug: chromium:None
Change-Id: I6b2ecc1519264073413ddb86c4dfaa444f080ff4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726291Reviewed-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@{#682314}

f in the chat for our brother Will, who has (at least temporarily)
joined infra.

BUG=none
TEST=none

Change-Id: I0e431520cc0eb297d80f5ced134a5cd48b6d5cd1
Signed-off-by: Paul Moy <pmoy@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1721176Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682313}

Try to eliminate race condition identified in https://crbug.com/972871#c32 by waiting for the expected navigations on the UI thread.

Bug: 957657, 972871
Change-Id: I54623c37061aabbb81b570572d03f9dede642863
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1724662Reviewed-by: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Reviewed-by: anthonyvd <anthonyvd@chromium.org>
Commit-Queue: Alexandre Frechette <frechette@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682312}

Bug: 881609
Change-Id: If1575775206e0fbad06637953f2ffbf09f6368fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1722365
Auto-Submit: Takuto Ikuta <tikuta@chromium.org>
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Reviewed-by: Ben Pastene <bpastene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682311}

Using wpt-import in Chromium 6ad84b4c.
With Chromium commits locally applied on WPT:
250461b3 "Worker: Register a service worker just once for worker subresource interception tests"
bf4ad57e "Experimental CookieStore API: some additional browser-side validation"
14d3a4a1 "Sort tracks by id in MediaStreamAudioSourceNode"


Note to sheriffs: This CL imports external tests and adds
expectations for those tests; if this CL is large and causes
a few new failures, please fix the failures by adding new
lines to TestExpectations rather than reverting. See:
https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md

NOAUTOREVERT=true
TBR=lpz

No-Export: true
Change-Id: Ic9d74ee1b6b27dd1a6e3ef3d95bfc6e932d8dfa9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725134Reviewed-by: WPT Autoroller <wpt-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: WPT Autoroller <wpt-autoroller@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#682310}

CI builders migrated:
- TSAN Release
- TSAN Debug

Bug: 950413
Change-Id: Ief5b6cf0113ea507a6f318a7761eedcb5bac7acd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1724678
Auto-Submit: Fumitoshi Ukai <ukai@chromium.org>
Commit-Queue: John Budorick <jbudorick@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682309}

RWHIER::ShowContextMenutAtPoint used last_mouse_move_target_ to
determine RenderWidgetHostImpl instance to forward the call to. It
acknowledged that tracked view may have been destroyed since remembering
it, and it first checked if it was in view map.

This check used to fail for nullptr without crashing leading to an early
return. However, IsViewInMap implementation changed since then and now
if there were no mouse enter/leave events earlier, the browser would
crash trying to dereference nullptr.

This happens when devtools on the desktop connect to a mobile instance
of the browser and forward a right click event on the page.
TouchEmulator will convert it directly to the call to show context menu,
but since remote devtools do not forward mouse move events, as the
mobile does not even have a mouse, this variable will be empty.

However, TouchEmulator already has a target view associated with
emulated touch event that is being converted to context menu request. So
pass that along and use it.

Bug: 987665
Change-Id: I1bf8012827e9397f911a3c12efc984815ad37901
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1718571Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682308}

https://chromium.googlesource.com/angle/angle.git/+log/70cded6ac635..2613cdba80a3


git log 70cded6ac635..2613cdba80a3 --date=short --no-merges --format='%ad %ae %s'
2019-07-30 syoussefi@chromium.org Vulkan: Fix barriers between render passes


Created with:
  gclient setdep -r src/third_party/angle@2613cdba80a3

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@google.com

Bug: None
Change-Id: I80d35189d86a8d5f3b86bac68b1a486cfe78f97f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1726369Reviewed-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@{#682307}

Remove unused method RecordAdFrameUkm from
AdsPageLoadMetricsObserver class.

Bug: 985934
Change-Id: Ib612423fa90f87e9b73297037d7faa3b448f7d15
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725132
Commit-Queue: John Delaney <johnidel@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682306}

separately."

This reverts commit 467d1d9d.

This change was reverted because of an issue with an earlier change
that this change depended on. There did not appear to be any issues
with this change; it just needs to be relanded.

> Original change's description:
> > Configure the insecure and secure parts of the async resolver
> > separately.
> >
> > We can now set the secure dns mode to AUTOMATIC and turn the
> > insecure part of the resolver off, which will result in the async
> > resolver issuing DoH requests and falling back to the system resolver
> > without attempting to send plaintext DNS requests itself.
> >
> > In a follow up cl, the secure dns mode part of the configuration
> > will be read from prefs. For now, we continue to set the mode to
> > AUTOMATIC if there are DoH servers specified and to OFF otherwise.
> >
> > Bug: 985589
> > Change-Id: Ia40cbae1fdd57e19e925e125dcf1e82289220242
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1709928
> > Commit-Queue: Katharine Daly <dalyk@google.com>
> > Reviewed-by: Tom Sepez <tsepez@chromium.org>
> > Reviewed-by: Eric Orth <ericorth@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#680161}

Bug: 985589
Change-Id: I207101bb03b385d08628002c2b463018e189223a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1717121Reviewed-by: Eric Orth <ericorth@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Katharine Daly <dalyk@google.com>
Cr-Commit-Position: refs/heads/master@{#682305}

Non-fast scrollable regions are regions on a cc::Layer where the
compositor should not handle scroll events. These are generated for:
1) Non-composited scrollable areas.
2) Resize controls.
3) Plugins that request wheel events.

These regions were previously computed in ScrollingCoordinator and
depended on compositing decisions made in a previous lifecycle stage.
This is not compatible with CompositeAfterPaint and needed to be
re-implemented to be independent of compositing decisions. In addition,
the previous implementation had a flaw where non-fast regions were only
stored on scrolling layers. This was incorrect if a non-scrolling layer
moved on the compositor, or in the presence of fixed-positioning.

This patch re-implements non-fast scrollable regions using the paint
system, similar to how touch-action rects are painted. This patch paints
non-fast regions for 1, leaving 2 and 3 for followups. The design is
outlined in [1] and [2] and has been implemented behind a flag.

Painting ScrollHitTestDisplayItems re-uses existing CompositeAfterPaint
code for painting scroll hit test display items.
PaintNonFastScrollableRegions uses these display items to mark non-fast
regions for non-composited scrollers. Though the CompositeAfterPaint
scroll hit test display item code is shared, there is a nuance in how
pre-CAP and CAP handle composited scrollers: pre-CAP only emits scroll
hit test items for composited scrollers (which is known at paint time),
whereas CAP emits them for all scrollers (compositing is not known at
paint time) and then later ignores the scroll hit test display items
that were for composited scrollers (this occurs in
PaintArtifactCompositor).

[1] design doc:
https://docs.google.com/document/d/1IyYJ6bVF7KZq96b_s5NrAzGtVoBXn_LQnya9y4yT3iw/view#heading=h.rrlzkp4v3huj

[2] documentation:
third_party/blink/renderer/core/paint/README.md

Bug: 864567, 817600
Change-Id: Ic24e2887404ff1ddb6481c014f5f4884ae1c924b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719404
Commit-Queue: Philip Rogers <pdr@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682304}

For very mysterious reasons, this only kind of works; peeking at the
systemwide notification which is sent (UAZoomFocusDidChangeNotification),
something often tells the system to go focus a seemingly random part of the
screen instead.

I've been unable to make headway on this, so sending CL on the principle
that "something is better than nothing." We can revisit later if we can
figure out why this is happening.

Comfortingly (?) the same thing happens to Safari web content so I'm going
to assume something is wonky with this system on the OS side.

Bug: 957395
Change-Id: I8356cff86795f19648ab6746d1f23fd5ea1a7025
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1713390Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682303}

QueueType::kWebScheduling was recently added for the scheduling API and these
task queues are per-frame. These task queues aren't used outside of unit tests
yet, so this DCHECK won't affect chrome builds, but it is failing locally
causing flakiness in scheduling API wpt tests.

This CL adds a separate IsPerFrameTaskQueue() method with a switch so adding
future QueueTypes cause a compile error if the test isn't updated.

Bug: 984057
Change-Id: If2ac727f63d26ae3998e8dddccbf39c9b680151e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1724896Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682302}

As of Xcode 11 beta 5, it appears iOS is now setting CERT_STATUS_WEAK_KEY
properly.

Bug: 977163
Change-Id: I8bc713eb8d20914410c1aa642932a4c615235ede
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725539Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682301}

Clean up. It's been enabled by default for awhile now.

Change-Id: Ice4ffc2d69aa8f17564293d9befe3dc3021244b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1725536
Auto-Submit: Bo <boliu@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#682300}