GitLab

VibrationTest.CancelVibrationFromMainFrameWhenMainFrameIsReloaded

BUG=617727
TBR=oshima@chromium.org

Review URL: https://codereview.chromium.org/2047503002 .

Cr-Commit-Position: refs/heads/master@{#398101}

Right now, we do a layer tree walk for iteration over all
layers on impl-side (LayerListIterator). Once we start
pushing layer list instead of layer tree during
commit/activation, we will use layer_list instead(layers
will be added to layer_list in stacking  order during
commit/activation). A lot of tests build layer
tree on the impl-side and don't go through
commit/activation. So, we need to explicitly build the
layer_list for these tests.

BUG=617366
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2032303004
Cr-Commit-Position: refs/heads/master@{#398100}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=piman@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2035943002
Cr-Commit-Position: refs/heads/master@{#398099}

Rename it to purgeActiveNetworkList which better reflects its actual
function.  It only purges the list of inactive networks, and does
not add to the list.

R=xunjieli

Review-Url: https://codereview.chromium.org/1967373003
Cr-Commit-Position: refs/heads/master@{#398098}

This CL is a strength of https://codereview.chromium.org/1952853005/.

BUG=607695

Review-Url: https://codereview.chromium.org/2032043002
Cr-Commit-Position: refs/heads/master@{#398097}

Revert of Re-enable WebGL Image Chromium. (patchset #3 id:40001 of https://codereview.chromium.org/2025973002/ )

Reason for revert:
I'm observing a behavior difference between the Image CHROMIUM and non-Image CHROMIUM path. Turning off Image CHROMIUM while I investigate.
https://bugs.chromium.org/p/chromium/issues/detail?id=617249#c5

Original issue's description:
> Re-enable WebGL Image Chromium.
>
> This CL makes DrawingBuffer use the newly added DescheduleUntilFinishedCHROMIUM,
> and turns on IOSurface backed WebGL by default.
>
> BUG=581777
>
> Committed: https://crrev.com/801f15833c140f120a2f5baed88645cb0619ab86
> Cr-Commit-Position: refs/heads/master@{#397603}

TBR=kbr@chromium.org,avi@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=581777

Review-Url: https://codereview.chromium.org/2041053002
Cr-Commit-Position: refs/heads/master@{#398096}

It's temporarily plumbed on PaintInvalidationState to let it work for spv2.
Will gradually switch to new code, using the paint property data collected
by PaintPropertyTreeBuilder.

Enable SlimmingPaintInvalidation by default when spv2 is enabled.

BUG=510908

Review-Url: https://codereview.chromium.org/2033183002
Cr-Commit-Position: refs/heads/master@{#398095}

This should be a behavior no-op. The nontrivial "is enabled" and "execute"
commands are now split into helper functions using a consistent style. This
helps make the multi-hundred-line-long switch statements more manageable.

Review-Url: https://codereview.chromium.org/2035033003
Cr-Commit-Position: refs/heads/master@{#398094}

It seems some implementations thow an undocumented exception
from MediaDrm.closeSession(). This CL catches and ignores all
of them.

BUG=611865

Review-Url: https://codereview.chromium.org/2038193003
Cr-Commit-Position: refs/heads/master@{#398093}

Aggressive inlining causes -Wstrict-overflow to be triggered.

BUG=616957
BUG=internal b/29059135

Review-Url: https://codereview.chromium.org/2036613002
Cr-Commit-Position: refs/heads/master@{#398092}

R=sky@chromium.org

Review-Url: https://codereview.chromium.org/2038143003
Cr-Commit-Position: refs/heads/master@{#398091}

Fix off-by-one error in https://crrev.com/385513

BUG=617553

Review-Url: https://codereview.chromium.org/2040963002
Cr-Commit-Position: refs/heads/master@{#398090}

This CL fixes an issue with the scroll to section not finding its host
element. A unit test has also been added to detect the issue.

BUG=616186
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2022893003
Cr-Commit-Position: refs/heads/master@{#398089}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=reillyg@chromium.org

Review-Url: https://codereview.chromium.org/2036863002
Cr-Commit-Position: refs/heads/master@{#398088}

Many executables are missing embedded manifest files when built with gn.
This causes OS compatibility information to be omitted which can lead
to strange behavior. This adds manifests to two executables.

TBR=reed@google.com
BUG=602505

Review-Url: https://codereview.chromium.org/2021113003
Cr-Commit-Position: refs/heads/master@{#398087}

TBR=dgozman

Review-Url: https://codereview.chromium.org/2038363003
Cr-Commit-Position: refs/heads/master@{#398086}

In some situations the same JniClient will be used for multiple connections
where ConnectToHost()->DisconnectFromHost()->ConnectToHost() will be called.

In ConnectToHost() we DCHECK !secret_fetcher_ but don't release it in
DisconnectFromHost(), which fails the DCHECK.

This CL solves this problem by resetting |secret_fetcher_| in
DisconnectFromHost(). However, we still need to investigate why JniClient
is being used for multiple connections.

BUG=617471

Review-Url: https://codereview.chromium.org/2046663002
Cr-Commit-Position: refs/heads/master@{#398085}

Revert of In official builds, let CHECK(false) crash instead of calling BreakDebugger. (patchset #2 id:20001 of https://codereview.chromium.org/1982123002/ )

Reason for revert:
Unfortunately crrev.com/1982123002 causes loss of
crash reports on Android arm64 (and supposedly also CrOS).
This is because __builtin_trap() raises a SIGILL on x86 and
arm but SIGTRAP on arm64. Breakpad does not handle SIGTRAP (yet).
Temporarily reverting this CL until SIGTRAP support for breakpad lands.

BUG=599867,614865

Original issue's description:
> In official builds, let CHECK(false) crash instead of calling BreakDebugger.
>
> This should save some binary size and make things a bit faster, without ill
> effects.
>
> See bug comment 15, and brettw's and my comments on
> "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation"
>
> BUG=599867
>
> Committed: https://crrev.com/481a8ec8b24df24795c63fd4ec26f3670d516db8
> Cr-Commit-Position: refs/heads/master@{#394035}

TBR=danakj@chromium.org,thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=599867

Review-Url: https://codereview.chromium.org/2046593002
Cr-Commit-Position: refs/heads/master@{#398084}

Since AudioCodecBridge::ConfigureAndStart creates AudioTrack
instance with config parameters, we need to initialize the
output parameters with the same values before we get
OnOutputFormatChanged().

Without this step the some changes between config and actual
parameters will be undetected, for instance before this change
(1) config_num_channels = 2, output_num_channels = 2
      old output value was 0, unnecessary AudioTrack recreation
(2) config_num_channels = 1, output_num_channels = 2
      old output value was 2, no change detected here but
      AudioTrack was created with num_channels = 1

BUG=none

Review-Url: https://codereview.chromium.org/2042563002
Cr-Commit-Position: refs/heads/master@{#398083}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=maxbogue@chromium.org

Review-Url: https://codereview.chromium.org/2033933002
Cr-Commit-Position: refs/heads/master@{#398082}

This was an error in the refactoring at https://codereview.chromium.org/1323313004.

BUG=615056

Review-Url: https://codereview.chromium.org/2042623002
Cr-Commit-Position: refs/heads/master@{#398081}

There seems to be nothing called InspectorFrontend. Removed unused
forward declarations for it and changed comments to say "frontend"
instead.

R=pfeldman@chromium.org,dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2046433002
Cr-Commit-Position: refs/heads/master@{#398080}

FontDataCache's key data type was a full FontPlatformData object, not a
pointer to one The value type of that cache is a SimpleFontData object,
which in itself stores a FontPlatformData object type.

If we want to manage memory related to font blobs (OpenType tables, web
font file buffers) we need to come to a situation where the lifecycle of
FontPlatformData objects is absolutely clear.

Previously, adding to the FontDataCache meant one copy of
FontPlatformData for the cache key, and one for the value as an owned
member of SimpleFontData.

In this situation, it is much harder to keep track of where we keep
FontPlatformData objects.

FontPlatformData objects keep a RefPtr<HarfBuzzFace>, which in turn
keeps hb_font objects, which keep references to OpenType tables copied
from Skia. If we cannot destroy FontPlatformData objects after use, we
cannot free the corresponding copied OpenType tables - so over the
lifetime of the renderer we're leaking OpenType table data for stale
FontPlatformData objects.

This is a first step towards fixing this situation and gaining better
control over the lifecylce of FontPlatformData objects.

BUG=617568
R=eae,tzik,bashi

Review-Url: https://codereview.chromium.org/2031363002
Cr-Commit-Position: refs/heads/master@{#398079}

Separate clip rect and visible rect calculation so visible rect logic
would be easier to follow.

R=ajuma
BUG=594675
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2008283003
Cr-Commit-Position: refs/heads/master@{#398078}

Adds a test to make sure sequential navs are handled correctly, and also add histogram checks to all tab helper tests.

BUG=589526

Review-Url: https://codereview.chromium.org/2040573002
Cr-Commit-Position: refs/heads/master@{#398077}

Context:
This bot has not been running for about 2 months now. When it was running it did not generate any useful alerts.
These files were originally added in https://codereview.chromium.org/1410353007/

# Failing with missing LGTM from OWNER for chrome/ct_top1k.isolate even though M-A LGTM'ed.
TBR=maruel

BUG=skia:4503

Review-Url: https://codereview.chromium.org/2039973002
Cr-Commit-Position: refs/heads/master@{#398076}

MediaStreamDispatcher::OnDeviceStopped() may delete the same element
twice from |label_stream_map_| and causes the crash.

BUG=616884

Review-Url: https://codereview.chromium.org/2035993002
Cr-Commit-Position: refs/heads/master@{#398075}

Account now switches when focus changes, not just updated wallpaper.

BUG=614926

Review-Url: https://codereview.chromium.org/2035753003
Cr-Commit-Position: refs/heads/master@{#398074}

The previous CL was built around a test case I had made myself (there was no real life example). I found one and realized the type should be "text" and not "input".

Related CL: https://codereview.chromium.org/2025063002/

BUG=616174
TEST=AutofillFieldTest

Review-Url: https://codereview.chromium.org/2041863003
Cr-Commit-Position: refs/heads/master@{#398073}

The extension TabHelper can have an associated extension if the
WebContents holds a hosted app. Watch for that extension being
unloaded and reset the reference to the extension if it is so that
we don't UAF it.

BUG=616057
BUG=616113

Review-Url: https://codereview.chromium.org/2037873002
Cr-Commit-Position: refs/heads/master@{#398072}

The name content::VideoFrameProvider was easy to cause confusion with
cc:VideoFrameProvider. Furthermore, the methods provided in the
content::VideoFrameProvider are not specific to Video, which makes the
name somewhat unsuitable.

List of changes:
* Moved the typedef content::VideoFrameProvider::RepaintCB out to a new
  file and renamed it to VideoFrameCallback.
* Renamed interface VideoFrameProvider to PausableStream
* Renamed method Play() to Resume()

BUG=526835

Review-Url: https://codereview.chromium.org/2005053006
Cr-Commit-Position: refs/heads/master@{#398071}

This is just a mechanical rename and reformat. The rename is good because:

 1) WebUI::CallJavascriptFunctionUnsafe is indeed unsafe and the caller
    is responsible for knowing when it is safe to call.

 2) WebUIMessageHandler::CallJavascriptFunction is the new preferred way.

 3) The change makes the above two points clear to coders not to use
    WebUI directly unless they know what they are doing.

In the future, WebUI::CallJavascriptFunctionUnsafe may become a private
member with a few friend classes.

See design doc for more details:
https://docs.google.com/a/chromium.org/document/d/1z1diKvwgMmn4YFzlW1kss0yHmo8yy68TN_FUhUzRz7Q/edit?usp=sharing

BUG=602523

Review-Url: https://codereview.chromium.org/1995113002
Cr-Commit-Position: refs/heads/master@{#398070}

BitmapUploader is needed only for chrome when it uses software rendering. So
instead of always creating a BitmapUploader (which creates an extra surface for
the window) for every widget, create it only when needed.

BUG=none

Review-Url: https://codereview.chromium.org/2040453002
Cr-Commit-Position: refs/heads/master@{#398069}

Reject calcs with both lengths and percentages in radial-gradient,
while for ellipse both length and percentage are allowed, they are
not allowed at the same time [1].

[1] https://drafts.csswg.org/css-images-3/#radial-gradients

Review-Url: https://codereview.chromium.org/1935173002
Cr-Commit-Position: refs/heads/master@{#398068}

In https://codereview.chromium.org/2025393003/ I moved the visualViewport object
from document onto window but forgot to move the event to fire on the window
instead.

BUG=595826

Review-Url: https://codereview.chromium.org/2034313002
Cr-Commit-Position: refs/heads/master@{#398067}

BUG=none
TEST=covered by tests
R=jamescook@chromium.org

Review-Url: https://codereview.chromium.org/2033843003
Cr-Commit-Position: refs/heads/master@{#398066}

Revert of Suppress -Wnonportable-include-path on clang tot bots (patchset #2 id:20001 of https://codereview.chromium.org/2040533003/ )

Reason for revert:
The Clang warning was removed again in r271761.

Original issue's description:
> Suppress -Wnonportable-include-path on clang tot bots
>
> BUG=617318
> R=hans@chromium.org
>
> Committed: https://chromium.googlesource.com/chromium/src/+/2bc751024e4ddf3f50594abdbf3c54b77df84562

TBR=thakis@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=617318

Review-Url: https://codereview.chromium.org/2043813002
Cr-Commit-Position: refs/heads/master@{#398065}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=danakj@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2034913002
Cr-Commit-Position: refs/heads/master@{#398064}

Revert of Specify direct dependency of //components/crash on kasko_features.h (patchset #1 id:1 of https://codereview.chromium.org/2038473002/ )

Reason for revert:
It's breaking the official win-asan builder (https://uberchromegw.corp.google.com/i/official.desktop/builders/win-asan/builds/268)

Original issue's description:
> Specify direct dependency of //components/crash on kasko_features.h
>
> //components/crash/content/app has a public dependency on the generated
> header kasko_features.h. However, the GYP and GN files specify this
> dependency only transitively via a dependency on //third_party/kasko
> (which //components/crash/content/app does not actually depend on). This
> CL changes the dependency to be directly on
> //third_party/kasko:kasko_features as a speculative fix for the build
> failures listed in crbug.com/611319. Note that in any case this change
> is correct (whether it ends up resolving the flaky build failures or no).
>
> BUG=611319
> TBR=pmonette
>
> Committed: https://crrev.com/d507af25f7281161a3eb0d44a0deef057e46c8dc
> Cr-Commit-Position: refs/heads/master@{#397390}

TBR=mark@chromium.org,pmonette@chromium.org,blundell@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=611319

Review-Url: https://codereview.chromium.org/2047473002
Cr-Commit-Position: refs/heads/master@{#398063}

MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon
are deprecated. This CL makes the following replacements to
remove some uses of these methods:

"MessageLoop(ForUI|ForIO)::current()->PostTask" ->
  "ThreadTaskRunnerHandle::Get()->PostTask"
"MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" ->
  "ThreadTaskRunnerHandle::Get()->PostDelayedTask"
"MessageLoop(ForUI|ForIO)::current()->DeleteSoon" ->
  "ThreadTaskRunnerHandle::Get()->DeleteSoon"
"MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" ->
  "ThreadTaskRunnerHandle::Get()->ReleaseSoon"

In files where these replacements are made, it adds these includes:
  #include "base/location.h"
  #include "base/single_thread_task_runner.h"
  #include "base/threading/thread_task_runner_handle.h"

And removes this include if it is no longer required:
  #include "base/message_loop/message_loop.h"

Why ThreadTaskRunnerHandle::Get() instead of
MessageLoop::current()->task_runner()?
 - The two are equivalent on threads that run a MessageLoop.
 - MessageLoop::current() doesn't work in base/task_scheduler
   because the scheduler's thread don't run MessageLoops.
   This CL will therefore facilitate the migration of browser
   threads to base/task_scheduler.

Steps to generate this patch:
1. Run message_loop_cleanup.py (see code on the bug).
2. Run tools/sort-headers.py on modified files.
3. Run git cl format.

BUG=616447
R=garykac@chromium.org

Review-Url: https://codereview.chromium.org/2031083002
Cr-Commit-Position: refs/heads/master@{#398062}