GitLab

Bug: 985914
Change-Id: I8ce9a771eb591cd7eadb93d94af2caa5f6af0e66
TBR: dcheng@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719444
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681325}

Parent access dialog should show correct title after the error is
cleared. The title should be the same as before showing the error and
it should match the reason that access code is requested for.

Bug: 987792
Test: manually
Change-Id: I4ec9a36ee22cfebae85875bbc3f2fb27d601c16d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719810Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Henrique Grandinetti <hgrandinetti@chromium.org>
Commit-Queue: Aga Wronska <agawronska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681324}

This CL:
- Avoids finishing the WebAPK on Android O+ (the behaviour on pre-O is
  different) when:
  1) The user selects the WebAPK from Android Recents
  2) The WebAPK was killed by the Android OS OOM killer
- Avoids finishing the WebAPK if the WebAPK was selected from Android
  recents and the host browser was uninstalled

BUG=978716
TEST=SplashActivityTest.*

Change-Id: I55927310afc99fa8565ea02533321d6bdcab536f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1677687Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Reviewed-by: Pavel Shmakov <pshmakov@chromium.org>
Commit-Queue: Yaron Friedman <yfriedman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681323}

In draw_utils/coordinates_unittest.cc, pp::Rect and pp::Size objects
are compared to expected values frequently.

This CL adds helper functions CompareRect() and CompareSize() to
compare pp::Rect and pp::Size objects, respectively, simplifying
the file.

Change-Id: I3ff8235a90860a3c8343b18730e5ad1e69b0ba1d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719329Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Jeremy Chinsen <chinsenj@google.com>
Cr-Commit-Position: refs/heads/master@{#681322}

Bug: 819294
Change-Id: Ie1530f7046b0c8eb76e26adca530fa57c67ed876
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1720637Reviewed-by: Ella Ge <eirage@chromium.org>
Commit-Queue: José Dapena Paz <jose.dapena@lge.com>
Cr-Commit-Position: refs/heads/master@{#681321}

In addition to remove linux-xenial, I did followings in this CL
* change "linux" -> "linux-trusty"
* have "linux-xenial" instead of "linux" in some mixins
* use "linux-trusty" for
  * linux-trusty-rel CQ/CI builder
  * linux_upload_clang CQ builder
  * WebRTC Chromium Linux Tester CI builder

I confirmed that w/ and w/o this CL generates the same flattened config
with flatten_buildbucket_cfg.

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

Bug: 971514
Change-Id: I48f5e7945690876b5d997f9f40ede57bc9f0637d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1716933Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Sinan Sahin <sinansahin@google.com>
Cr-Commit-Position: refs/heads/master@{#681319}

Revert "CrOS: Adding new SearchResult flags to dinner for one to allow for future-proof placement of it and other future policy tile apps."

This reverts commit 1c673235.

Reason for revert: Causes issue 987723

Original change's description:
> CrOS: Adding new SearchResult flags to dinner for one to allow for future-proof placement of it and other future policy tile apps.
>
> Bug: 981023
> Change-Id: I06933a73ffafa91c8388d0325c008d2bd8e436e3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1687296
> Commit-Queue: Cameron Womack <camw@google.com>
> Reviewed-by: Yury Khmel <khmel@chromium.org>
> Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
> Reviewed-by: Alex Newcomer <newcomer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#677966}

TBR=oshima@chromium.org,khmel@chromium.org,newcomer@chromium.org,camw@google.com

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

Bug: 981023
Change-Id: Ia3e2a571df3050ead665e7184fb128508f244b67
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1721013Reviewed-by: Alex Newcomer <newcomer@chromium.org>
Reviewed-by: Yury Khmel <khmel@chromium.org>
Commit-Queue: Alex Newcomer <newcomer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681318}

To composite color values cross thread, we must have a specific
CrossThreadColorValue, and the only way to know if a CSSStyleValue holds
a color value is to create a new color specific style value.  This patch
adds a new class CSSColorStyleValue for this purpose.

Bug: 883721
Change-Id: I83472ffd26bf2eba3312b8578e81222f61bd17c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1717189
Commit-Queue: Adam Raine <asraine@google.com>
Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org>
Reviewed-by: Xida Chen <xidachen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681317}

This change adapts media::VideoFrame to the new shared memory API [1].

media::VideoFrame::WrapExternalSharedMemory wraps shared memory in
several contexts: sometimes from a shared memory object directly,
and sometimes indirected through a
VideoCaptureDevice::HandleProvider. The VideoFrame is also created
with a pointers to mapped memory, and treats the shared memory
handle mostly as an opaque blob, sometimes duplicating for passing
across processes, or passing it to wrap it in another
VideoFrame. This latter wrapping also complicates ownership, as it
implies that the shared memory must be owned externally. Because of
this, the ownership of this kind of handle is external to the
VideoFrame.

The shared memory backing this use of VideoFrame is sometimes claimed
to be read-only, and sometimes writable ("unsafe" in the jargon of the
current shared memory API). This has lead to bugs (crbug.com/797470
and crbug.com/888153). While there may be a way to refactor so that
read-only shared memory can be used where appropriate, that is beyond
the scope of this CL. Here we just make the unsafe shared memory usage
explicit, and clean up the API in a way that will hopefully make it
easier to extend in the future.

The core goal of this CL is to refactor VideoFrame to remove use of
the legacy shared memory API, which forces permissions and ownership
to be explicit. This CL does not change use of the mojo
SharedBufferHandle API, which is strongly owned but hides region
permissions (although they are strongly checked). A summary of the
change is as follows.

 (1) VideoFrames are explicit about being backed by unsafe shared
     memory, and VideoFrame creation is cleaned up. Previously, data
     backed by shared memory was created with a
     WrapExternalSharedMemory factory, except in some cases where the
     frame was created with a different kind of external memory (eg,
     WrapExternalYuvData) and then a shared memory handle was shoved
     in with AddSharedMemoryHandle. After this CL, a VideoFrame backed
     by shared memory is first created with the appropriate
     WrapExternal* call, and then explicitly backed with unsafe shared
     memory. This makes current usage clear and will allow for
     different kinds of shared memory (read-only, writable) to be used
     in the future expressed without causing a combinatorial explosion
     of factory methods or parameters.

 (2) Changing the VideoFrame creation API implies changing consumers
     to use the new shared memory API and to be explicit about
     shared memory permissions.

 (3) Remove media::SharedMemoryHandleProvider (an implementation of
     VideoCaptureDevice::Buffer::HandleProvider). This class
     effectively confused uses of read-only and writable regions,
     and practically was used mostly as a utility routine for
     converting different types of buffer handles.

 (4) Additional cleanup in code that managed shared memory regions,
     particularly those that duplicate regions, which now the new
     permissions used by VideoFrame. TODOs which noted that regions
     were being duplicated read-write when they should be duplicated
     read-only are addressed: in some cases, the regions can now be
     duplicated read-only; in other cases the comment was incorrect
     and the region in question must be duplicated writable. In these
     cases an attempt has been made to document the use cases that
     demand a writable handle. Affected classes that manage shared
     memory regions are:
      * VideoCaptureBufferPool
      * VideoCaptureBufferTracker / SharedMemoryBufferTracker

Unfortunately, the nature of these changes makes it impossible to break
this change into small pieces. In particular, the shared memory permissions
are all inter-dependent, and the strong checking done by the new shared API
as well as mojo::ScopedSharedBufferHandle make it impossible to update
usage piecemeal.

A future change could add read-only shared memory to a video frame,
and use that for the encoder input buffer, which in theory only needs
read-only access. However, in current practice that is not the
case:

(a) crbug.com/888153 shows that some hardware encoders require
writable shared memory regions.

(b) ExternalVideoEncoder passes unsafe regions as the input frame, taken
via a CreateVideoEncodeMemoryCallback from a legacy
SharedMemoryHandle. The callback is also used to create output regions
(which must be writable). Fixing this inconsistency requires a larger
refactoring, also because CreateVideoEncodeMemoryCallbacks are passed
around in other cases.

(c) GpuArcVideoEncodeAccelerator takes a raw handle to
create an input frame for VEA::Encode. This is not a read-only
region. ArcVideoEncoder is in Android branches for ChromeOS (called
pi-arc-dev and arc-nyc-mr1). The file descriptor today is writable because
we copy plane data to the fd on the Android side for various reasons
(conversion, etc).

[1] https://docs.google.com/document/d/1lk2-7W7Cy7FDqG-6lgS8LRkzXABYTOytf6VUsWNf8-0/edit#heading=h.7nki9mck5t64

Bug: 888829, 849207, 843117, 795291, 803136, 793446
Change-Id: I776902f1b82c0b96e9916bcd59afdf4b3df89a91
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1680188Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Tommi <tommi@chromium.org>
Reviewed-by: Christian Fremerey <chfremer@chromium.org>
Reviewed-by: Yuri Wiitala <miu@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Cary (CET) <mattcary@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681316}

This change marks the following RPCs with enough information to figure
out whether they've been triggered by direct actions:

When SupportsSite is called from a Chrome CCT created for AA, this
change sets ClientContext.is_cct.

When a script is run by using a direct action, instead of the UI,
this change sets ClientContext.direct_action

The two are necessary, as it is possible to use direct actions on a AA
started by CCT. It is possible to use the UI to answer prompts triggered
by a script run by a direct action.

Additionally, when a prompt choice is made by using a direct action,
instead of the UI, this change sets ProcessedActionResut.direct_action

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

MessageLoop will go away, eventually.

ScopedTaskEnvironment will per default start a ThreadPool, which should
be fine in most of the cases. If you belive your test needs to make sure
that no ThreadPool runs let me know and I will update the patch.

BUG=891670
This CL was uploaded by git cl split.

R=wychen@chromium.org

Change-Id: Iec9eda1a1ec8fa5412704dc41be9f486a1f68f05
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1649581
Auto-Submit: Carlos Caballero <carlscab@google.com>
Reviewed-by: Wei-Yin Chen (陳威尹) <wychen@chromium.org>
Commit-Queue: Carlos Caballero <carlscab@google.com>
Cr-Commit-Position: refs/heads/master@{#681314}

It was kept to keep downstream intact, now can be deleted

Bug: 916542
Change-Id: I400c2dec8f4d9eba053e85701f4eb726c97107e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1718964
Auto-Submit: Pavel Shmakov <pshmakov@chromium.org>
Commit-Queue: Peter Conn <peconn@chromium.org>
Reviewed-by: Peter Conn <peconn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681313}

An element is added to the set if a child is removed in order to force
an update of whitespace siblings. Removing a child doesn't cause a
style recalc or layout tree rebuild, but removing an inline element
between say two whitespace nodes makes one of the whitespace LayoutTexts
unnecessary. We keep this set until the next lifecycle update and marks
the elements in the set for layout tree rebuild to reach the whitespace
children. We skip these nodes if the layout object had been detached in
the meantime.

What happens here, however is that we didn't remove the elements from
the set when the elements were removed from the document. In this case
it is even adopted into a different document and gets a new layout
object in that document's layout tree.

When the original document gets its lifecycle update, we try to rebuild
the layout tree of the element which is now in a different document and
DCHECKs fail for style dirtiness.

Bug: 981384
Change-Id: I26fe3a8ac2c6b8994e6d4ad9593a8476422a0535
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719345Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org>
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681312}

Bug: 910319
Change-Id: Ic9a9fa2be934d95aee31a7f1440890d6a9fa2697
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1717694
Commit-Queue: Sam Maier <smaier@chromium.org>
Auto-Submit: Sam Maier <smaier@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681311}

Bug: 987965
Change-Id: I29b50b988983b2ec8ef976370a576af426dedbbe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1720833Reviewed-by: Lowell Manners <lowell@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681310}

These metrics have been useful from time-to-time over the years to
answer questions about how users zoom; most recently in the last 2
weeks.

Bug: 975221
Change-Id: If9e251c0e4396b5914e2e9a3d322f1fc6cfe0476
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1678380Reviewed-by: Steven Holte <holte@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Auto-Submit: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681309}

https://chrome-internal.googlesource.com/chrome/src-internal.git/+log/424fc331f3be..9a69857888af


Created with:
  gclient setdep -r src-internal@9a69857888af

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

Bug: 986380
Change-Id: Ib4ed402900f28036d94bb36d8660f895f44fcc6e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1715666Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org>
Commit-Queue: Yann Dago <ydago@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681307}

This change adds UMA tracking for SMSReceiver API to give us data on friction
and performance of UI decisions made for this feature. Because there was some
disagreement between adding the user interaction after a successful call, this
will give us a better idea of what kind of impact the UI has or doesn't have.
Specifically it will track the following.

1. Duration between the time a SMS is successfully received and when the user
   selects Continue.

2. Duration between the time a SMS is successfully received and when the user
   selects Cancel.

More details on metrics and its motivation here in the API Design Doc [1].

[1] https://docs.google.com/document/d/1dB5UM9x8Ap2-bs6Xn0KnbC_B1KNLIUv4W05MunuXYh0/edit#heading=h.bbporvvwzoo7


Bug: 976332
Change-Id: Id689c9937c17a9dc930cce89ba0965e8f20a96d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1716961Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Jun Cai <juncai@chromium.org>
Commit-Queue: Ayu Ishii <ayui@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681306}

Sometimes the doodle height on the NTP is changing. If this is occurring
while the omnibox is focused, the stored offset of the collection view
is too big and upon unfocusing the omnibox the NTP is too much scrolled.

Bug: 986763
Change-Id: Ia2c641f547f6bb8780143f4edf5a94f09b9bc5bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1720814
Auto-Submit: Gauthier Ambard <gambard@chromium.org>
Commit-Queue: Yi Su <mrsuyi@chromium.org>
Reviewed-by: Yi Su <mrsuyi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681305}

Two WPT autorolls and no joy on their expectations. Mark these tests a
Pass Failure on all bots to green the chromium tree webkit tests.

No-try: true
No-presubmit: true
Bug: 987915
Change-Id: If7c28237cdd7a10d48d058da864279332308edeb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1720840Reviewed-by: Friedrich [CET] <fhorschig@chromium.org>
Reviewed-by: Noel Gordon <noel@chromium.org>
Commit-Queue: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681304}

Current, we assume that |ShouldWalkCheck| wouldn't change during the
lifetime of |ScopedPaintTimingDetectorBlockPaintHook|. It turns out
that it can, for unknown reason. A temporary fix is to redo
|ShouldWalkCheck| at the close of the scoped hook.

Bug: 983860

Change-Id: I524a1a6281107ac87fc5a517009cd93be7426574
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719448Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Liquan (Max) Gu <maxlg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681303}

* Ensures omnibox popup shortcuts egtests compat with EG2
* Adds a new EG2 target and adds shortcuts tests to ios_chrome_eg2tests
* Cleans up shortcut egtest deps

Bug: 866147
Change-Id: I3c004889b230e7590a62d5f4ab062cb6103456f8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1698420
Commit-Queue: Stepan Khapugin <stkhapugin@chromium.org>
Auto-Submit: Stepan Khapugin <stkhapugin@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681302}

We see autofill tests take between 30 and 30000 milliseconds and
that is probably disk I/O. Switching to a memory database makes
the tests much faster, though it's unclear what the cause of the
30 second tests is.

Change-Id: Ie4a7d331f6b2dead3649e406a039ea68ce188990
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1718325Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Reviewed-by: Dominic Battré <battre@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Auto-Submit: Daniel Bratell <bratell@opera.com>
Cr-Commit-Position: refs/heads/master@{#681301}

Snapshots are normally captures in MainController's
|-prepareTabSwitcher|.  When links are opened via the context menu in
a different ApplicationMode, it is opened without entering the tab
switcher and the snapshot for the previous WebState might be stale.

Bug: 978400
Change-Id: Ifaf1b5dec80e2a139cdbe3a0f34ae51f3fae54c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1716039
Auto-Submit: Kurt Horimoto <kkhorimoto@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Commit-Queue: Kurt Horimoto <kkhorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681300}

On Android, input events are delivered asynchronously. Because of that,
onClick listeners may be invoked after the fragment has been removed or
Chrome has been backgrounded. When Chrome is backgrounded, any fragment
transactions will fail to avoid state loss. This CL adds checks to bail
out early from click listeners if the parent fragment isn't resumed or
the state has already been saved. Also, calls to commit and dismiss are
replaced with commitAllowingStateLoss and dismissAllowingStateLoss.

Bug: 987884
Change-Id: I96494eaf0370934f2c502cfd5e768c6e8ec30c08
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1718951
Commit-Queue: Theresa <twellington@chromium.org>
Auto-Submit: Boris Sazonov <bsazonov@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681299}

permission_types.h should own the helper method used for generating a
vector of all PermissionTypes. This is done dynamically to reduce
the burden of updating this list. It is stored in a static container
so that it can be lazily generated as needed. Additionally, use of
dynamic memory guarantees uncomplicated destruction while static
storage does not consider this a "leak".

Bug: 986605
Change-Id: I7bcaafe9cf94d31a3ae796c97f754da643e3c572
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1716946Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Reviewed-by: Caleb Rouleau <crouleau@chromium.org>
Commit-Queue: Rohan Pavone <rohpavone@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681298}

This CL creates a new virtual suite that runs web tests with the audio
service running on a sandboxed utility process.
It also adds expectations for audio-related tests already in expectations
files.

Bug: 976696
Change-Id: Ia25ff740fb4735db0d3ae4ea9d08787e6818da5b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1715811
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Armando Miraglia <armax@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681297}

Early conversion to double resulted in DocumentTimeline returning a
different value than the requestAnimationFrame timestamp. By preserving
the full precision time delta we can use the exact same conversion as
the requestAnimationFrame timestamp.

Bug: 986974
Change-Id: I508330a168bf6523b1ec3912efb24159b876f6e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719853
Commit-Queue: Robert Flack <flackr@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681296}

This reverts commit 69b9b238.

Reason for revert: https://chromium-review.googlesource.com/c/chromium/src/+/1719859 depends on this cl.

Original change's description:
> Implement GetCurrentFramebufferDamage().
> 
> GLOutputSurfaceBufferQueue::GetCurrentFramebufferDamage() didn't get
> implemented in https://crrev.com/c/1685909. This caused some interesting
> graphics glitches with OOP-D enabled.
> 
> Bug: none
> Change-Id: Idb0d8e43c36e5f925f4c475a2010660b10c48f97
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1702147
> Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
> Commit-Queue: kylechar <kylechar@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#677458}

TBR=dcastagna@chromium.org,kylechar@chromium.org

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

Bug: none
Change-Id: I56334ee6d3d261dfd5b84d8fa5b8e337770b3792
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1720909Reviewed-by: Alex Newcomer <newcomer@chromium.org>
Commit-Queue: Alex Newcomer <newcomer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681295}

In this CL I've conditionally disabled new DCHECKs added
in crrev.com/c/1593403. Although the outline updates
should be safe, we should still fix this properly
and enable these DCHECKS universally.

Bug: 987836
Change-Id: I04d4e79652c2556ca058cb959b859c03a9415d10
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719772Reviewed-by: Aleks Totic <atotic@chromium.org>
Commit-Queue: Ian Vollick <vollick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681294}

Fixing a variable typo and adding
SigninPromoViewMediatorTest::AddDefaultIdentity().
Related to: crrev.com/c/1718370

Change-Id: I4532e824b5ab540a7d42eaaaeb271e52e16200cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1717303
Commit-Queue: Jérôme Lebel <jlebel@chromium.org>
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Auto-Submit: Jérôme Lebel <jlebel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681293}

On iOS 13, fallback colors aren't used anymore.
Changes iOS 12 selected text color to the new one.

Bug: 987174
Change-Id: Iab24298207babfdd306516a23dd9c51b8fc9c46d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1719354
Commit-Queue: Javier Ernesto Flores Robles <javierrobles@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681292}

This CL triggers the unmasking dialog when a user in the Manual
Fallback dialog selects a masked server card, and uses the results to
populate the field in the form.

Change-Id: I350cde87eb412ab709c4eca589e62ed3429ef920
Bug: 969194
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1686674
Commit-Queue: Tommy Martino <tmartino@chromium.org>
Reviewed-by: Jared Saul <jsaul@google.com>
Cr-Commit-Position: refs/heads/master@{#681291}

Build with GCC and libstdc++ is failing in files using tab_sharing_ui.h
as it has a ScopedObserver of a TabStripModel without including it
in advance.

Bug: 819294
Change-Id: I4b12073484f65ad2bb873119daa748245296d282
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1713526Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: José Dapena Paz <jose.dapena@lge.com>
Cr-Commit-Position: refs/heads/master@{#681290}

MDC font was defaulting to system font of size 14, this is kept the
same. But for some reason the font they returned couldn't be recreated
with a semibold trait. So it was switched to a normal system font of
the same size.

Fix a bug when a tab was instantiated without being selected. This
was caused by creating the views after they were being styled.

An early return to the |selected| setter was added to simplify that
method.

Bug: 987169, 976817
Change-Id: I10c97a5a8a6f155f0aac21a7f2bf5ab16ded56a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1718949
Commit-Queue: Javier Ernesto Flores Robles <javierrobles@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681289}

Allowing testers to setup responses with a byte array body
instead of a String body is important because it reflects
the true range of values that can be returned in the body of
a response.

Bug: 669707
Change-Id: I96f385bde0aa592caf60eee763bd26d0ccd2eba4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1715173
Commit-Queue: Benjamin Kirchman <kirchman@google.com>
Reviewed-by: Paul Jensen <pauljensen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681288}

... from modules/mediastream/video_track_adapter_settings.h

BUG=704136,919392
R=guidou@chromium.org, haraken@chromium.org

Change-Id: Ifd92202da1df04bbd49ceec13865e7c38f546c58
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1715884
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#681287}

https://android.googlesource.com/platform/external/perfetto.git/+log/b3891c1e6e90..d7e4835d4345


git log b3891c1e6e90..d7e4835d4345 --date=short --no-merges --format='%ad %ae %s'
2019-07-26 treehugger-gerrit@google.com Merge "traced_probes: ftrace page header parsing: turn "overwrite_count" into a bool that it effectively is"


Created with:
  gclient setdep -r src/third_party/perfetto@d7e4835d4345

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

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