GitLab

views wants to (more or less) own the DialogDelegate. This is currently
done via refcounting. To remove that dependency of the refcounts,
extract it into its own object, with lifetime contracts against
LoginHandler.

Now the threading and refcounting mess is largely confined to the
LoginHandler base class, rather than spread into the subclasses.

Bug: 908926
Change-Id: Ia7f88c23d051dff06492baee2b050f82265a59e3
Reviewed-on: https://chromium-review.googlesource.com/c/1388037Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Carlos IL <carlosil@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626194}

The AutoRoll server is located here: https://autoroll.skia.org/r/fuchsia-sdk-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:fuchsia-arm64-cast;luci.chromium.try:fuchsia-x64-cast
TBR=cr-fuchsia+bot@chromium.org

Change-Id: I8b2793a95aa1a6642e0b87d98fe63747a55040b6
Reviewed-on: https://chromium-review.googlesource.com/c/1437398Reviewed-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@{#626193}

This is for consistency with Windows and allows minimized windows to be
activated.

BUG=924075
R=sky,fbeaufort

Change-Id: Ic86ffba47805b2ba4f5c8f049cdccd2e75be8d9b
Reviewed-on: https://chromium-review.googlesource.com/c/1437263
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Auto-Submit: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626192}

This reverts commit ad149d1e.

Reason for revert: crbug/925079 — ubsan

Original change's description:
> Revise EventRewriter API.
>
> Since http://crrev.com/556458 there have been two (or three) completely
> different ways of ‘returning’ events from an EventRewriter:
>
> - The original output parameter on RewriteEvent(), with the clunky
>   NextDispatchEvent() to produce multiple events.
>
> - Calling SendEventToEventSource(source, event), when the replacement
>   event must pass through later event rewriters. (This had the problem
>   of not tracking the original source.)
>
> - Several EventRewriters do an end run around the rewriter system in
>   some cases, e.g. calling WindowEventDispatcher::OnEventFromSource()
>   after a timeout, since the original RewriteEvent() interface could
>   only produce events in response to incoming events.
>
> This CL replaces all the above cases with a consistent return mechanism,
> using Send…() functions. This is inspired by SendEventToEventSource(),
> but has the caller provide the output functions explicitly, so that
> multiple sources can correctly share an EventRewriter (as Ash does).
>
> This CL contains the EventRewriter/EventSource revision, under
> //ui/events, plus conversions of ‘trivial’ rewriters (essentially those
> that only used RewriteEvent()). Other rewriters will be converted in
> separate CLs for review by their respective OWNERS, because removing
> NextDispatchEvent() or asynchronous dispatch generally requires some
> logic change.
>
> This CL includes a compatibility shim for the old API, which will be
> removed once all rewriters have changed.
>
> How to convert an EventRewriter:
>
> How to convert an EventRewriter:
>
> - When the incoming event is accepted unchanged, replace old API uses of
>      return EVENT_REWRITE_CONTINUE;
>   with new API
>      return SendEvent(continuation, &incoming_event);
>
> - When the incoming event is to be discarded, replace old API uses of
>      return EVENT_REWRITE_DISCARD;
>   with new API
>      return DiscardEvent(continuation);
>
> - When the incoming event is to be replaced, replace old API uses of
>      *rewritten_event = std::move(new_event);
>      return EVENT_REWRITE_REWRITTEN;
>   with new API
>      return SendEventFinally(continuation, replacement_event);
>
> - When the incoming event is to be replaced, and the replacement event
>   should pass through later rewriters, replace old API uses of
>      return SendEventToEventSource(source, replacement_event);
>   with new API
>      return SendEvent(continuation, replacement_event);
>
> - When the incoming event is to be replaced by multiple events, replace
>   old API uses of
>      *rewritten_event = std::move(new_event_1);
>      // record new_event_2 … new_event_N
>      return EVENT_REWRITE_DISPATCH_ANOTHER;
>   with new API
>      details = SendEventFinally(continuation, new_event_1);
>      ⋮
>      return SendEventFinally(continuation, new_event_N);
>
> Bug: None
> Change-Id: I4d217cee5aa1a2f2dbf178ce642ef1b6e2338c25
> Reviewed-on: https://chromium-review.googlesource.com/c/1203882
> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
> Reviewed-by: Michael Wasserman <msw@chromium.org>
> Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
> Reviewed-by: Peter Kotwicz <pkotwicz@chromium.org>
> Reviewed-by: Ken Buchanan <kenrb@chromium.org>
> Commit-Queue: Kevin Schoedel <kpschoedel@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#625701}

TBR=sadrul@chromium.org,msw@chromium.org,kenrb@chromium.org,kpschoedel@chromium.org,afakhry@chromium.org,pkotwicz@chromium.org

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

Bug: 925079
Change-Id: I0489467f0ee4d6cfca4a71570280cfcb49678135
Reviewed-on: https://chromium-review.googlesource.com/c/1435688
Commit-Queue: Kevin Schoedel <kpschoedel@chromium.org>
Reviewed-by: Kevin Schoedel <kpschoedel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626191}

This CL changes the concept of choosing a primary display.

As discussed offline with rjkroege@, Chromium assumes that a primary
display must be chosen among displays located as near to origin
as possible (and Wayland does not have a concept of a primary display.
Thus, that assumption works best).

There are several cases, which have been addressed in WaylandScreen:
1) When an output is added, its type is NOT_PRIMARY as long as
geometry data is not known by that point.
2) Once Wayland sends all the geometry changes to a WaylandOutput,
the last one notifies WaylandScreen about the changes, and
OnOutputMetricsChanged is called. A decision on which display
is primary is taken based on several conditions:
 - If there was a single display added without bounds (it always
   happens on initialization, when no display was added before),
   it must have been the very same display, which received
   geometry changes, and it must become the primary display.
 - If an updated/newly added display is located closer to origin
   that a previous one, the former becomes a primary.
 - If an updated/newly added display is one of the nearest displays
   to origin and the previous display matches the same condition,
   choose the updated/newly added one, because Wayland is sending
   geometry changes for all the displays (a reaction to relocation
   actions performed by a user).

Bug: 924088
Change-Id: Icf13f7b7eee0a33a67ca4830168eff9b5332ee9b
Reviewed-on: https://chromium-review.googlesource.com/c/1426701
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626190}

Draw Occlusion has launched successfully last year, we now remove it from base::Feature list.

Bug: 924129

Change-Id: I4126303bdc87f34403789e9eccf74c98be89ca91
Reviewed-on: https://chromium-review.googlesource.com/c/1429381Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Yi Xu <yiyix@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626189}

Currently, if a device starts a RemotePlayback session and an external
device plays/pauses the video (via the Android cast notification), the
WMPI that started the casting session never gets updated. This means
that the user will see the video element on their phone as "playing",
with no media time update, or they will see the local video as paused
when the cast video is clearly playing.

This CL addresses the issue by requesting Blink to play/pause the
HTMLMediaElement to match the state of the remotely playing video.
This is done by bubbling up play state changes from the
FlingingRenderer to WMPI via the OnRemotePlayStateChange interface.

To detect an external play state change, we save whether the last
command from WMPI was a play or a pause, and propagate a change whenever
we get a MediaStatus update that is of the opposite play state. The
cast device does not care if it receives a "PLAY" command while already
playing (or "PAUSE" when paused). Therefore, after calling
OnRemotePlayStateChange, FlingingRenderer does not need to treat the
commands it receives any differently than a user initiated command.

NOTE: This approach works reasonably well, but is not an ironclad
guarantee of consistency. We are fine with missing a few changes,
because all the user has to do is tap the video element once to return
to a consistent state. Being too aggressive in trying to detect play
state changes sometimes causes the phone to go in a feedback loop,
where it constantly issues commands while the UI wildly switches
between playing and pausing.

Bug: 790766
Change-Id: If230c412a6a020c88970e1c9475d8fdc97976c3b
Reviewed-on: https://chromium-review.googlesource.com/c/1413398
Commit-Queue: Thomas Guilbert <tguilbert@chromium.org>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626188}

Bug: 866062
Change-Id: Ib611fae1f944b2674531ba064f19810fc40dd381
Reviewed-on: https://chromium-review.googlesource.com/c/1417114Reviewed-by: Caleb Rouleau <crouleau@chromium.org>
Reviewed-by: Achuith Bhandarkar <achuith@chromium.org>
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626187}

This CL is adding a sanity dcheck to avoid tests crashing on MAC only when
a chrome developer forgot to call the base function
"ContentBrowserTest::PreRunTestOnMainThread".


  class MyBrowserTest : public ContentBrowserTest {

   public:

    void PreRunTestOnMainThread() override {

      [...]

      ContentBrowserTest::PreRunTestOnMainThread();
  // Required, otherwise crash on MAC.
    }

I recently did that silly mistake and needed time to set up a MAC build to
debug it. I believe this test is cheap enough and worth saving developers time.

R=sky@chromium.org

Change-Id: Iec0ed2e19b216a35c675016ad6ff88dc9e1c86ad
Reviewed-on: https://chromium-review.googlesource.com/c/1407110Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626186}

This change fixes a crash that occurs when trying to view the USB
preferences when a device has been granted permission to a site. The
crash is caused because addChosenObjects() does not check if |mSearch|
is null first before checking if the String is empty.

Bug: 923593
Change-Id: I772e4357361653e7b5e0ce41691e7832d525a68a
Reviewed-on: https://chromium-review.googlesource.com/c/1427740Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Ovidio de Jesús Ruiz-Henríquez <odejesush@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626185}

In Network Quality Estimator (NQE), start an experiment to
cap the value of the Effective Connection Type (ECT) when
the signal strength is low. Currently, NQE computes ECT based
on the observed RTT of the network traffic. This CL adds a mechanism
to modify ECT on connections expected to be slower without waiting
for the network traffic to take the full RTT.

Change-Id: I271aa0e461b4de96d8b33dd87c6a9e23298fadf9
Bug: 924160
Reviewed-on: https://chromium-review.googlesource.com/c/1420270Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Ryan Sturm <ryansturm@chromium.org>
Commit-Queue: Tarun Bansal <tbansal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626184}

Replace AccountTrackerService::GetAccountInfo() with
IdentityManager::GetPrimaryAccountInfo().

Bug: 922760
Change-Id: I39faccbf4fc622f808a1ec75e67656d55260c2bb
Reviewed-on: https://chromium-review.googlesource.com/c/1425611
Commit-Queue: Henrique Ferreiro <hferreiro@igalia.com>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626183}

ImageChanged() is called immediately when a LayoutObject is added
as an ImageObserver of a StyleImage. Previously LayoutBlock::ImageChanged()
called FirstLineStyleRef() which would update the first line style cache
which might be too early. Particulary, that caused re-entrance of
AddClient() when we updated the pending image observer when the cache
was updated.

Now don't call FirstLineStyleRef() from LayoutBlock::ImageChanged().

Also added DCHECKs to ensure a LayoutObject calls StyleImage::AddClient()
and StyleImage::RemoveClient() for exactly the same count.

Bug: 924457
Change-Id: Ib3f33febfbc591707e70813c7cb4add90ced7671
Reviewed-on: https://chromium-review.googlesource.com/c/1436881
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626182}

This reverts commit b21bf2bb.

Reason for revert: broke the build: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8923328721517960816/+/steps/compile/0/stdout

Original change's description:
> [Nav Experiment] Call LoadIfNecessary() in CWVWebView session restore.
> 
> The web view load scheduled by WKBasedNavigationManager::Restore() is
> deferred when used in CWVWebView's |resetWebStateWithSessionStorage|
> because the |_containerView| is not created until later. This CL calls
> LoadIfNecessary() explicitly after the view is created to trigger the
> session restoration.
> 
> This fixes WebViewRestorableStateTest when WKBasedNavigationManger is
> enabled. A better approach would be to turn this test into a
> programmatic test so both navigation managers implementations are
> tested, but web::features symbols are not exposed in ios/web_view.
> 
> Bug: 862714
> Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;luci.chromium.try:ios-simulator-cronet
> Change-Id: I21e694e3fef6a833f1cce04ff9cebd3784349111
> Reviewed-on: https://chromium-review.googlesource.com/c/1135435
> Commit-Queue: Danyao Wang <danyao@chromium.org>
> Reviewed-by: Eugene But <eugenebut@chromium.org>
> Reviewed-by: Hiroshi Ichikawa <ichikawa@chromium.org>
> Reviewed-by: Justin Cohen <justincohen@chromium.org>
> Auto-Submit: Danyao Wang <danyao@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#626170}

TBR=justincohen@chromium.org,eugenebut@chromium.org,jbudorick@chromium.org,danyao@chromium.org,ichikawa@chromium.org

Change-Id: Ie5346cd1e76b6e7510f589e2cb36602ed7cc0fbd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 862714
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;luci.chromium.try:ios-simulator-cronet
Reviewed-on: https://chromium-review.googlesource.com/c/1436172Reviewed-by: Danyao Wang <danyao@chromium.org>
Commit-Queue: Danyao Wang <danyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626181}

This still leaves memory_instrumentation in the RC service, hosted
by content and the relevant dependencies. All dependencies to the
RC coordination unit graph are however scrubbed.

Bug: 910288
Change-Id: I6744d2f8d42ad8c88458b531057ada0c4c2ba01a
Reviewed-on: https://chromium-review.googlesource.com/c/1425042
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: François Doray <fdoray@chromium.org>
Reviewed-by: Chris Hamilton <chrisha@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626180}

Previously introduced WebNavigationBodyLoader is now used for
loading the navigation request body, instead of faking the
WebURLRequest.

Brief list of changes in this patch:
- WebNavigationParams take a bunch of request- and response-related
  fields instead of WebURLRequest.
- RenderFrameImpl fills the params instead of constructing a fake
  WebURLRequest, and constructs NavigationBodyLoader.
- DocumentLoader synchronously processes params, and then starts
  body loader to receive the main resource data. Multiple places
  in Blink are interested in main resource loading process, so
  DocumentLoader notifies them by calling DispatchXXX methods
  on FrameFetchContext. We should be able to clean this up later
  if needed.
- webkit_unit_tests mimic production and create a body loader
  of their own.
- Some unrelevant test cases are removed (e.g. checking main
  resource request priority).

With this patch we are just two steps away from committing
navigation synchronously:
- Preload mhtml archives in advance to retrieve the mime type of
  the main document.
- Move commit from "received first byte" to "handle response" step.

Things which could be cleaned up:
- Elegantly notify interested parties about main resource load.
- Simplify the loading flow in DocumentLoader, making it linear.
  Currently, we keep the flow similar to original one, where we
  call StopLoading() from various places to minimize the CL and
  potential risk.

This patch corresponds to step 6.g of the doc linked in the bug.

TBR=mmenke@chromium.org

Bug: 855189
Change-Id: I379172a94d2d59f694d0cbb99f22b147339a5090
Reviewed-on: https://chromium-review.googlesource.com/c/1401238
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626179}

BUG=804637
R=thestig

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

The cpu_profiler category is disabled by default.
This entry is not useful and is adding confusion
to users when reporting traces on bugs.

R=oysteine@chromium.org

Change-Id: I8d272dccf9307739d8cb5d95aa830357219ae31f
Reviewed-on: https://chromium-review.googlesource.com/c/1435747Reviewed-by: oysteine <oysteine@chromium.org>
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626177}

Bug: 924785
Change-Id: Ia077d4d43baf974df46baa64632254e95a9ec6b1
Reviewed-on: https://chromium-review.googlesource.com/c/1432883
Commit-Queue: Jenny Zhang <jennyz@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626176}

The //fuchsia:webrunner_pkg was moved to
//fuchsia/runners:web_runner_pkg but a reference to the old target was
still present in //fuchsia:action. This fixes the issue.

Bug: 922635
Change-Id: I29733695ef4dcbe1e84ae1b3be51754ed69b5297
Reviewed-on: https://chromium-review.googlesource.com/c/1435700
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Commit-Queue: Kevin Marshall <kmarshall@chromium.org>
Reviewed-by: Kevin Marshall <kmarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626175}

The mojom category is needed to debug what is happening on the IO/Thread.
We are seeing janks related to communications between renderers, browser
and GPU. We believe the mojom categoy will help us doing investigation.

R=oysteine@chromium.org

Bug: 867931
Change-Id: Ic01d67ca82cf60e949793eaf5ac1a09486452519
Reviewed-on: https://chromium-review.googlesource.com/c/1437065Reviewed-by: oysteine <oysteine@chromium.org>
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626174}

According to the new RobolectricTestRunner(haven't updated yet): https://github.com/robolectric/robolectric/blob/robolectric-4.1/robolectric/src/main/java/org/robolectric/RobolectricTestRunner.java#L98
seems getJarResolver() called in the constructor which will check system property "robolectric.offline" for DependencyResolver.

Bug: 900746
Change-Id: Ia05f0028330b8633a9fe329824d1a97e18f37e50
Reviewed-on: https://chromium-review.googlesource.com/c/1436557Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Yun Liu <yliuyliu@google.com>
Cr-Commit-Position: refs/heads/master@{#626173}

JSON manifests are deprecated.

Bug: 895616
Change-Id: If5306731b0bae4cb12dba636e8a70aef87766514
TBR: halliwell@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/1436734
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626172}

There are lots of unused includes. Also modernize the code slightly.

Change-Id: I55fea71019682e39a018f211c33f71db3543901a
Reviewed-on: https://chromium-review.googlesource.com/c/1435722Reviewed-by: Tommy Li <tommycli@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626171}

The web view load scheduled by WKBasedNavigationManager::Restore() is
deferred when used in CWVWebView's |resetWebStateWithSessionStorage|
because the |_containerView| is not created until later. This CL calls
LoadIfNecessary() explicitly after the view is created to trigger the
session restoration.

This fixes WebViewRestorableStateTest when WKBasedNavigationManger is
enabled. A better approach would be to turn this test into a
programmatic test so both navigation managers implementations are
tested, but web::features symbols are not exposed in ios/web_view.

Bug: 862714
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;luci.chromium.try:ios-simulator-cronet
Change-Id: I21e694e3fef6a833f1cce04ff9cebd3784349111
Reviewed-on: https://chromium-review.googlesource.com/c/1135435
Commit-Queue: Danyao Wang <danyao@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Hiroshi Ichikawa <ichikawa@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Auto-Submit: Danyao Wang <danyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626170}

When connecting touch devices via a USB-C cable, the touch-display
pairing may fail. This happens specifically when multiple external
displays are connected. The only way to resolve this is by performing
a manual calibration.

The default heuristic that pairs touch controllers and displays
connected via the USB fails since the display is actually connected
via the display link interface rather than the USB. The display is
thus listed as an evdi device when the pairing happens.

This patch changes the way we identify USB devices and lists evdi
displays as USB displays instead.

Bug: 925211
Change-Id: I2568d41360f6f23465fd28314d5602f29f562204
Component: Touch device manager, evdi, usb, pairing
Reviewed-on: https://chromium-review.googlesource.com/c/1435758
Commit-Queue: Malay Keshav <malaykeshav@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Michael Spang <spang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626169}

Using wpt-import in Chromium 8427edc8.
With Chromium commits locally applied on WPT:
f643497e "[resource-timing] Modify is_secure_context_ based on resource"
20defaa4 "[LayoutNG] ComputeReplacedSize min/max width/height fix"
40748e1e "Upstream fast/workers to external/wpt/workers: first batch."
6691ad3f "Fix preload tests failing on wpt.fyi dashboard, second attempt"


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

Directory owners for changes in this CL:
andruud@chromium.org:
  external/wpt/css/css-properties-values-api
bugsnash@chromium.org, ericwilligers@chromium.org, meade@chromium.org, nainar@chromium.org, rjwright@chromium.org, shend@chromium.org:
  external/wpt/css/css-conditional
drott@chromium.org, kojii@chromium.org:
  external/wpt/css/css-fonts

NOAUTOREVERT=true
TBR=markdittmer

No-Export: true
Change-Id: I1578fb80b8b4d56d239c08fdcc5cf60173cbc359
Reviewed-on: https://chromium-review.googlesource.com/c/1437066Reviewed-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@{#626168}

Flushing after every sequence of command, which is sufficient to work
around this crash without OOP-R, did not work around this crash.
Now flush at every command.

The flowchart for interpreting these results is
- If this does not fix the issue: Add crash instrumentation to see what
  command is causing the crash.
- If this fixes the issue: See if we can "bisect" which commands need
  to be flushed in order for this to be fixed.

Bug: 906453
Change-Id: Ic60833d4c4e15f7c9eed18ca5b6267e275ae6dec
Reviewed-on: https://chromium-review.googlesource.com/c/1436591Reviewed-by: Victor Miura <vmiura@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626167}

This is intended as a decent introduction for folks who have to work on
AppCache.

Change-Id: I153251d0128f58261fa9e3c66339982b0bf4493d
Reviewed-on: https://chromium-review.googlesource.com/c/1424220
Commit-Queue: Victor Costan <pwnall@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Auto-Submit: Victor Costan <pwnall@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626166}

TBR=dmazzoni@chromium.org, aleventhal@chromium.org

Change-Id: I0ec929c7bac23f8a5f5bf3e53d2f4aa38bb35db8
Reviewed-on: https://chromium-review.googlesource.com/c/1361336
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626165}

No behavior change expected.

compile_resources.py takes almost exclusively build intermediates as
inputs (all except for link config, which rarely changes), and so
md5_check was just adding complexity & overhead.

Adding AtomicOutput should improve robustness & reduce overbuilds in a
more effective way, as well as protect against Ctrl-C at unfortunate
times.

Change-Id: Iee179fb3b693e8f2b98399b365537ff7aec27b13
Reviewed-on: https://chromium-review.googlesource.com/c/1436736
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Auto-Submit: Andrew Grieve <agrieve@chromium.org>
Reviewed-by: Eric Stevenson <estevenson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626164}

Bug: 916726
Change-Id: I2b09a0d9c7b3f6b716bb250a68b2cbada1d472d3
Reviewed-on: https://chromium-review.googlesource.com/c/1427463
Commit-Queue: Kevin Strohbehn <ginko@google.com>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Weidong Guo <weidongg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626163}

This CL effectively reverts the refactoring in
https://chromium-review.googlesource.com/c/chromium/src/+/1185218/. It
extracts the lower level decode code so that it can be used (later) to
implement a gpu::ImageDecodeAcceleratorWorker that decodes JPEGs using
the VAAPI.

A VaapiJpegDecoder class is created to contain this lower level code. In
a follow-up CL, this class is expanded to be responsible for dealing
with the VaapiWrapper and surface creation.

This opportunity is used to fix some includes and build dependencies.
Additionally, some code health fixes are done, the most significant
being getting rid of memset in the Fill*() methods.

Bug: 924310
Test: the VaapiJpegDecoderTest unit tests pass on a nocturne.
Change-Id: Idf207e9f81385611e84069e229a0e59eec2479ec
Reviewed-on: https://chromium-review.googlesource.com/c/1424401Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Andres Calderon Jaramillo <andrescj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626162}

https://pdfium.googlesource.com/pdfium.git/+log/e24ead1a8947..f0898a22bff3


git log e24ead1a8947..f0898a22bff3 --date=short --no-merges --format='%ad %ae %s'
2019-01-25 tsepez@chromium.org Remove CJX_ classes that do not meaningfully extend CJX_Container.


Created with:
  gclient setdep -r src/third_party/pdfium@f0898a22bff3

The AutoRoll server is located here: https://autoroll.skia.org/r/pdfium-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=dsinclair@chromium.org

Change-Id: Ib2fbeadb148daafaa61d8411e3f6ab9650dece65
Reviewed-on: https://chromium-review.googlesource.com/c/1437008Reviewed-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@{#626161}

SVG elements don't participate in the normal layout algorithms and are
more likely to be used for animations.

Bug: 581518
Change-Id: I66c811d32fabff6c181629b82a9798a9e9d60995
Reviewed-on: https://chromium-review.googlesource.com/c/1437104
Commit-Queue: Steve Kobes <skobes@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626160}

This CL merges the SOCKSClientSocketPool with the
TransportClientSocketPool it used to sit above. In doing this, the
SOCKSClientSocketPool class is removed, in favor of a
TransportClientSocketPool. SOCKSConnectJobs now directly create
TransportConnectJobs, instead of going through a socket pool.

This doesn't affect any other socket pools - there's still an SSL socket
pool on top of the socket pool for a SOCKS proxy, for instance.

This is part of an effort to flatten the socket pools.
https://docs.google.com/document/d/1g0EA4iDqaDhNXA_mq-YK3SlSX-xRkoKvZetAQqdRrxM/edit

Bug: 472729
Change-Id: I22f808bb67372d0f9dd843bae9c70006f553b04b
Reviewed-on: https://chromium-review.googlesource.com/c/1417719
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626159}

Change-Id: I94a3e7c5f8e89e2d2080024755cdc4a5f87ad92f
Reviewed-on: https://chromium-review.googlesource.com/c/1437396Reviewed-by: David Bienvenu <davidbienvenu@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626158}

Bug: 921548
Change-Id: I1406ddf0284dac2d007d71f4b7acac23d72c6a63
Reviewed-on: https://chromium-review.googlesource.com/c/1436203
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Auto-Submit: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626157}

This deadlock situation is not reproducable and we don't have any
understanding of how perfetto would add a task to the scheduler's
sequence manager rather then the task manager. We suspect that this is
no longer an issue.

Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=839073
Change-Id: Id56e2f3bed30e29abb0c05e668ef9abbafda909f
Reviewed-on: https://chromium-review.googlesource.com/c/1433771
Auto-Submit: Stephen Nusko <nuskos@chromium.org>
Commit-Queue: oysteine <oysteine@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626156}

Rather than blindly assigning "nested-document", we ought to examine the
state of the frame's owner to determine whether it might potentially end
up executing as a plugin, and report the value in the header accordingly.

Bug: 860510
Change-Id: I78291d8209382fbd325f4d8e72b24c6444fe25b6
Reviewed-on: https://chromium-review.googlesource.com/c/1432955
Auto-Submit: Mike West <mkwst@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626155}