The GpuChannel is lost in the GPU crash. The GpuChannelLost observer NotifyGpuContextLost to restore the context and recreate Canvas resource
provider.
Remove RendererBlinkPlatformImpl::CreateSharedImageInterfaceProvider().
SharedImageInterfaceProvider is now created directly inside
SharedGpuContext. It doesn't need to use the platform proxy.Also move
webgraphics_shared_image_interface_provider_impl.cc from
content/renderer to third_party/blink/renderer/platform/graphics/gpu
because it's directly called from Blink/ instead of content/.
Update SharedGpuContext::CreateSharedImageInterfaceProviderIfNeeded()
so WebGraphicsSharedImageInterfaceProviderImpl ctor and the
GpuChannelLost notification is called on the same thread where
SharedImageInterfaceProvider is requested.
Bug:40064122
Change-Id: Ieea951b7ff6fb214e821f84d9a945280f2822119
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5770840
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1345023}
There is an existing WebUICodeCache flag (defined in
content/public/common/content_features) that is used to enable code
caching for WebUI scripts for all chrome:// and chrome-untrusted://
resources.
This is currently disabled by default as experiments showed mixed
results for performance improvements (different impacts across
different WebUI pages, some improved significantly some regressed).
This CL introduces a WebUIRestrictedCodeCache param that can be
enabled alongside the existing WebUICodeCache flag. When enabled
this param restricts use of the generated code cache for WebUI to a
subset of targeted scripts that are expected to benefit most from
the code caching feature. Initially this will only target Tab
Search script resources.
blink::Platform::ShouldUseCodeCacheWithHashing has been added to
allow embedders to conditionally restrict which hashed code cache
resources should use the cache.
Bug: 358193008, 359335784
Change-Id: I2f7467b8eaa984d0c2863c5bacfa5b32486adfa7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5773687
Commit-Queue: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1340840}
This CL replaces SharedBitmap with SharedImage in CanvasResourceSharedBitmap.
1. Add new classes WebGraphicsSharedImageInterfaceProvider,
WebGraphicsSharedImageInterfaceProviderImpl..
2. RendererBlinkPlatformImpl creates GpuChannelHost,
ClientSharedImageInterface, and then
WebGraphicsSharedImageInterfaceProvider for SharedGpuContext.
3. In the software rending mode, SharedGpuContext creates and provides
OffscreenCanvas with WebGraphicsSharedImageInterfaceProvider
which is later used for creating ClientSharedImage for
CanvasResourceSharedBitmap.
4. WebGraphicsSharedImageInterfaceProviderImpl observes GpuChannelLost
and destroys ClientSharedImageInterface in the event of lost.
The feature is behind the flag CanvasSharedBitmapToSharedImage and is
disabled by default.
Bug: 40064122
Change-Id: I081bc0723eb666706046618885809db21ee088f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5490840
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1333200}
The GPU channel cannot be established when gpu_remote is disconnected.
Stop calling RequestNewLayerTreeFrameSink because it's going to fail
again and it will be stuck in a forever loop of retries. This makes the
processes unable to be killed after Chrome is closed.
Bug: 336164423
Change-Id: Ie7db1df5531e178b2d06063c10c23ded917217b8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5676887
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1323390}
This CL enables VisitedLinkState to query for partitioned :visited links when the feature flag is enabled. This requires VisitedLinkState to determine the triple-partition key for each link query, where VisitedLinkReader will match each key with its corresponding per-origin salt before calculating its corresponding fingerprint. If the fingerprint is present in the VisitedLinkReader's hashtable, the link will be styled as visited.
Bug: 345525059
Change-Id: Ib56f93a0f3ea34f62258cf75b2d334dac73334c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5564325
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Commit-Queue: Kyra Seevers <kyraseevers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1315197}
blink::WebURLRequest is used for the argument of
URLLoaderThrottleProvider::CreateThrottles() method after [1]. But we
are planing to call this method from the background thread where we
don't use blink::WebURLRequest [2]. Also we are planing to deprecate
blink::WebURLRequest, and planing to use network::ResourceRequest
instead [3].
So this CL changes the argument type of CreateThrottles() from
blink::WebURLRequest to network::ResourceRequest.
A network::ResourceRequest is created in ResourceLoader::Start(). So we
pass the reference of the structure through ResourceFetcher::
CreateURLLoader().
In frames:
ResourceLoader::Start()
-> ResourceFetcher::CreateURLLoader()
-> LoaderFactoryForFrame::CreateURLLoader()
|-> URLLoaderThrottleProvider::CreateThrottles()
|-> ServiceWorkerNetworkProviderForFrame::
| GetSubresourceLoaderFactory()
|-> URLLoaderFactory::CreateURLLoader()
In workers:
ResourceLoader::Start()
-> ResourceFetcher::CreateURLLoader()
-> LoaderFactoryForWorker::CreateURLLoader()
|-> WebWorkerFetchContext::CreateThrottles()
| -> WebServiceWorkerFetchContextImpl::CreateThrottles() or
| DedicatedOrSharedWorkerFetchContextImpl::CreateThrottles()
| -> URLLoaderThrottleProvider::CreateThrottles()
|-> URLLoaderFactory::CreateURLLoader()
mojom::blink::RequestContextType in blink::WebURLRequest is checked in
the code path. But this type member is not in network::ResourceRequest.
network::ResourceRequest has a network::mojom::RequestDestination
member. And some of these checks of mojom::blink::RequestContextType can
be safely converted to network::mojom::RequestDestination without any
behavior change. But the check in ResourceFetcher::CreateURLLoader()
needs the mojom::blink::RequestContextType. Also we need to pass
`service_worker_race_network_request_token` to
LoaderFactoryForWorker::CreateURLLoader(), and
`is_from_origin_dirty_style_sheet` flag to
ServiceWorkerNetworkProviderForFrame::GetSubresourceLoaderFactory().
So this CL adds these three arguments to CreateURLLoader() methods.
[1]: https://crrev.com/c/994152
[2]: https://crrev.com/c/5113665
[3]: https://groups.google.com/a/chromium.org/forum/#!topic/platform-architecture-dev/ntSzerId4gw
Bug: 1379780
Change-Id: I6e0a987d779b1fb428a4b27b813b3f53f2d1d781
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5121813
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: David Song <wintermelons@google.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1245656}
When a main thread isolate is created ask the platform whether it should
start in the background state or not. Extension processes always start
in the background state to conserve memory.
Bug: 263412
Change-Id: Ieb7e2c8854dc0de63f580ea53f61bfa5cda72514
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5078440
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1233413}
Change attribution support to be web_contents specific to support the
disabled option for WebView. This change ensures that when attribution
reporting is disabled for WebView, no calls are made (previously the
initial calls to the attribution server were made, although the result
was not logged).
OBSOLETE_HISTOGRAM[Conversions.AttributionSupport]=Replaced by Conversions.AttributionOsLevelApiState and Conversions.AttributionBehavior
Fixed: 1492081
Test: AttributionReportingTest
Change-Id: I0a1aceca88805a8446691aee98e2e5b7716dadb9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4966783
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Joanne de Abreu <jdeabreu@google.com>
Reviewed-by: Nan Lin <linnan@chromium.org>
Auto-Submit: Joanne de Abreu <jdeabreu@google.com>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Elly FJ <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1217264}
Protocol Handler specifies that only URLs with HTTP/HTTPS schemes are
allowed to be registered as Protocol handlers. However non-web URLs like
chrome-extension:// and isolated-app:// should be an exception to this.
This CL creates a new ProtocolHandlerSecurityLevel kSameOrigin that
allows the registration of protocol handler URL of non-HTTP(S) scheme
(while still within the same origin as the requesting frame). Currently,
only "isolated-app" schemed URLs are granted this security level.
Bug: 1484037
Change-Id: I94f87b065f45c2d1a6dbeb5484e32c4f52f71761
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4872957
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Zelin Liu <zelin@chromium.org>
Reviewed-by: Gyuyoung Kim <gyuyoung@igalia.com>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Robbie McElrath <rmcelrath@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1207201}
This change is not intended to change any behavior. This is a
mediumweight rewrite applied primarily to renderer code, promoting a
bunch of `T*` into `raw_ptr<T>` (or `T&` to `raw_ref<T>`).
MiraclePtr is not yet generally enabled in the renderer process,
so this should only affect rewritten members by turning them into
no-op `raw_ptr` (thought to have negligible overhead).
Given the scope of the rewrite and the security benefits, we feel that
the binary size increase is unavoidable.
AX-Relnotes: n/a.
Binary-Size: Size increase is unavoidable (see above).
Bug: 1444624
Change-Id: I1cda6fe446b1a8552cb3c98c1afeae0f15218619
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4904523
Owners-Override: Keishi Hattori <keishi@chromium.org>
Commit-Queue: Kalvin Lee <kdlee@chromium.org>
Reviewed-by: Keishi Hattori <keishi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1203810}
This CL removes support User-Agent reduction origin trial for Javascript
API and all subresource requests. Make sure all context use the default
user-agent function instead of checking whether response has a valid
origin trial token on User-Agent reduction/deprecation origin trial.
This CL also refactor corresponding tests to make sure the user-agent
returns the correct value when reduction features turns on.
This CL cleans up other one-off code we introduced to completed the
user-agent reduction origin trial.
Change-Id: I3f1c3213feffc8f3fc7de8dc5c23b9090f498e3a
Bug: 1258063
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4557684
Reviewed-by: Ari Chivukula <arichiv@chromium.org>
Commit-Queue: Victor Tan <victortan@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1155100}
This is a refactoring CL that removes
`blink::mojom::ServiceWorkerFetchHandlerBypassOption
fetch_handler_bypass_option` from
CreateServiceWorkerSubresourceLoaderFactory. The param was introduced in
the previous CL [1], but it was unnecessary plumbing, we can pass
`mojom::blink::ServiceWorkerFetchHandlerBypassOption::kDefault` directly
to ControllerServiceWorkerConnector in
RendererBlinkPlatformImpl::CreateServiceWorkerSubresourceLoaderFactory.
[1] crrev.com/c/4451966
Bug: 1420517
Change-Id: Ifd4d3867b2b0c7f0e00d27b342255287b0a1c017
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4573500
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Shunya Shishido <sisidovski@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1152364}
The URL is just used for annotation purposes; there's no need to use
TopDocument() here, which is misleading in cross-process iframes, since
it returns the Document of the local root instead. Several other places
already pass the document URL instead of the "top" document URL, so this
brings <canvas> more in line with the other uses anyway.
Also rename the various parameters and places it's plumbed through to
remove "top" from the name.
Bug: 617677
Change-Id: I6e605f1fd16001a6cfdeda83cd80e514d1cbdc45
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4545273
Reviewed-by: Stephen Chenney <schenney@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1146207}
https://github.com/WICG/attribution-reporting-api/pull/758
Web attribution is explicitly disabled for WebView. This CL extends
the OS support enum to allow web attribution to be independently
configurable, and the Attribution-Reporting-Support header will
indicate the support level accordingly.
If neither web nor os-level attribution is enabled, background
attributionsrc requests will not be made, and
the Attribuiton-Reporting-Eligible header will not be set on requests.
Note that this applies even when kAttributionReportingCrossAppWeb
feature is disabled to avoid bandwidth waste.
A virtual function is added to ContentBrowserClient to allow WebView
to disable web attribution. A follow-up CL will enable OS support and
disable web support on WebView.
Note that we cannot add web tests for the NoWebOrOsSupport DevTools
issue type as there is no way to override the OS support value there.
Side note: when both web and OS are supported, the header is updated
to "os, web" to align with the explainer.
Bug: 1432278
Change-Id: Id53852ed2891755ff05b74ea025ce40f44c08956
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4413547
Reviewed-by: Andrew Paseltiner <apaseltiner@chromium.org>
Commit-Queue: Nan Lin <linnan@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1134960}
This CL enables ServiceWorkerBypassFetchHandler with the
`all_with_race_network_request` option (aka BestEffortServiceWorker) via
OriginTrial token.
We add the new option named
`ServiceWorkerFetchHandlerBypassOption::kRaceNetworkRequest` to
ServiceWorkerFetchHandlerBypassOption mojom, so that we can pass the
info that the loader should trigger RaceNetworkRequest from browser
to renderer. Once ServiceWorkerMainResourceLoader confirmed there is a
valid OriginTrial token, set
`ServiceWorkerFetchHandlerBypassOption::kRaceNetworkRequest`. Then
ServiceWorkerSubresourceLoader which is on a renderer side lookup
fetch_handler_bypass_option and dispatch RaceNetworkRequest.
Change-Id: I6d22bbcaee96e80d0e93b4f665e3d326d0c1ac71
Bug: 1420517
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4451966
Commit-Queue: Shunya Shishido <sisidovski@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Reviewed-by: Minoru Chikamune <chikamune@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1133597}
This is one of the first steps to move attribution reporting request
and response logic to network service. It also makes it easier to
enforce the properties that the header is set if and only if the
corresponding feature is enabled and when the
Attribution-Reporting-Eligible is also present.
The feature flag and the mojom type are moved to
//services/network/public to be used by //services/network, blink and
browser. We will investigate removing all knowledge of the OS support
value from the renderer in the future.
The OS support enum is added to the resource request types to be
populated to the network service layer.
We will likewise move setting the Attribution-Reporting-Eligible header
to the network service in a future CL.
Bug: 1375791, 1425083
Change-Id: I6d0dc6154230963b376477a74239115b64c6ffae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4426530
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Brendon Tiszka <tiszka@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: Nan Lin <linnan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1131961}
Add |inert_interval| finch parameter to the feature and modify the code
to see RAILMode changes on render processes. If the current RAIL mode is
loading or is just changed to be not loading, we will consider that the
render process is running OnLoad or DOMContentLoaded event handler. The
process requires memory to finish the event handlers. So wait inert
interval after loading is finished and dispatch memory pressure signals
if any requests are arrived during the inert interval.
Bug: 1393283
Change-Id: Id12458659437b9ba74b038f9c1847c7799982672
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4333318
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Takashi Sakamoto <tasak@google.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1120355}
Currently ExtensionLocalizationPeer is used to replace localization
templates in CSS files with the appropriate localized strings for
extensions [1].
ExtensionLocalizationPeer was introduced 13 years ago [2], and it is
using a mechanism of blink::WebRequestPeer to intercept and replace the
content body.
This mechanism of blink::WebRequestPeer is used only by
ExtensionLocalizationPeer now. And we can replace the content body using
the more widely used mechanism of blink::URLLoaderThrottle.
This CL introduces a new blink::URLLoaderThrottle named
ExtensionLocalizationThrottle, and replaces ExtensionLocalizationPeer
with it. This CL also removes the WebResourceRequestSenderDelegate which
is used only for ExtensionLocalizationPeer.
[1] https://developer.chrome.com/docs/extensions/reference/i18n/
[2] https://codereview.chromium.org/570007
Bug: 1417066, 1413912
Change-Id: I19b97bd745875f24f943d7cd9f93171de8ef627d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4257812
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: David Bertoni <dbertoni@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1109362}
This CL does the following:
1. Delete Platform::WrapURLLoaderFactory() method.
2. Make RenderThreadImpl::InitializeRenderer() call a new
blink::SetCorsExemptHeaderList() method which calls
blink::LoaderFactoryForFrame::SetCorsExemptHeaderList().
3. blink::LoaderFactoryForFrame::CreateURLLoader() and
PrefetchedSignedExchangeManager will create a WebURLLoaderFactory
using a new blink::LoaderFactoryForFrame::GetCorsExemptHeaderList()
method.
Bug: 1413912
Change-Id: I6a37e355ee5779878ad3b086b079a04e6f9ab64b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4236209
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1104452}
Currently ServiceWorkerNetworkProviderForFrame::CreateURLLoader() in the
content layer is called to create a WebURLLoader from
blink::LoaderFactoryForFrame::CreateURLLoader().
We'd like to stop exposing blink::WebURLLoader to the content layer.
So this CL does the followings:
- Replace ServiceWorkerNetworkProviderForFrame::CreateURLLoader() with
GetSubresourceLoaderFactory() which returns a
network::SharedURLLoaderFactory.
- Make blink::LoaderFactoryForFrame::CreateURLLoader() call the new
method to get a network::SharedURLLoaderFactory, and create a
blink::WebURLLoaderFactory using Platform::WrapURLLoaderFactory().
- Introduce Platform::WrapURLLoaderFactory(
scoped_refptr<network::SharedURLLoaderFactory>).
This CL should not introduce any behavior change.
Bug: 1413912, 789857
Change-Id: I44343eaceda6d308924db5bc75de8385ec01c4c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4211117
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hiroki Nakagawa <nhiroki@chromium.org>
Commit-Queue: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102996}
Because of the "hidepid=2" mount option for /proc on Android,
browser process cannot open /proc/{render process pid}/maps and
status, i.e. no such file or directory.
So add PrivateMemoryFootprintProvider, which uses MemoryUsageMonitor,
to third_party/blink/renderer/controller and provides the calculated
private memory footprint for browser process by using render_host.mojom.
Bug: 1393283
Change-Id: Ibb00262afc2ed0552e3f0c2ec5fb7449878b93c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4124620
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Takashi Sakamoto <tasak@google.com>
Cr-Commit-Position: refs/heads/main@{#1096563}
Win7/8 support is deprecated. This CL removes the remaining Win7/8
code from content/* and a bit of corresponding code from
third_party/blink.
Also fixes lint warnings.
Bug: 1385856
Change-Id: I214fe93fc1583a2214862e9652ffef7d81043691
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4178560
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: David Bienvenu <davidbienvenu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1095092}
Replace WebAudioDevice::RenderCallback with the above, to reduce
overhead from adapting between different callback types.
This will also make it easier for WebAudio to support the new audio
glitch reporting system (to be done in a follow-up CL, see bug link
below).
Higher-level, I think we should move toward unifying more of
Chromium's audio infrastructure and this is a step in that direction.
Bug:1384499
Change-Id: I1a7640335b0a7f1d2bb58d6ca719a84a6358faac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4126170
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Alvin Ji <alvinji@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Michael Wilson <mjwilson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1090673}
The VideoFrameCompositorTaskRunner is currently not accessible
from modules and platform/peerconnection. This CL makes it available
using accessors in Platform instead and is a prerequisite to make
VSyncDecoding work in a subsequent CL.
Bug: 1393053
Change-Id: Ic7d4ce3b197dc738f496ada896f6e228421a50ef
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4051150
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Markus Handell <handellm@google.com>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1079474}
Code generally assumes the Media task runner is a single thread. Issue
crbug.com/1144329 hints at there isn't a hard requirement that the Media
sequence is a thread, and additional motivation for changing has been
provided in crbug.com/1144329#c2 (power consumption).
This change should be NOP, but hoists build assumptions on Media being a
SingleThreadTaskRunner to being its super class, SequencedTaskRunner.
Future CLs will be landed to also fix runtime dependencies as the Media
thread switches to become sourced by CreateSequencedTaskRunner() inside
RenderThreadImpl.
Bug: 1144329
Change-Id: Id24ffd3c059a9e5da567861758500c171031fd36
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3928266
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Jordan Bayles <jophba@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Commit-Queue: Markus Handell <handellm@google.com>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1059135}
This CL cleans up two redundant arguments in
CreateAudioDevice() function: input channel count and input device
specifier. These argument was added in the past for some reasons,
but it is not being used anywhere today.
NOTE: This does not include a functional change.
Change-Id: Ife7c530a7f5d1ad6d4f55bee9207474cfd6ed133
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3817846
Commit-Queue: Hongchan Choi <hongchan@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1032806}
renderer/core depends on storage/common so modules should be able to.
Remove the APIs from the platform that cause the serialization of the
SecurityOrigin to a String and parse into a GURL. Use the ToUrlOrigin
directly to avoid the serialization as null.
BUG=591482
Change-Id: I49c1ba7a6ae9216746dc16dbb6ea3b6f162cec9e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3749483
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1023283}
This is a no-op migration from base::ThreadPriority to base::ThreadType.
Except for the name changes of enum classes and functions, their
behavior should be kept unchanged. By using the new ThreadType API, the
caller declare the type of work a thread runs, and let the platform
implementation decide its behavior. Apart from the current priority
setting, the QoS API will further be used on some platforms.
Mappings in existing callers are as follows:
ThreadPriority::BACKGROUND => ThreadType::kBackground
ThreadPriority::NORMAL => ThreadType::kDefault
ThreadPriority::DISPLAY for compositing only on select
platforms (WIN, ANDROID, CrOS)
=> ThreadType::kCompositing
ThreadPriority::DISPLAY unconditionally on *all* platforms
=> ThreadType::kDisplayCritical
ThreadPriority::REALTIME_AUDIO => ThreadType::kRealtimeAudio
As this CL aims to make all platform-specific decisions in the
platform_thread_<platform>.cc impls, ifdef exceptions on main threads
(like on Mac) have moved to their respective impls.
The resulting callers should thus have no ifdefs left except for the odd
exception with a TODO we aim to unravel after this no-op CL.
ifdefs for render_message_filter()->SetThreadType() stay for now as this
call is already platform specific.
Bug: 1278628, 1324809
Change-Id: I36fbc4fc988c12e712da2e131595255a7b4fe4b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3329026
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Zhibo Wang <zhibo1.wang@intel.com>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Olga Sharonova <olka@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Peng Huang <penghuang@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Markus Handell <handellm@google.com>
Reviewed-by: Sergey Volk <servolk@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1021517}
FetchEvent worker timing is the experimental feature behind the runtime
flag. The implementation of the feature has been suspended since 2019
November, and we don't have a plan to complete it. For code simplicity,
this CL removes the entire implementation.
This removal should be safe as the feature has never been shipped on any
browsers and its spec is still in the editor's explainer stage[1] (not
merged into the service worker spec and the resource timing spec).
[1] https://github.com/wanderview/fetchevent-worker-timing/blob/master/explainer.md
Bug: 900700
Change-Id: I781ccece189e80bfb329073ed952dc1bffd1d1b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3697967
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Ben Kelly <wanderview@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1013407}
