This IPC was used for tests to synchronize with the renderer from the
browser process. The RenderFrameSubmissionObserver does this job for
us instead now and does not rely on legacy mojo or test-only IPCs. This
CL converts the 3 test cases relying on the old IPC over to use the
RenderFrameSubmissionObserver utility instead.
R=avi@chromium.org, rouslan@chromium.org
Bug: 419087
Change-Id: I61d3cf37f55bfbbf97e73f8523605613d4e9be39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1787406
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Rouslan Solomakhin <rouslan@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694304}
The vulnerability indicated in crbug.com/995964 suggests that the core
issue relates to the assumption that device_start_request_queue_ can
only contain one occurrence of a controller while this might not be the
case.
This change makes sure that all occurrence of a controller are removed
from the list, instead of removing only the first found.
BUG=995964
Change-Id: Ice2a1da37d13339128d3d52d25daa252c5d61155
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1784726
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Armando Miraglia <armax@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694255}
This CL replaces the usage of unretained pointers with weak pointers
in VideoCaptureManager.
This conversion is safe because all places where the pointers are saved
are on the IO thread as well as the place were the callbacks are then
executed (see line 326 and 348).
BUG=998548
Change-Id: I47bda798fa7bcbd66bf23682ee6c6dd26b5642c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1789223
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Commit-Queue: Armando Miraglia <armax@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694214}
.. to avoid SMB exhaustion during the commit. System trace data could
get lost since we switched to kDrop mode (and was susceptible to
deadlocks before).
With this patch, we commit the data in smaller batches and wait for an
acknowledgement from the perfetto service before committing the next
batch.
Bug: 998940
Change-Id: Ic38a07a3d91f5798f074ac67d25e06a2026dbea3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1782620
Commit-Queue: Eric Seckler <eseckler@chromium.org>
Reviewed-by: oysteine <oysteine@chromium.org>
Reviewed-by: Yury Khmel <khmel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694199}
For the initial version of the BackForwardCache, we want to store only
one document per tab to minimize memory usage.
As part of this change the test SubframeSurviveCache4 was deleted,
because the scenario it covers is no longer possible with a cache size
of 1.
Change-Id: I9dacb0c2c81c3266310f65f06337f72865ae6351
Bug: 1000658
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1782902
Commit-Queue: Lowell Manners <lowell@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694195}
In addition to the histogram: Navigation.IsSameProcess
Add the histograms: Navigation.IsSameSiteInstance
Navigation.IsSameBrowsingInstance
During a navigation, getting a new SiteInstance do not necessarily
implies switching processes. This new histograms will help to
understand the effects of some experiments like
ProactivelySwapBrowsingInstance.
Bug: 977562
Change-Id: Ib598f67fcfe1dd9aab45fa2e2250d3fa300fce41
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1776050
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694185}
This CL implements is phase 2.5 on the design document [1].
[1] https://docs.google.com/document/d/1AJKVA5U4nDkyDB9p4ROrggWXadCxyy-grKaE9KS5vOU/
Basically, it moves transmission_encoding_info_handler.cc|h directly to
renderer/platform/peerconnection, as well as its respective unit test.
It also removes the blink::Platform::TransmissionEncodingInfoHandler()
and its overrides, now that Blink does not need to access content/ for such
functionality.
What is left for a follow up CL is the removal of the base class
WebTransmissionEncodingInfoHandler [2], which became unneeded.
[2] //third_party/blink/public/platform/web_transmission_encoding_info_handler.h
BUG=787254
R=guidou@chromium.org, haraken@chromium.org
Change-Id: I47f151fcfd67a9ae1a5c7e58bcf03b7ae3017664
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1785162
Auto-Submit: Antonio Gomes <tonikitoo@igalia.com>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694180}
Currently we use "trustable-bundled-exchanges-file" flag to specify
trustable WBN file path for testing. But always calling
net::FilePathToFileURL() in NavigationRequest is nonsense. So this CL
change the flag to use URL, and stop always calling FilePathToFileURL()
in NavigationRequest.
TBR=tmartino@chromium.org
Bug: 966753
Change-Id: I5afb17fedd432dc7793b44711ee075e5fc9318b6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1787491
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694177}
This change ensures that URLs blocked by CSP commit with opaque origins
that contain precursor information consistent with the blocked URL.
This will allow the precursor information to be verified at commit time
in a follow-up CL.
Bug: 991607
Change-Id: I239d1a7ec07917de6a79c3074a61ab0b47ed7d8b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1785498
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694171}
After this patch, range requests to a bundled entry will return a 206
(partial content) response with the requested byte range.
This makes media contents (videos, etc.) in bundles work more
efficiently.
Bug: 1001366
Change-Id: I9037a94ef6a08a4c125e9128af8ce99904ec45fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1787479
Commit-Queue: Kunihiko Sakamoto <ksakamoto@chromium.org>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694162}
Relanded after startup scheduling order for DWriteFontLookupTableBuilder
was fixed and a callback to retrieve the caching directory was added to
ShellContentBrowserClient so that content_shell knows where to cache
the font lookup table and layout tests accessing local() fonts do not
time out.
In order to test DWriteFontLookupTableBuilder a cache directory is
configured for persisting the built table. The same happens when a full
browser runs with a profile - in which case a subdirectory of the
USER_DATA directory is used. Do not scan fonts if a directory is not
configured.
This situation happens in unit tests in tests other than the
DWriteFontLookupTableBuilder unit tests, as ContentClient and
BrowserClient do not return a path for GetFontLookupTableCacheDir() in
testing. It is sufficient to test DWriteFontLookupTableBuilder in its
own unittests. If local unique font matching on Windows 7 is required in
a unit test, a cache directory can be configured using
DWriteFontLookupTableBuilder::GetInstance()->
SetCacheDirectoryForTesting(...)
Thanks to etienneb@ for identifying this problem and initial fix proposal.
Bug: 996167
Change-Id: Ib538dabfa02a1b59517d6535c2b6d9a74cc07a64
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1777862
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694141}
This CL fixes a bug that happens only on Pixel 3 XL in landscape mode.
- Chrome does not use the large notch area around the top that goes to
left side in landscape mode. This makes screen/view x coordinate
different. The correct coordinate to use for touch event is view
coordinate, not the screen one being used in OverscrollScroller.
- SideSlideLayout calls getMeasuredWidth() at the beginning (right
after being attached) to find correct position of the navigation
bubble when swiped from right. It somehow still returns the width
in portrait mode (== height in landscape) and causes the arrow to
position somewhere in the middle of the screen. Got around this
problem by using the width of the parent view instead. This makes
some init logic simpler.
Bug: 999572
Change-Id: I36ea8f56531686877a9cd5831570959e85788b67
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786391
Commit-Queue: Jinsuk Kim <jinsukkim@chromium.org>
Reviewed-by: Donn Denman <donnd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694135}
GN check fails with plugins disabled since
b2090049ba ("Accessibility action handling pipeline for plugins")
with the following error:
ERROR at //content/public/test/fake_pepper_plugin_instance.cc:8:11: Include not allowed.
^------------------------------------
It is not in any dependency of
//content/test:test_support
The include file is in the target(s):
//ppapi/shared_impl:shared_impl
which should somehow be reachable.
Fix it by removing fake_pepper_plugin_instance.cc when plugins are
disabled.
Bug: 1001367
Test: gn gen --check out/chromecast_rel --args='is_chromecast=true
is_component_build=false is_debug=false'
Change-Id: Ic1472ad263a2be56a73d84588d908fcad0933236
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1783711
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Auto-Submit: Michael Spang <spang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694112}
Previously we return a URLLoaderFactory without going through embedder's
interception logic (e.g. Extensions). This might cause confusing behavior.
This CL is to return nullptr in that case in order to abort update checking
consistently.
Bug: 648295
Change-Id: Ia8b0d517c21df60aa0abcbbb1d4aea6f9d58e514
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786519
Commit-Queue: Makoto Shimazu <shimazu@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694104}
This CL converts OOPIFs from using a compositor viewport that is the
entire size of the content layer, to a much smaller one based on the
visible intersection of the OOPIF's content with its parent's viewport.
This should decrease compositor resources used by the OOPIF, and
prevent excessively large tiles being produced.
Bug: 852348
Change-Id: I27977e2513d727bc6ba1a414504157cef3436a03
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1778362
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694066}
The original CL (crrev.com/c/1730889) was reverted because it
seemed to break some extension browser_tests on MSAN bot.
The issue was addressed by crrev.com/c/1775892.
The difference between the original CL and this CL are:
* Using thread pool instead of the IO thread. This change comes from
crrev.com/c/1768490
* Using mojo type adapter. This change is required due to
crrev.com/c/1757604
Original description:
This is practically a revert of https://crrev.com/c/1053042.
The previous change was made to ensure user agent is set for
RenderThreadImpl before creating service workers. However,
service worker code path doesn't rely on RenderThreadImpl's
user agent. User agent is passed as a part of
EmbeddedWorkerStartParams. We don't need to use mojo::Renderer
interface to create EmbeddedWorkerInstanceClient.
This change allows us to choose the thread to create
EmbeddedWorkerInstanceClient, which is a requirement for
off-the-main-thread service worker startup.
Bug: 692909
Change-Id: I96c348ff186254a29a58d0d16faa938f1b0aa272
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1758031
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694027}
This CL is to support pointerlock unadjusted movement.
The api is added at crrev.com/c/1764943 behind flag.
This CL adds a is_raw_movement_event bit in web_pointer_properties
to indicate this event is has unadjusted movement value from OS.
The bit is set when the corresponding ui::Event has the EF_RAW_MOVEMENT
flag. It needs to be set for other native events type once we add
support on other platform.
When the bit is set, do not scale mouse/pointer event movementx/y
and use the value to dom event directly.
Bug: 982379
Change-Id: Ib96dda28a4ba352e0dbe09fa18e5d6959271f5c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1770076
Commit-Queue: Ella Ge <eirage@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694012}
The main goal is to compare memory usage of Chrome in Reduced Mode and
Full Browser. To make a fair comparison, the situations measured need
to be the same ones. Only background tasks that may run in either Full
Browser or Reduced Mode trigger the measurement.
Memory usage is measured and emitted once, with a random (0-60s) delay
after the background task starts. The range of the delay is chosen to
catch the execution of a background task at various steps.
The metrics are emitted only once so that the average does not
converge towards the memory usage after the task is executed.
This CL adds the following histograms:
- Memory.BackgroundTask.Browser.ResidentSet.(FullBrowser|ReducedMode)
- Memory.BackgroundTask.Browser.PrivateMemoryFootprint
.(FullBrowser|ReducedMode)
- Memory.BackgroundTask.Browser.SharedMemoryFootprint
.(FullBrowser|ReducedMode)
- Memory.BackgroundTask.Browser.PrivateSwapFootprint
.(FullBrowser|ReducedMode)
- Memory.BackgroundTask.OfflinePrefetch.Browser.ResidentSet
.(FullBrowser|ReducedMode)
- Memory.BackgroundTask.OfflinePrefetch.Browser.PrivateMemoryFootprint
.(FullBrowser|ReducedMode)
- Memory.BackgroundTask.OfflinePrefetch.Browser.SharedMemoryFootprint
.(FullBrowser|ReducedMode)
- Memory.BackgroundTask.OfflinePrefetch.Browser.PrivateSwapFootprint
.(FullBrowser|ReducedMode)
Bug: 993832
Change-Id: Ifbe87c0eb5842d6494b558d13b671647f257f6d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1761055
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Reviewed-by: Xi Han <hanxi@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694006}
Extensions use legacy IPC but service workers use Mojo for IPCs. There
is no ordering guarantee between them. This means that a service worker
could run before onloaded message is received.
This was problematic for extension background service workers.
They expect extension APIs are available at the beginning but until
onloaded message is received we can't install extension API bindings.
This CL suspends service workers until extensions' onloaded message is
received. This way we can make sure that extension APIs are available
on background service workers at the beginning.
Bug: 995134
Change-Id: I9bb5e3b9292d783936ae919388f72ed4b4c7c3a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1775892
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#694003}
RenderFrameImpl::CreateFrame() creates a new RenderWidget for a child
frame, but for the main frame it only starts the compositor. Instead,
have it unfreeze the main frame RenderWidget, bringing it to life in
the same way that child frames do.
Similarly, RenderFrameImpl::FrameDetached() destroys the RenderWidget
for a child frame, which is kept alive until that point. But for a
main frame the RenderWidget is frozen at the point of SwapOut instead.
Change SwapOut to not branch for main frames, and wait for
FrameDetached to freeze the main frame's RenderWidget where the child
frame's RenderWidget is destroyed.
This matches the main frame's frozen/thawed times to child frames'
created/destroyed times.
Then RenderFrameProxy no longer needs a main frame special case to
freeze the RenderWidget, since even if SwapOut is missed due to
aborting a navigation, RenderFrameImpl::OnDelete would have run which
detaches the frame and would have frozen the RenderWidget.
Since we unfreeze the RenderWidget as soon as the provisional
RenderFrame exists, we no longer need to WarmUpCompositor() and
all the logic for that may go away in RenderWidget.
All logic in RenderWidget around is_frozen_ is split to become
is_frozen_ || IsForProvisionalFrame() which matches the same time
periods. It seems important to keep both because the RenderWidget can
go thawed->frozen->provisional before some event happens, so checking
frozen only is not enough. One exception is during initialization,
where the RenderWidget is never for a provisional frame, it is either
for a local frame (not frozen) or for a remote frame (frozen).
R=dcheng@chromium.org
Bug: 419087, 745091
Change-Id: Id11beef5fc7cd4ec7eb960e84ea1e97cc33d93ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1693812
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693987}
If the renderer process crashes while running a nested message loop to drive the
popup, then the RenderFrameHostImpl pointer may no longer be valid. The class
tried to listen for destruction via RenderWidgetHost destruction, but the
lifetime of RenderFrameHost is not tied to the lifetime of RenderWidgetHost for
child frames.
Bug: 1000035
Change-Id: I65043cdfaa211911cabf94034841e775b6b481fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1779380
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Auto-Submit: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693983}
When a transaction is aborted, it clears its locks but it doesn't remove
the lock request. If a transaction hadn't been granted its locks yet,
then the lock request would still be active after the abort.
This change fixes this by also clearing the lock request during the
Abort call.
R=cmp@chromium.org
Bug: 999769
Change-Id: Ia1abd76dbe023f401ab27fb3ac89c6fc8aef2ecb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786865
Reviewed-by: Chase Phillips <cmp@chromium.org>
Commit-Queue: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693979}
Currently, a non-sandbox GPU process for the GPU info collection is launced
15 seconds after the browser starts. From the GPU watchdog crash reports, many
systems are still busy within the first 30 seconds of the GPU process launch.
Running a second GPU process during this period will make the system even
busier. Therefore, the delay is now extended from 15 seconds to 120 seconds.
The side effect of this delay is DX12/Vulkan won't be available in about:gpu
in the first 120 seconds. This will be fixed in the other CL.
TBR=jochen@chromium.org
Bug:949839
Change-Id: Ib21531f2ae8757199878f810ea33536d373081e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1783108
Commit-Queue: Maggie Chen <magchen@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693948}
These tests were previously migrated from single-threaded MessageLoop to
a multi-threaded TaskEnvironment (then named ScopedTaskEnvironment) as
part of crbug.com/891670.
//base OWNERS decided in retrospect that it was better to keep a
single-threaded option for TaskEnvironment and introduced
SingleThreadTaskEnvironment. This CL retrofits that decision for
/content/browser/renderer_host/input.
This CL is a no-op if it passes CQ.
This CL was uploaded by git cl split.
R=tdresser@chromium.org
Bug: 891670
Change-Id: I178884fcf70f05b71f828abb8c5648fb187d99ca
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786781
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Commit-Queue: Timothy Dresser <tdresser@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693933}
While timeout scaling is still needed in some spots that don't use
CriteriaHelper/CallbackHelper, having these commonly-used helpers
apply the scaling should reduce the number of spots where tests
forget to scale their own timeouts.
Bug: 1001106
Change-Id: Iff9891916cb5c22227208abc48677c7d91698e69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1723422
Reviewed-by: David Trainor <dtrainor@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693930}
These tests were previously migrated from single-threaded MessageLoop to
a multi-threaded TaskEnvironment (then named ScopedTaskEnvironment) as
part of crbug.com/891670.
//base OWNERS decided in retrospect that it was better to keep a
single-threaded option for TaskEnvironment and introduced
SingleThreadTaskEnvironment. This CL retrofits that decision for
/content/renderer/pepper.
This CL is a no-op if it passes CQ.
This CL was uploaded by git cl split.
R=bbudge@chromium.org
Bug: 891670
Change-Id: Idca36fd4180c5e8047274ffb141a074562413e71
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786807
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693924}
This CL makes the pointer lock request also pass the
PointerLockOption.unadjustedMovement (added in crrev.com/c/1764943)
to browser with the pointerlock request IPC.
It stores the boolean mouse_lock_raw_movement_ in RWHI whenever
receive the OnLockMouse IPC, and use on GotResponseToLockMouseRequest.
Storing the value because passing the boolean to RequestToLockMouse
will get into too many code path. RWHI.GotResponseToLockMouseRequest()
is the only caller to RWHV.LockMouse(), and RWHV.LockMouse is the
only place that locks mouse.
Bug: 982379
Change-Id: Ia930960bb3c16e249e26e154430c62a9bf06b8eb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1767098
Commit-Queue: Ella Ge <eirage@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693894}
These tests were previously migrated from single-threaded MessageLoop to
a multi-threaded TaskEnvironment (then named ScopedTaskEnvironment) as
part of crbug.com/891670.
//base OWNERS decided in retrospect that it was better to keep a
single-threaded option for TaskEnvironment and introduced
SingleThreadTaskEnvironment. This CL retrofits that decision for
/content/browser/fileapi.
This CL is a no-op if it passes CQ.
This CL was uploaded by git cl split.
R=mek@chromium.org
Bug: 891670
Change-Id: Id40fcab691f3126d75b96599b381d622f6c6cc11
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1786814
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#693848}
