GitLab

Used to analyze traces uploaded via Slow Reports when draw intervals
above the 99th percentile threshold are detected.

Bug: 1055890
Change-Id: I64c97de8ffcd9d288f5c71a85bdd79789f704d66
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2083431Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Commit-Queue: Hailey Wang <haileywang@google.com>
Cr-Commit-Position: refs/heads/master@{#749348}

Before this patch, both "abort" and "can make payment" shared a
PaymentEventResultCallback type, which creates a lot of code churn when
only one of the event types needs an update.

This patch splits PaymentEventResultCallback into CanMakePaymentCallback
and AbortCallback.

After this patch, changing the parameters for "can make payment"
callback will be easier.

Bug: 1005076
Change-Id: I0df01a8a8b4551a16f1949d77ffd546df7ea5702
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2091646
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Sahel Sharify <sahel@chromium.org>
Auto-Submit: Rouslan Solomakhin <rouslan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749347}

This keeps the scope of changes in a new milestone directory to the
vars.star file.

Bug: 922150
Change-Id: I82a951a019f24d2795343b41f8c8785852f1e2cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098855Reviewed-by: Aaron Gable <agable@chromium.org>
Commit-Queue: Aaron Gable <agable@chromium.org>
Auto-Submit: Garrett Beaty <gbeaty@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749346}

We'll eventually go back to gbm_bo_map and hopefully get rid of the
ifdef statements.

BUG=b:145747350
TEST=CQ will test

Change-Id: I70f0c4f947886f32cc533cebbdf1649bb62c1e01
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2088796Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749345}

Also rename to reflect the fact that it is an interactive ui test, not
a browser test.

Bug: 1026426
Change-Id: I5754be8b906dac488c2ce739e19dd74e9a0ac2e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2097556
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: dpapad <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749344}

This CL introduces a SafeBrowsingTabHelper, which is a WebStatePolicyDecider
that makes a Safe Browsing query on each call to ShouldAllowRequest(). For
now, the result of the Safe Browsing query is ignored; the purpose of making
the Safe Browsing query is to exercise the Safe Browsing database code and
record UMA (being added in http://crrev.com/c/2087415) for database freshness.

This new behavior is behind the kSafeBrowsingAvailableOnIOS flag.

Bug: 1049340
Change-Id: I2844637fa9e3c0845fca6355ff1547b9d19252c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2092127
Commit-Queue: Ali Juma <ajuma@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org>
Reviewed-by: Varun Khaneja <vakh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749343}

Bug: 812428
Change-Id: Idb20a957d712b8a1c1faf259fc0fe2d9559005e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098768
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Commit-Queue: John Budorick <jbudorick@chromium.org>
Auto-Submit: Ben Pastene <bpastene@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749342}

https://webrtc.googlesource.com/src.git/+log/8f47b27268ea..6c08e4b57d48

git log 8f47b27268ea..6c08e4b57d48 --date=short --first-parent --format='%ad %ae %s'
2020-03-11 marinaciocea@webrtc.org Remove deprecated RtpVideoStreamReceiver constructor.
2020-03-11 danilchap@webrtc.org Cleanup RtcpReceiver tests
2020-03-11 terelius@webrtc.org Scale unacked_data consistently in RobustThroughputEstimator
2020-03-11 mbonadei@webrtc.org Revert "Reland "Whitespace change to kick bots.""
2020-03-11 mbonadei@webrtc.org Reland "Whitespace change to kick bots."

Created with:
  gclient setdep -r src/third_party/webrtc@6c08e4b57d48

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/webrtc-chromium-autoroll
Please CC webrtc-chromium-sheriffs-robots@google.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

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

Bug: None
Tbr: webrtc-chromium-sheriffs-robots@google.com
Change-Id: If77e55490b9085f777cdb30e0bbd452e6b607dd5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2097840Reviewed-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@{#749341}

After http://cl/299870071, it is possible for CryptAuth to send device
metadata packets with empty |encrypted_metadata|. This can happen if a
device has not uploaded its metadata encrypted with the correct group
public key. Note: We still always expect nontrivial encrypted metadata
for the local device.

Bug: 951969
Change-Id: If18ddf4bc20559be47a7bf9382ab4fb8fcdd6d16
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2097240
Auto-Submit: Josh Nohle <nohle@chromium.org>
Commit-Queue: James Vecore <vecore@google.com>
Reviewed-by: James Vecore <vecore@google.com>
Cr-Commit-Position: refs/heads/master@{#749340}

Bug: b/149422033
Merge-With: eureka-internal/365398
Change-Id: I67f3440efcfde831f025e57bd92c40d41051077a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2063533Reviewed-by: Yuchen Liu <yucliu@chromium.org>
Commit-Queue: Alex Leung <alexleung@google.com>
Cr-Commit-Position: refs/heads/master@{#749339}

BUG=1052765

Change-Id: I85abe058fa355c8ac08c928d4938e2be86a4b239
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098902Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#749338}

This unittest started failing soon after landing.
Disabling for now.

stdout:
Crashed during OverlayPresentationContextImplTest.ContainedOverlayUI

TBR=kkhorimoto@chromium.org

Bug: 1060758
Change-Id: Idf593a9b3ae9858a11610fb07d6036baf7e42496
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2099083Reviewed-by: edchin <edchin@chromium.org>
Commit-Queue: edchin <edchin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749337}

This CL fixes an issue where source device changes mid gesture scroll.
For example, when user initiates a mousewheel scroll, a GSB and a GSU
are dispatched. Before the GSE for mousewheel is dispatched, lets say
the user initiates a scrollbar scroll. At this point, a new set of
GSB and GSU are dispatched. While the scrollbar scroll is in progress,
the deferred GSE from the mousewheel will arrive and end up clearing
the scroll and current device (i.e scrollbar) would no longer be able
to scroll. To fix this, we maintain state in the InputHandlerProxy
that tells which source device is currently in charge of scrolling. If
a GSE for a device, other than the one in charge, is dispatched, it is
dropped. This state is maintained in currently_active_gesture_device_.
It is set on DID_HANDLE or DID_HANDLE_SHOULD_BUBBLE (for cases where a
scroll doesn't occur and the event needs to be bubbled) for GSB/GPB and
cleared on GPE/GSE.

Bug: 1055237, 1060157
Change-Id: Ib42637d33efbdc0cef5e957e095b3015eb5ec2c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2068743
Commit-Queue: Rahul Arakeri <arakeri@microsoft.com>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749336}

With ios13-beta-sim running Chromium, this file is no longer needed.
MB in its current state will check this file for the GN args, which
is undesired. We want it to grab the arguments from the already
migrated mb_config.pyl.

Downstream has its own definitions for ios13-beta-sim under the
internal master groups and are unaffected.

Bug: 1055164
Change-Id: I9a995aa9dcc33f6d2f419438c25ef4c7a5bc2f5a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2096881
Commit-Queue: Jeff Yoon <jeffyoon@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749335}

https://skia.googlesource.com/skia.git/+log/6dc0f63a509c..dafbf121a8b1

git log 6dc0f63a509c..dafbf121a8b1 --date=short --first-parent --format='%ad %ae %s'
2020-03-11 brianosman@google.com SkVertices: Remove volatile/nonvolatile bit

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

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/skia-autoroll
Please CC brianosman@google.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

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

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
Bug: None
Tbr: brianosman@google.com
Change-Id: Ibadda86f25aa77f8d6790c9f4a9cc92d86522283
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2097830Reviewed-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@{#749334}

crrev.com/c/2066840 made it impossible to create a Chrome profile
outside of the user data directory. Unfortunately, some sync tests
rely on this to be able to test two profiles syncing to the same
account.

This CL adds a command line flag --allow-profiles-outside-user-dir
that restores previous behaviour. This flag should be only used as a
workaround to fix the sync tests before we have more robust solution.

Bug: 1060366
Change-Id: I864a32d5e5d06b029bab1233b33fbb80d27ea137
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2096769
Commit-Queue: Alex Ilin <alexilin@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749333}

This is a reland of 00134099

Original change's description:
> Passing audio capture timestamp to WebRTC.
> 
> Bug: 1054403
> Change-Id: I6349687ce55535a0cdc405db67687d967a04fea1
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2066777
> Commit-Queue: Minyue Li <minyue@chromium.org>
> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
> Reviewed-by: Guido Urdaneta <guidou@chromium.org>
> Reviewed-by: Henrik Andreasson <henrika@chromium.org>
> Reviewed-by: Yuri Wiitala <miu@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#749126}

Bug: 1054403
Change-Id: Icf0af14fd91f2390c933d4b97b8cdbe06dc34ada
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2093446Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Minyue Li <minyue@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749332}

Add the WebAuthenticationCrosPlatformAuthenticator feature flag (default
disabled). If enabled, it will cause the FidoChromeOSDiscovery to be
instantiated for MakeCredential and GetAssertion requests that permit
the 'internal' transport.

Also move ChromeOS code up into the device namespace like most of the
other fido-related code. Its naming is sufficiently unique.

Bug: b/144861739
Change-Id: I50bf39c5c7841a7358840968d10a568c6f22ae6d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2088535
Commit-Queue: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: Adam Langley <agl@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749331}

In preparation for removing the N betty bots.

Bug: b/150926708
Change-Id: I2c98c09cfff229393b55bae6b916b5b0b81eea1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098843
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Commit-Queue: John Budorick <jbudorick@chromium.org>
Auto-Submit: Ben Pastene <bpastene@chromium.org>
Reviewed-by: John Budorick <jbudorick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749330}

Not a future-proof fix, but at least unbreaks it for now by adding
libcrashpad_handler_trampoline.so to the ignored list.

Crash looks like:
Dumping static initializers via dump-static-initializers.py:
Traceback (most recent call last):
  File "../../build/android/gyp/assert_static_initializers.py", line 174, in <module>
    main()
  File "../../build/android/gyp/assert_static_initializers.py", line 159, in main
    ignored_libs, no_initializers_libs)
  File "../../build/android/gyp/assert_static_initializers.py", line 125, in _AnalyzeStaticInitializers
    _PrintDumpSIsCount(f.filename, temp.name, out_dir, tool_prefix)
  File "../../build/android/gyp/assert_static_initializers.py", line 55, in _PrintDumpSIsCount
    so_with_symbols_path)
Exception: ('Unstripped .so not found. Looked here: %s', './lib.unstripped/libcrashpad_handler_trampoline.so')

Bug: 939207
Change-Id: I3cf6b9ba52d80a789ec5bcd3b8e1943e0a578a3a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098773
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Commit-Queue: Peter Wen <wnwen@chromium.org>
Auto-Submit: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Peter Wen <wnwen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749329}

This CL updates the Trust Tokens store to handle a few requirements for
token issuance:
1. Allow adding tokens to fail if there is no stored key commitment for
the tokens' issuer with value equal to that of the tokens' associated
key.  (Previously, this was DCHECKED as a precondition, but it's easier
to handle within the store.)
2. Add a capacity limiting the number of tokens stored per issuer, and
make TrustTokenStore::AddTokens respect this capacity.
3. Add a number-of-tokens-for-issuer getter so clients can check (for
instance) if tokens are at capacity without attempting to add a token.
4. Add a cap on the number of issuers allowed to be associated with any
given top level origin, and make TrustTokenStore::SetAssociated respect
this limit.

Bug: 1042962
Test: Expand unittests.
Change-Id: I544aa64eeeab1a1f6c777631f1579d2402fd179e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2057523Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Commit-Queue: David Van Cleve <davidvc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749328}

This is a partial reland of https://crrev.com/c/chromium/src/+/2062692.
We confirmed that the CL affected startup metrics on Mac. However, our
assessment is that the change is correct (restored tabs are painted
before non-restored tabs more often). As a precaution, the
original CL is split in two:
- Start loading restored tabs earlier (this CL)
- Enforce stricter requirements in FirstWebContentsProfiler (http://crrev.com/c/chromium/src/+/2097368)

Original change description:

On Windows, a visible restored tab starts loading in the following stack,
before FirstWebContentsProfiler is created:

  content::NavigationControllerImpl::LoadIfNecessary
  content::NavigationControllerImpl::SetActive
  ...
  content::WebContentsImpl::UpdateWebContentsVisibility
  content::WebContentsViewAura::UpdateWebContentsVisibility
  ...
  BrowserView::Show
  SessionRestoreImpl::ShowBrowser
  SessionRestoreImpl::RestoreTab
  SessionRestoreImpl::RestoreTabsToBrowser
  SessionRestoreImpl::ProcessSessionWindows
  SessionRestoreImpl::ProcessSessionWindowsAndNotify
  SessionRestoreImpl::Restore
  SessionRestore::RestoreSession
  ...
  StartupBrowserCreator::Start
  ...
  content::BrowserMainLoop::PreMainMessageLoopRun

On Mac, it starts loading in the following stack, after
FirstWebContentsProfiler is created:

  content::NavigationControllerImpl::LoadIfNecessary
  content::NavigationControllerImpl::SetActive
  ...
  content::WebContentsImpl::UpdateWebContentsVisibility
  content::WebContentsViewMac::OnWindowVisibilityChanged
  -[WebContentsViewCocoa updateWebContentsVisibility]
  -[WebContentsViewCocoa windowChangedOcclusionState:]
  ...
  base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run
  ...
  ChromeBrowserMainParts::MainMessageLoopRun

This prevents FirstWebContentsProfiler from having strict cross-platform
expectations about events it observes. With this CL, we ensure that visible
restored tab start loading in the following stack on all platforms:

  content::NavigationControllerImpl::LoadIfNecessary
  chrome::`anonymous namespace'::CreateRestoredTab
  chrome::AddRestoredTab
  ...
  SessionRestoreImpl::Restore
  SessionRestore::RestoreSession
  ...
  StartupBrowserCreator::Start
  ...
  content::BrowserMainLoop::PreMainMessageLoopRun

This allows us to enforce strict cross-platform expectations about events
observed by FirstWebContentsProfiler, and also have the nice benefits that
navigation isn't delayed until we get a window visibility update during a
Mac session restore.

Bug: 1035419, 1020549, 1022492
Change-Id: I2964de553c0195ba94a35dc41d17c4a28cc5d05d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2095970
Commit-Queue: François Doray <fdoray@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749327}

What's New (from: https://github.com/google/bundletool/releases):
- Skip dex merging in universal APK for devices that have multidex support
- Support for keeping resources with given names in the master split.

Bug: 1027124, 1033098
Change-Id: I19964fc25fe4db60b77b4e7901afcf5d53020c38
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098842Reviewed-by: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Peter Wen <wnwen@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Auto-Submit: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749326}

As per CL 1176109, removing similar sentence with broken link from
documentation

Change-Id: I62eaf44824b86e0a37374201fa2667b351bb383a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2095140
Auto-Submit: Joshua Berenhaus <joshber@microsoft.com>
Commit-Queue: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749325}

When launching into an incognito tab initially, the status view wouldn't
be initialized, and absent a search engine change, would never
be initialized ever again. This caused populateFadeAnimations to hide
everything in the location bar by accident, since the first visible
focused view was null.

We should always initialize mStatusView if the search engine logo
feature is enabled, and it is safe to do so; there guards against using
its padding etc. when not actually showing the logo.

Bug: 1060503
Change-Id: Id43b667082b3016b11105d7fcfb4594c24a63ede
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098266
Commit-Queue: Patrick Noland <pnoland@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749324}

Summary of changes available at:
https://chromium.googlesource.com/v8/v8/+log/83b2817d..506142ad

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: Ib0529faf9965cd530b1c9d77ab70c4a72588dd31
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098404Reviewed-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@{#749323}

This is clearer and generates more efficient code (a compile-time
constant with nothing else).

Change-Id: I8dfab291aa1c9213410fe8f778f0ce06e84745d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098844
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Auto-Submit: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749322}

This CL adds chrome://flags/#cors-for-content-scripts to make it easier
for end users to control the CorbAllowlistAlsoAppliesToOorCors feature.

Bug: 920638
Change-Id: I1f812edf23f4395af9a719a7a3203896c571e677
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098258Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749321}

This CL simplifies the enabling logic for grid and group because low-end
and accessibility is supported for GTS with the TabGroup M5 flag.

Change-Id: I0b49f25526252275dc914e6631360e0b45495ff6
Bug: 1019489
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2092186Reviewed-by: Theresa  <twellington@chromium.org>
Reviewed-by: Wei-Yin Chen (陳威尹) <wychen@chromium.org>
Reviewed-by: Xi Han <hanxi@chromium.org>
Commit-Queue: Mei Liang <meiliang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749320}

This CL extends the scrollable shelf information from test api by
including the boolean value which indicates whether scrollable shelf
is in overflow mode.

Bug: 1058590
Change-Id: I46d384a46f4c71f32cd321cbfab2f7304feb462a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098333Reviewed-by: Toni Baržić <tbarzic@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Andrew Xu <andrewxu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749319}

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/fuchsia-sdk-chromium-autoroll
Please CC cr-fuchsia+bot@chromium.org on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

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

Cq-Include-Trybots: luci.chromium.try:fuchsia-arm64-cast;luci.chromium.try:fuchsia-x64-cast
Tbr: cr-fuchsia+bot@chromium.org
Change-Id: Ib10b79fa95348b06509df437a89df0716d91fa36
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2098922Reviewed-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@{#749318}

The underlying ARCore runtime requires camera access in order to
function. https://crrev.com/c/2072667 caused AR to prompt for OS/App
level camera access; however, this only happens if the user is shown the
permission prompt and grants the site access to the AR permission. If
the camera permission is denied either as a result of this prompt, or
revoked through the settings UI later, it is not checked again.

This adds a step to the site permissions request flow that ensures that
appropriate OS permissions are set. This mimics the flow that
MediaStreamDevicesController does, but puts the logic into the
permissions context class like GeolocationPermissionContextAndroid. If
indicated (via the persist bool), whatever permission is determined for
AR for the requesting origin permission will be saved, but the end
result bubbled back to whoever requested the permission will indicate
that the permission was granted iff both the site was granted permission
for AR and Chrome itself has permission to use the camera from the OS.

Bug: 1058058
Change-Id: I6f2d74d146de03998b59992a70c94d6c04dabbe6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2087704
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Klaus Weidner <klausw@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749317}

This is a followup to https://crrev.com/c/2090981 to implement the
corresponding functionality for associated endpoints.

Miscellaneous fixes:
- add aliases for {{MojoInterface}}InterfaceBase in blink::mojom::blink
  to satisfy Blink's audit_non_blink_usage.py checker
- remove unused ctors from CrossVariantPendingMojo{Remote,Receiver}


Bug: 1059157
Change-Id: I34b07727f1d02936f29ea796c43ad5458df29dc1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2094708
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749316}

Move About Chrome Settings to org.chromium.chrome.browser.about_settings
package.

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

Also renaming related functions and variables.
Making wording more inclusive.

Bug: 842296
Change-Id: If1121d2496c151a87ecb9a517633195d8e851a7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2095841Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Marc Treib <treib@chromium.org>
Reviewed-by: ssid <ssid@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Eugene Zemtsov <eugene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749314}

When trying to compute the next or previous AXObject on the same line, and when not using LayoutNG,
and when an AXLayoutObject is associated with an inline layout object which doesn't have any of its siblings
on the same line, we need to recursively look at the parent AXLayoutObjects.
However, before doing that we should ensure that the current AXLayoutObject is either the first or the last child
because any of our ancestors may span multiple lines.
Also, we should ensure that if "culled inline" is in effect, we will still walk the inline line boxes.

In addition, This patch fixes an issue with associating a list marker with
its list item via a next/previousOnLine relationship, when
the list item doesn't have any visible text, but only accessible text, e.g. an aria-label.

Example HTML snippet:
<div contenteditable="true">
  This is a
  <a href="example.com">
    link
    <span style="outline-style: solid">
      test with a
      <br>
      second line.
    </span>
  </a>
</div>

Observed issue:
All the contents of the contenteditable will appear to be on a single line.

Cause:
Chromium's renderer uses line boxes to represent each line.
There were two mistaken assumptions in AXLayoutObject:
1. Assuming that line boxes are always created.
Line boxes are not always created for every inline element; an optimization known
as "culled inline".
Only if the element has margin, decoration, padding, and outline, will
line boxes be created.
2. Assuming that if a node in the accessibility tree has no other nodes either before or after it
on a given line, then we should always look for such nodes in the siblings of its
parent object. However, this won't work if the parent node represents an inline element,
because that element can span multiple lines.
For example, a span on the first line will be marked as being on the same line as
a text node on the second line, if there is a second span that
starts on the first line but finishes on the second line, and which contains
the text node.

R=aleventhal@chromium.org, dmazzoni@chromium.org, kbabbitt@microsoft.com

Change-Id: I8815eeed629de0949fce598e9443163045ff7570
Bug: 1059612
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2090102Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Kevin Babbitt <kbabbitt@microsoft.com>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749313}

TBR=govind@chromium.org

Change-Id: I4c932d6c1be5444888c68bc28f77c91ce8ad3c6e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2097831Reviewed-by: Ben Mason <benmason@chromium.org>
Reviewed-by: Krishna Govind <govind@chromium.org>
Commit-Queue: Krishna Govind <govind@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749312}

Calling the RemoveBeforeLoadJavaScript() function on a Frame that has
already disconnected is benign, but triggers warning logspam, so handle
the case of deletion after Frame disconnection gracefully.

Bug: b/150973463
Change-Id: Ia029a561221bf05d1f8500a5a502e6c06841e07b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2095725
Auto-Submit: Wez <wez@chromium.org>
Commit-Queue: Kevin Marshall <kmarshall@chromium.org>
Reviewed-by: Kevin Marshall <kmarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749311}

Bug: 993790
Change-Id: If6f276c619eaf684e078aba582cb272913b2634b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2071909
Commit-Queue: Charlie Hu <chenleihu@google.com>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749310}

SettingsPageBrowsertest added another layer of test classes that was
not used by the SettingsUIBrowserTest and was partially intentionally
overridden in the AboutPageBrowsertest.

Remove this class and move the only 2 shared functions to a new file
that provides them as test_utils, and move other behavior/functions to
AdvancedPageBrowsertest, which is the only test that uses them.

Also re-enabling SettingsUIBrowsertest by changing the browsePreload
to only load settings_ui.html, and by removing the
SettingsPageBrowsertest setup, which may have been causing the
flakiness.

Bug: 1026426, 986985
Change-Id: I8e51cd9f1926bf35b9b12ad15213bd7b816b60a8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2095864
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: dpapad <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#749309}