GitLab

When testing binary size I often only care about Release-iphoneos and
it'd be nice to be able to specify that when invoking the script.

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I58a0ba0d470d1bbef3c405b42c62468fb64028c4
Reviewed-on: https://chromium-review.googlesource.com/996555Reviewed-by: Hiroshi Ichikawa <ichikawa@chromium.org>
Commit-Queue: John Wu <jzw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548526}

This reverts commit f5bbb138.

Reason for revert: breaks Windows build

Original change's description:
> Add SubmitFrameMissing mojo call for WebVR/WebXR
> 
> Goal is that we get a clean lifecycle for a functioning WebVR/WebXR
> presentation render loop. It's started by a presenting SendVSync, calls
> GetVSync to schedule the next frame, and is ended by a SubmitFrame
> call. If there was nothing drawn, it uses SubmitFrameMissing instead of the
> usual SubmitFrame/SubmitFrameWithTextureHandle.
> 
> In WebVR 1.1, submitFrame is a JS call, and the app can exit its animation
> loop without calling it. WebXR had an analogous feature where SubmitFrame
> was skipped if the framebuffer wasn't touched by drawing calls. This
> made it hard to tell for the device side if a frame is done or not.
> 
> WebVR 1.1 worked around this by deferring a GetVSync call until after
> SubmitFrame, but this was complex:
> 
> -  // The logic here is a bit subtle. We get called from one of the following
> -  // four contexts:
> -  //
> -  // (a) from requestAnimationFrame if outside an animating context (i.e. the
> -  //     first rAF call from inside a getVRDisplays() promise)
> -  //
> -  // (b) from requestAnimationFrame in an animating context if the JS code
> -  //     calls rAF after submitFrame.
> -  //
> -  // (c) from submitFrame if that is called after rAF.
> -  //
> -  // (d) from ProcessScheduledAnimations if a rAF callback finishes without
> -  //     submitting a frame.
> -  //
> -  // These cases are mutually exclusive which prevents duplicate GetVSync
> -  // calls. Case (a) only applies outside an animating context
> -  // (in_animation_frame_ is false), and (b,c,d) all require an animating
> -  // context. While in an animating context, submitFrame is called either
> -  // before rAF (b), after rAF (c), or not at all (d). If rAF isn't called at
> -  // all, there won't be future frames.
> 
> This CL removes those special cases and just always calls RequestVSync from
> requestAnimationFrame, collapsing cases (a) and (b) into an unconditional call.
> Cases (c) and (d) are now no longer needed and removed.
> 
> The layout tests now check the SubmitFrameMissing call count.
> 
> Also added a check for a WebXR exclusive session ending in the middle of a
> frame. (The layout tests revealed this since OnEndFrame no longer exits early
> on a clean framebuffer.)
> 
> Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
> Change-Id: I5722097d421ca9448760e696ea379895a1320199
> Reviewed-on: https://chromium-review.googlesource.com/996614
> Reviewed-by: Ian Vollick <vollick@chromium.org>
> Reviewed-by: Brandon Jones <bajones@chromium.org>
> Reviewed-by: Martin Barbella <mbarbella@chromium.org>
> Reviewed-by: Bill Orr <billorr@chromium.org>
> Commit-Queue: Klaus Weidner <klausw@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#548518}

TBR=vollick@chromium.org,bajones@chromium.org,mbarbella@chromium.org,klausw@chromium.org,billorr@chromium.org

Change-Id: I18f7e808840140c7a4c55139687700b8e1ceac8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Reviewed-on: https://chromium-review.googlesource.com/998652Reviewed-by: Klaus Weidner <klausw@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548525}

will-change will force the media controls to use a different
layer. According to Pinpoint this will reduce CC memory usage
by 18% and GPU memory usage by 6%.

BUG=821961,821414

Change-Id: I13c62f79577dfef253acf5f3b89cecaf0c5c1ad3
Reviewed-on: https://chromium-review.googlesource.com/996309Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: Becca Hughes <beccahughes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548524}

Prior to this patch, in rare circumstances represented in tests,
OnGotInitialHistoryDataAndIconURLCandidates() could be called twice
without actually receiving new candidates in-between (i.e. call to
OnUpdateCandidates()).

In the particular case of pages listing Web Manifests, this could lead
to the next candidate being processed by
DownloadCurrentCandidateOrAskFaviconService() in a situation where
actually all candidates were already processed, going out of bounds of
the candidates vector.

Bug: 828196
Change-Id: Ic4966db627b9e26252fb1c1b3f0512a054301df6
Reviewed-on: https://chromium-review.googlesource.com/995673Reviewed-by: Peter Kotwicz <pkotwicz@chromium.org>
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548523}

This reverts commit cf7316a4.

Reason for revert: Suspect for crashes in crbug/827105

Bug:827105

Original change's description:
> Simple disk cache: fix inode problem caused by extremely small cache files
>
> On POSIX filesystems, when most of cache files are extremely small, they
> are hardly evicted by size limitation of cache and cache can be grow to
> maximum inode of the partition.
>
> So make cache watch the current available inodes and update its
> limitation on maximum cache files count periodically. Then evict cached
> resources not only depending on size limit, but also on count of cached
> files limit.
>
> This was originally authored by Yunsik Jang <yunsik.jang@lge.com>
>
> Change-Id: I4216c7602b2cc24fb0f445f8297836acbc08c431
> Reviewed-on: https://chromium-review.googlesource.com/964329
> Commit-Queue: José Dapena Paz <jose.dapena@lge.com>
> Reviewed-by: Maks Orlovich <morlovich@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#545203}

TBR=pasko@chromium.org,gab@chromium.org,morlovich@chromium.org,jose.dapena@lge.com

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

Change-Id: Ib04a897431143a90bcf9f2d778247ae9b8201047
Reviewed-on: https://chromium-review.googlesource.com/995733Reviewed-by: Julia Tuttle <juliatuttle@chromium.org>
Commit-Queue: Maks Orlovich <morlovich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548522}

NOTRY=true

Bug: 829499
Change-Id: I4196bdfd484c3ca3497a390528980d72795f5a3d
Reviewed-on: https://chromium-review.googlesource.com/998613Reviewed-by: Ned Nguyen <nednguyen@google.com>
Commit-Queue: Ned Nguyen <nednguyen@google.com>
Cr-Commit-Position: refs/heads/master@{#548521}

I overzealously landed https://crrev.com/c/990512 assuming that if a
TCP connection is open through an HTTP/2 proxy with an empty ALPN list,
then the server cannot negotiate HTTP/2.  Turns out that there are
already 11 crashes reported on the first day of the Canary release
that picked up this change.  This CL adds a unittest that triggers this
CHECK (verified locally), and changes Job::DoInitConnectionComplete() to
handle this case properly and avoid the crash.

Bug: 828865
Change-Id: I5bc8fb447a07d350970904b350f9aeb670e2da7d
Reviewed-on: https://chromium-review.googlesource.com/996878Reviewed-by: Ryan Hamilton <rch@chromium.org>
Commit-Queue: Bence Béky <bnc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548520}

The patch updates most usages of |SessionID::id_type| as
well as other primitive types like |int| that actually represent
session IDs (i.e. window, tab or session identifiers). Instead,
SessionID instances are adopted, via the newly introduced API.

We do this as part of a larger effort to control better the lifetime of
SessionID instances. In particular, the goal is:
1. To avoid the direct use of the default constructor, which currently
   assigns new unique IDs (and we're planning to change that).
2. Reduce the usage of SessionID::id_type, int, int32_t etc. for the
   cases where SessionID can be used (which should be safer), so
   conversions from/to unsafe types is avoided.
3. Make the error-case (usually represented as ID -1) more homogeneous
   via the adoption of SessionID::InvalidValue().

As per behavioral differences: SessionID::FromSerializedValue()
squashes all negative numbers as well as zero into
SessionID::InvalidValue(), internally represented as -1. This should
be a no-op for most of the code, with some exceptions (like extensions
API) that I have excluded in this patch.

Bug: 823798
Change-Id: I2b6268d110cfe3fe7b531d4f95b3022d8f012e80
Reviewed-on: https://chromium-review.googlesource.com/989912
Commit-Queue: Mikel Astiz <mastiz@chromium.org>
Reviewed-by: Benoit L <lizeb@chromium.org>
Reviewed-by: rajendrant <rajendrant@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Jialiu Lin <jialiul@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548519}

Goal is that we get a clean lifecycle for a functioning WebVR/WebXR
presentation render loop. It's started by a presenting SendVSync, calls
GetVSync to schedule the next frame, and is ended by a SubmitFrame
call. If there was nothing drawn, it uses SubmitFrameMissing instead of the
usual SubmitFrame/SubmitFrameWithTextureHandle.

In WebVR 1.1, submitFrame is a JS call, and the app can exit its animation
loop without calling it. WebXR had an analogous feature where SubmitFrame
was skipped if the framebuffer wasn't touched by drawing calls. This
made it hard to tell for the device side if a frame is done or not.

WebVR 1.1 worked around this by deferring a GetVSync call until after
SubmitFrame, but this was complex:

-  // The logic here is a bit subtle. We get called from one of the following
-  // four contexts:
-  //
-  // (a) from requestAnimationFrame if outside an animating context (i.e. the
-  //     first rAF call from inside a getVRDisplays() promise)
-  //
-  // (b) from requestAnimationFrame in an animating context if the JS code
-  //     calls rAF after submitFrame.
-  //
-  // (c) from submitFrame if that is called after rAF.
-  //
-  // (d) from ProcessScheduledAnimations if a rAF callback finishes without
-  //     submitting a frame.
-  //
-  // These cases are mutually exclusive which prevents duplicate GetVSync
-  // calls. Case (a) only applies outside an animating context
-  // (in_animation_frame_ is false), and (b,c,d) all require an animating
-  // context. While in an animating context, submitFrame is called either
-  // before rAF (b), after rAF (c), or not at all (d). If rAF isn't called at
-  // all, there won't be future frames.

This CL removes those special cases and just always calls RequestVSync from
requestAnimationFrame, collapsing cases (a) and (b) into an unconditional call.
Cases (c) and (d) are now no longer needed and removed.

The layout tests now check the SubmitFrameMissing call count.

Also added a check for a WebXR exclusive session ending in the middle of a
frame. (The layout tests revealed this since OnEndFrame no longer exits early
on a clean framebuffer.)

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I5722097d421ca9448760e696ea379895a1320199
Reviewed-on: https://chromium-review.googlesource.com/996614Reviewed-by: Ian Vollick <vollick@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Reviewed-by: Martin Barbella <mbarbella@chromium.org>
Reviewed-by: Bill Orr <billorr@chromium.org>
Commit-Queue: Klaus Weidner <klausw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548518}

This is because shell extensions don't specifically target Chrome, they
just get automatically loaded by the OS. These will get blocked in phase
2 of third-party software blocking.

For IMEs, they are allowed because there is no viable alternative for
their implementation.

Bug: 829490
Change-Id: I501aad6e77734336161448f0e8e91ac78ec6d40d
Reviewed-on: https://chromium-review.googlesource.com/996586
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548517}

Not supported on iOS so dev builds will not show chrome://ukm data still.

Bug: 826400
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I5d2b1ddc06256903949940638ed76e5d9231da51
Reviewed-on: https://chromium-review.googlesource.com/985017Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Olivier Robin <olivierrobin@chromium.org>
Commit-Queue: Robert Kaplow <rkaplow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548516}

This CL extracts the call to vaCreateContext() out of VaapiWrapper's
CreateSurfaces() and into a new method VaapiWrapper::CreateContext().

The former still calls the latter, but this change allows for separating
the allocation of the surfaces from the creation of the context. In
particular, this is needed for decoding directly on client Surfaces
(see the bug and/or the experimental CL crrev.com/c/986353. from
which this code is separated).

Bug: 822346
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I37f28d2a0fe939264d3153f34bd25bbc6c77ba79
Reviewed-on: https://chromium-review.googlesource.com/995623Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548515}

ClientControlledShellSurface doesn't use configure to resize.

This is reland of https://crrev.com/c/994173/5

TBR=reveman@chromium.org
BUG=828586
TEST=manual

Change-Id: Id39f3d0ac5b680aa74fef13df7d0631d5b9ca742
Reviewed-on: https://chromium-review.googlesource.com/998339Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548514}

When steady state elisions is on, the user focuses the Omnibox, and
presses an arrow key, we should unelide and place the cursor correctly.

This adds a unit test for the above behavior.

Bug: 797354
Change-Id: I417603b21c89a634dc494dcbe3a764f19d7f0d27
Reviewed-on: https://chromium-review.googlesource.com/996295
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548513}

This fixes 3 things:
 1) No longer need a friended private variable on MessageLoop
    (this facilitates crbug.com/825327)
 2) Support backtraces that go through TaskScheduler (and eventual other
    TaskAnnotator users)
 3) Support backtraces for tasks posted when returning from a nested
    loop (MessageLoop would previously set the field to null rather than
    "previous" when returning from a task).

New TaskAnnotatorBacktraceIntegrationTests are largely based on previous
PendingTaskTests (plus testing support beyond simple MessageLoop/Thread).

Prefered making PendingTask::task_backtrace mutable to forcing all
PostTask annotations (TaskAnnotator::DidQueueTask and TaskTracker::WillPostTask)
to use a non-const pointer given this doesn't really modify the state of
the PendingTask but rather some internal tracing state.

This also revealed issue 826902.

Bug: 825987, 825327, 826902
Change-Id: Iae24c8d8745a6dadb2185f5c581fb1ff1d5b3f23
Reviewed-on: https://chromium-review.googlesource.com/982496
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548512}

Use constraintLessThanOrEqualToAnchor: to make sure that close button
always anchored to the right edge of the view.

Bug: None
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: Icf2c7064d8172056d1cba02987d703496d2dc25d
Reviewed-on: https://chromium-review.googlesource.com/998348Reviewed-by: edchin <edchin@chromium.org>
Commit-Queue: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548511}

This CL has no intended behavior change.

In addition to moving the code, this CL:
  * Updates the names of classes/files to remove the Memlog prefix.
  * Updates the name of the service to be "Heap Profiling Service" from
    "Profiling Service".
  * profiling_browsertest was removed as it wasn't testing anything useful.
    There is a large suite of end-to-end browser tests in memlog_browsertest.cc
    [untouched by this CL].

Bug: 827545
Change-Id: I7ef0947d7de4070d1863c509e2d280cefd4fec2d
Reviewed-on: https://chromium-review.googlesource.com/995641
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Cait Phillips <caitkp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548510}

The fix to crbug.com/826701 resulted in crbug.com/827931 highlighting
that calling ShowProfileErrorDialog that early (before ResourceBundle
is initialized) is just not possible.

As discussed @ https://chromium-review.googlesource.com/c/chromium/src/+/985110/3/chrome/browser/prefs/chrome_pref_service_factory.cc#332
it is preferable to defer this message to BrowserThread::UI for when
it is brought up.

Turns out ChromeBrowserMainParts::DeferringTaskRunner already puts an
early ThreadTaskRunnerHandle in place for this very purpose :)

R=sky@chromium.org

Bug: 827931
Change-Id: Icf409103e51cf9957ac60b3ffa4b8310a5b36dbb
Reviewed-on: https://chromium-review.googlesource.com/996215Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548509}

This adds a few constructors to SharedWindowedAnalyzerClient
and switches over all call sites that use initializer lists
to use a constructor instead. The upcoming FrameMetrics class
will use the "max_window_size" constructor.

Bug: 807463
Change-Id: Ie1d21b90ce00dff84d41c30e9563a9fba4ba67f5
Reviewed-on: https://chromium-review.googlesource.com/981415
Commit-Queue: Brian Anderson <brianderson@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548508}

Crash stacks seem to clearly indicate that the layout object of the
owning element of the frame may be null.

The exact reason for this is unknown, as for why it happens more
often or always when OOPIFS are present, but it seems that
http://crrev.com/1508f4a32a3fb19d6e3599acc0bcc817ebe6c5be
may be involved.

Note also that the code path in question is specific to RLS,
which explains why it starts in M66.

Bug:816383

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I8580e307d4f3d1cee312c6b70c433e0223944cb8
Reviewed-on: https://chromium-review.googlesource.com/997103Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548507}

AsynExtensionFunction is deprecated and will soon be removed.

Bug: 829174
Change-Id: I1201a74737fff8846f0847e1a2ae1c3963d96af9
Reviewed-on: https://chromium-review.googlesource.com/997099
Commit-Queue: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548506}

Will be used to check that deapplying the patch on gclient works as well.

Bug: 643346
Change-Id: I7428af15b48b772e2e8bc9662563cb880169dfac
Reviewed-on: https://chromium-review.googlesource.com/996562Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548505}

The only thing that cares about persisted SCTs is DevTools (which should be able
to handle missing SCTs or other security info), so we don't need to persist them
to the disk cache. This change removes the SCT serialization from
HttpResponseInfo::Persist and throws out SCTs when reading them out of
existing cached entries.

Bug: 647947
Change-Id: Ida1171057d9c22819778e53cd3e242b0dcac585d
Reviewed-on: https://chromium-review.googlesource.com/996462
Commit-Queue: Emily Stark <estark@chromium.org>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548504}

This is in preparation for removing all traces of "gradient" from the
implementation.

No functional change; only file/class renames.

BUG=none
TEST=none

Change-Id: Ie2d0a16239c37557ea05a7c1eeea3180ad793980
Reviewed-on: https://chromium-review.googlesource.com/996714Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548503}

NOTRY=true

Change-Id: Ib13536e94a765ecb2732125970b9210f03d0eb48
Reviewed-on: https://chromium-review.googlesource.com/998310
Commit-Queue: Ned Nguyen <nednguyen@google.com>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548502}

Bug: 717696
Change-Id: I92bcf252641604da42532da8a4d1a8d5281bfeec
Reviewed-on: https://chromium-review.googlesource.com/996581Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548501}

The test is failing on Win7 Tests (dbg)(1) and WebKit Win7 as well.

TBR=beccahughes@chromium.org
TBR=thomasanderson@chromium.org

No-Try: true
No-Presubmit: true
No-Tree-Checks: true

Bug: 829228
Change-Id: I676a6d19c2f35a3acd8fc701b409fc8c2fb4ba20
Reviewed-on: https://chromium-review.googlesource.com/998332
Commit-Queue: Takumi Fujimoto <takumif@chromium.org>
Reviewed-by: Takumi Fujimoto <takumif@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548500}

I thought that this would trigger a hairpin callback, but it doesn't
because device discovery goes via the MessageLoop in both the virtual
and real-world cases.

Change-Id: I2c44793294189d9171221d1cb9cdb5a706c3869e
Reviewed-on: https://chromium-review.googlesource.com/982634
Commit-Queue: Adam Langley <agl@chromium.org>
Reviewed-by: Balazs Engedy <engedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548499}

We now provide frame tree, frame committed and frame deleted trace events
while tracing, and then show the processes which match them on Timeline.

Followups:
- move browser events from tracing handler to frame tree nodes;
- emit frame tree from tracing started observer;
- do the same for workers in renderer;
- remove InspectorTracingAgent;
- maybe show non-interesting events on the tracks, but grey them out;
- UI improvements.

Bug: 820250
Change-Id: I6a4a782cab2f286bc037742f4119e1eca9a34d3c
Reviewed-on: https://chromium-review.googlesource.com/974367
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548498}

Including a name in the trace makes it easier to diagnose bugs.

Bug: 777763
Change-Id: I81d80b4cc0f9d71be5631575730a7ae6479b18f0
Reviewed-on: https://chromium-review.googlesource.com/977969
Commit-Queue: Alex Clarke <alexclarke@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548497}

Now password_controller.js is injected by adding it to call of __gCrWeb.findPasswordForms().
It has performance drawbacks since __gCrWeb.findPasswordForms() could be called multiple times.
This CL makes injection of password_controller.js with WKWebView injection.

Also this CL updates the header comment in password_controller.js with up-to-date information.

Bug: 828824, 418827
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I4036e3279e0c3a32301795b46630c49801679106
Reviewed-on: https://chromium-review.googlesource.com/995534
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548496}

We attempt to optimize the background image destination rectangle to
avoid pointlessly painting under borders, thus allowing more non-tiling
image draws. But that breaks when there is a border image with outsets
because in that case, despite an opaque border, the background image
may not cover the border area.

Also clean up the conditional that prevents the optimization.

R=fmalita@chromium.org
BUG=827871

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ibd0fb4307fd2d7b7df4421f18fb07da2c669aa79
Reviewed-on: https://chromium-review.googlesource.com/996884
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548495}

Tests were broken because:
1: Not updating constants after reverting
   https://chromium-review.googlesource.com/957916
2: Not overriding some size classes in UIWindow
3: Removing width constants that would require pixel alignment, which
   means tests would be device scale dependent.

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I3813137b884475e645a3a7977b8ff699d53bfa20
Reviewed-on: https://chromium-review.googlesource.com/996216Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548494}

Include new archive additions like pak/dex/other parsing.

Bug: 827168
Change-Id: Idf9d851765d5a3b20cffa3c9177481a392cc8153
Reviewed-on: https://chromium-review.googlesource.com/997974
Commit-Queue: Peter Wen <wnwen@chromium.org>
Reviewed-by: agrieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548493}

Right now in TouchActionFilter class, the white_listed_touch_action_
member has a default value of Auto when the TouchActionFilter is
constructed. We have not started using this value yet to filter gesture
event and that's why this is not a problem for now. However, later on
we would want to use that value to determine whether a gesture is
definitely / partially allowed. In that case, a default value of auto
will cause a lot of trouble.

It makes sense to make white_listed_touch_action_ member Optional.
When we receive a computed value from cc, we set it. When we start
filtering gesture event, we will be able to check against the value
that we received from cc, instead of against the default value.

This CL should not cause any behavior change because we have not yet
using that value to do anything. It is a pre-requisite for following up
CLs that will be using the value to filter gesture event.

Bug: 772130
Change-Id: I6de715c62b86067d53c28b5241002b9b8f74e16c
Reviewed-on: https://chromium-review.googlesource.com/997763
Commit-Queue: Xida Chen <xidachen@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548492}

When the build flag enable_volume_tables_access is false the AThing speaker
build for CMA breaks. This adds the necessary #idefs.

Bug: internal b/77634874
Test: builds now
Change-Id: I8841c819c2ac5523c2953c6725c69b92bc328864
Reviewed-on: https://chromium-review.googlesource.com/998334Reviewed-by: Kenneth MacKay <kmackay@chromium.org>
Commit-Queue: Chris Kuiper <ckuiper@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548491}

The 'AsyncTransferThread' was removed in crrev.com/345908. So remove the
reference to it from the benchmark code.

BUG=509076

Change-Id: I9b9fe755a87ea55eeff5ccc1c3a59943684a0958
Reviewed-on: https://chromium-review.googlesource.com/997102Reviewed-by: David Reveman <reveman@chromium.org>
Reviewed-by: Ned Nguyen <nednguyen@google.com>
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548490}

While geolocation is active, the network geolocation provider
periodically scans using WLAN hardware to identify nearby wifi APs.
The set of APs is sent to a Google service which returns a position
estimate. Once there are no active geolocation listeners, the
wifi data provider and network location provider are shut down.

Some state retained by these providers must be preserved in order to
properly enforce the wifi polling policy. Previously, the policy state
was destroyed whenever there were no active geolocation listeners,
allowing a situation where wifi scans could be performed in rapid
succession as long as the providers were recreated each time. With this
CL, a newly-created WifiDataProvider obeys the policy for its initial
scan.

When a newly-created WifiDataProvider is denied an initial scan, it may
cause a newly-created NetworkLocationProvider to fail to acquire fresh
wifi data in a timely manner. This may cause a related issue where a
Geolocation call is unable to acquire a fresh estimate due to policy,
and has no cached value to return, leading to long delays or timeouts on
Geolocation API calls. To provide a good experience in this situation,
NetworkLocationProvider's cache of the most recent network position
estimate is moved to LocationArbitrator where it is retained when the
provider is recreated. The cached value may be returned when it is
sufficiently recent and no new data is available.

BUG=828547

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

Bug: 807436
Change-Id: Ic908a9764c1f9432ee14783561f720597c2c2b42
Reviewed-on: https://chromium-review.googlesource.com/996453Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548488}

After the 1% rollout of the new app, we have seen a ~30% drop in the
reliability metrics. More than half of the failure are p2p-failure. We
are also getting lots of users reporting that the app used to work on
the old app but it no longer works.

Turns out many mobile ISPs have already switched into an IPv6-only
network (with NAT64 gateway), and they are not able to connect because
we hardcode IPv4 addresses in stanza and other places. We didn't had the
logic to handle this before so I'm not sure why many people with
IPv6-only network also claim that it used to work on the old app. Maybe
Apple had removed an IPv4 compatibility layer?

This CL fixes this issue by adding IPv6 translation logic when dealing
with IPv4 literals.

Change-Id: I1a25fad4c2f7c804a66f0e04b3569b5aa5d49b5c
Bug: 829117
Reviewed-on: https://chromium-review.googlesource.com/994587Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Commit-Queue: Yuwei Huang <yuweih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548487}