This patch moves the GpuVideoAcceleratorImpl to media/mojo/clients
and renames it to MojoGpuVideoAccelerator. This class can now be used
both in content and in components/mirroring.
Cast Streaming will be updated to use this implementation to enable
hardware mirroring in the media::cast::MediaVideoEncoderWrapper
implementation.
Googlers may view the related design doc at:
http://go/cast-streaming-media-videoencoder
Publicly published design documentation available at:
https://tinyurl.com/cast-streaming-mvew
Bug: 282984511
Change-Id: I91bba38ea55007d3f3626027308d800aeda0a383
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6095257
Commit-Queue: Jordan Bayles <jophba@chromium.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1398421}
While the process priority is mostly simplified to a
"backgrounded" or "foregrounded" boolean value, more priority
values will be used in the future and it'll be useful to know
in traces.
Change-Id: I5605560b8802ae47092b1251dbed75606514d69f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5722149
Reviewed-by: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1376864}
On some builders the death test was failing because an assert had an
unexpected message. Removed the death test: there's no need to test for
an invalid handle since it's blocked at the Mojo layer.
Bug: 375065072
Change-Id: I09d0882e9a207b5440d3018edf5b2db8ab579980
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5953918
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Auto-Submit: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1372758}
Following a suggestion by Nasko in https://crrev.com/c/5867574, this
handles performance scenario shared memory completely in the blink and
components/performance_manager layers, getting rid of a shim through
content/ and chrome/.
This will unblock a followup CL to attach the browser-side
StructuredSharedMemory region to ProcessNode instead of
RenderProcessHost, which is blocked by the content/ shim accessing it
synchronously on the UI thread. The cost is an extra IPC roundtrip on
process startup.
Includes a partial revert of https://crrev.com/c/5867574 that returns
mojom::Renderer::TransferSharedMemoryRegions to TransferSharedLastForegroundTime.
Bug: 365586676
Change-Id: I681a3c941661ebba7c10b7abaf54aa5c4e430a9e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5949866
Commit-Queue: Joe Mason <joenotcharles@google.com>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Auto-Submit: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1372300}
This CL adds 3 features to selectively disable/enable parts of the
memory pressure response in renderers:
"ForwardMemoryPressureToBlinkIsolates"
Controls whether memory pressure is forwarded to Blink isolates, which
has for effect to trigger a GC (critical) or start incremental marking
(moderate).
"ReleaseResourceStrongReferencesOnMemoryPressure"
Controls whether `blink::MemoryCache` and `blink::ResourceFetcher`
release their strong references to resources in response to memory
pressure. This affects whether previously used resources can be found
in the `blink::MemoryCache` in the future.
"ReleaseResourceDecodedDataOnMemoryPressure"
Controls whether `blink::Resource` releases its decoded data in
response to response to critical memory pressure. This affects
whether the data has to be decoded again if the resource is
reused in the future.
A previous experiment disabled *all* memory pressure clients in
renderers on desktop, with good impact on LCP but some memory
increase (go/finch50-no-memory-purge-in-renderers-desktop). The new
features will be used to assess the impact of important memory pressure
client on the LCP and memory metrics in isolation.
Bug: 40287434
Change-Id: I920389c3cadf3f6e82b6836e484adebf10ef90a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5913594
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Francois Pierre Doray <fdoray@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1366859}
* Renames TransferSharedLastForegroundTime to
TransferSharedMemoryRegions and uses it to transfer multiple region
handles. Also updates it to allow optional handles (the mojo typemap
will crash on invalid handles otherwise.)
* Adds functions to manage the browser side of the channel in
components/performance_manager.
* Adds accessors to ContentBrowserClient to return performance
scenario region handles. The default implementation returns invalid
handles, but ChromeContentBrowserClient gets the handles from
components/performance_manager.
* Adds a test for TransferSharedMemoryRegions.
Bug: 365586676
Change-Id: Ib0ff85e07459d768896ea571e357d687cb9e8243
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5867574
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Olivier Li <olivierli@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Joe Mason <joenotcharles@google.com>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Cr-Commit-Position: refs/heads/main@{#1359994}
Adds a cleaner interface to ReadOnlySharedMemoryRegion /
SharedMemoryMapping, which specifies the type that's stored in the
memory when the memory is mapped rather than on every access.
Converts some simple users of shared memory to use
StructuredSharedMemory.
Bug: 357945779
Change-Id: I27105cf7feb2136c14c7e345617f7e2284f15e0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5746992
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Joe Mason <joenotcharles@google.com>
Reviewed-by: Yuzhu Shen <yzshen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1343748}
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 field is:
* Unsafe in presence of Oilpan (see https://crbug.com/40261265)
* Not actually used - there are no callers of
`AgentGroupScheduler::GetBrowserInterfaceBroker`. This method was
added in https://crrev.com/c/2677585 and AFAICT no callers have ever
been added later - for example this command finds no other commits:
`git log -S AgentSched -- content/browser/browser_interface_binders.cc`
Removing this field also helps to make progress on
https://crbug.com/41482945 - this field is related to 1 out of 5 callers
of `BrowserInterfaceBrokerProxy::Bind` and the linked bug requires
passing `ContextLifecycleNotifier` to `HeapMojoRemote`. I note that
`AgentGroupSchedulerImpl::BindInterfaceBroker` seems to be the only
caller of `BrowserInterfaceBrokerProxy::Bind` which doesn't have a 1:1
relationship with a `ContextLifecycleNotifier` (which IIUC roughly
corresponds to the `ExecutionContext`). The other callers are 1)
constructor of `WorkerGlobalScope`, 2) constructor of
`content::RenderFrameImpl`, 3)
`MojoBindingContext::SetMojoJSInterfaceBroker` (we ignore here
`GetEmptyBrowserInterfaceBroker` which doesn't actually need to bind an
actual mojo remote).
Fixed: 40261265
Bug: 41482945
Change-Id: Id07826bb008bea6157a30868a56ad05ad3bbc675
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5646657
Reviewed-by: Francois Pierre Doray <fdoray@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1319775}
of a single boolean indicating if the process is backgrounded.
Currently a nop change as the enum is converted back to a single
boolean in the renderer, but it will be used in a later CL to
apply different interventions when a process is kUserVisible
versus kUserBlocking.
Bug: 41485666
Change-Id: Ide4130a1d7b9653ae434e0d0992d46f74fbb9e7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5555305
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Patrick Monette <pmonette@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1314537}
It will support automatic ".BestEffort" suffixing in renderers for
metrics that rely on timing.
It uses shared memory to share read-only std::atomic<TimeTicks> state
between RenderProcessHostImpl and the renderer.
"HangWatcher.IsThreadHung.RendererProcess.*" will be the first metric to
test this out. There was a recent "regression" caused to it by a
mix-shift when shipping more aggressive backgrounding of best-effort
renderers on Mac, recovering from that is how we test that this works.
Local chrome://histograms test: https://snipboard.io/KjNzMa.jpg
Bug: 334983411
Change-Id: I78259ca47514059a74fb1b672192e90b24551e31
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5459762
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Olivier Li <olivierli@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1311669}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ibc66b8c440e4bcdef414e77fef4d9874d2ea9951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5493800
Auto-Submit: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293330}
Synchronous IPCs aren't ideal, we can add a small cache to avoid
them in most situations. The cache is first populated with 4 items
upon RenderThread initialization. When the cache has only two items
in it new ones are asynchronously requested from the browser. If
the cache is empty it will fall back to the synchronous request.
This is implemented as a feature flag since we'd like to conduct a
study to see if this impacts FCP/LCP.
Thanks to nasko@ who's discussion sparked this approach as opposed
to something more complex as discussed in
https://docs.google.com/document/d/1nu1aUc4_UiWeqwAQ0-mxTMP4S7pZmNBvs110GGMuZl8/edit
Bug: 41496222
Change-Id: I3ea33d63c1437f879fafa33ce85d5daa279df9bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5249292
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1256479}
This filter is bound on the IO thread and processes a single
synchronous message. It does not need to be an associated interface
because messages that depend on it are sent after the synchronous
response is returned to the renderer.
Bug: 993189
Change-Id: Ic43d3febc4d442dc50c0a91d04391c311e4eaab3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5174108
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1244249}
Having it on the RenderMessageFilter meant it was processed on the IO
thread, but ultimately it was posted to the UI thread anyways. So it is
much less complicated if the method is on a UI bound interface. This
method is only used by the GPU benchmarking extension.
Bug: 993189
Change-Id: Iab3de7769a894f3437371a3bff7b7827a2ed2de4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5170790
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1243535}
- Do not build RenderFrame as an IPC::Sender/Listener
- Remove public FromRoutingID lookup
- Remove requesting the routing ID from RenderFrame
- Do not build ChildThread as an IPC::Sender
- This leaves all the legacy IPC code in ChildThreadImpl the same.
- We still require legacy IPC for some associated channel interfaces (see
RenderThread::GetChannel callsites, and
RenderThreadObserver::RegisterMojoInterfaces).
- The scheduling differences between associated channel interfaces and
normal associated interfaces still also need to be resolved to disable legacy IPC over the wire.
Bug: 1502660
Change-Id: I6343377ee82a8284ce8a9734f6e5719f6ca102a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5105871
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1242431}
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}
--disable-web-security is used to disable cross-origin isolation in
general. Various things like certain bindings (e.g.
performance.measureUserAgentSpecificMemory()) are gated behind the
WebIDL attribute 'CrossOriginIsolated'. This mostly depends on
Agent::CrossOriginIsolated(). Set this property directly on the renderer
process when --disable-web-security is provided.
The effect is that various otherwise gated APIs become usable which is
useful for debugging.
Bug: chromium:1486857
Change-Id: I146513a26d757118edb9be5f57fe6f7f1317b128
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4896878
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1205080}
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}
Previously, during Origin Trial Policy creation, it pulled the disabled
tokens from the CLI flags. As reported in the linked bug, there is a
small limit to the number of disabled tokens that can be provided. This
CL changes where the policy gets the disabled tokens.
Now, when OriginTrialPolicyImpl is created, it will use
OriginTrialsSettingsProvider to get the settings previously set during
the start up of the browser or renderer.
---
When are the settings for OriginTrialsSettingsProvider set:
Browser: During the startup of chrome and android webview, it
will set the settings for blink::OriginTrialsSettingsProvider.
Renderer: The settings are pushed to the renderer via
InitializeRenderer. Once that is called, the settings for
blink::OriginTrialsSettingsProvider are set
---
About blink::OriginTrialsSettingsProvider:
It stores the settings for the process. OriginTrialPolicyImpl can refer
to it to get the settings. In single process mode, the settings are only
set during browser startup and not during InitializeRenderer.
Bug: 1216609
Change-Id: Ibe1663463688344d20bcd62ca4952c1cfebedfbb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4424072
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: James Scott <jamescscott@google.com>
Reviewed-by: Jason Chase <chasej@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1145589}
Previously, build flags were used to restrict this to Android, but that
entailed significant complexity by infecting a lot of related code with
the need to itself be buildflag-protected. This will make it easier to
add OS support to other platforms in the future, if needed, and
increases test coverage.
This change introduces a no-op OS-level manager for platforms on which
OS support is disabled and removes layering violations between the
AttributionManager and AttributionOsLevelManager.
Change-Id: I7a984d6c77fd0312ad104c248d4278bb7666d99e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4480909
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: Nan Lin <linnan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1139825}
This CL adds a method to the Renderer mojo interface so that:
* The blink memory cache is cleared when a user clears cache via
chrome://settings/clearBrowserData.
* SplitCache tests reliably clear the blink memory cache even when
tabs/shells share a process.
For simplicity, the method doesn't take a time range to clear caches.
This should be fine because the disk cache still retain resources
outside the time range. These resources will be served via the disk
cache.
Bug: 1434900,668114
Change-Id: I174e8af0e97b69989380a0e9c303d2f14ea58b36
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4486550
Commit-Queue: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1138084}
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 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}
Highlight colors are accessed via `WebSandboxSupport` rather than being
retrieved from AppKit. This means it is no longer necessary to write
them into user defaults. `LayoutThemeMac` still reads
`AppleAquaColorVariant` from user defaults on older OS versions so it
must still be written. It can be removed once Chromium drops support for
macOS 10.13.
Since colors are no longer retrieved from AppKit it is no longer
necessary to post notifications to let AppKit know that the system
colors have been changed.
Change-Id: I2838946feb1b45a07d9026db26df00c29b4bb7fc
Fixed: 1420647
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4381954
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Mark Rowe <markrowe@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1125711}
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}
Per crrev.com/c/4313359, MeasurementManagerFutures will be used and
therefore the Android API to get measurement state is asynchronous.
The measurement state is per device and can only change when the user
changes the setting on the device. The flag is cached as a global
variable and initialized once on startup. The value returned from JNI
will be populated to all renderer processes created earlier.
Bug: 1417278
Change-Id: Ideb3582849d9415acc3b7265a88d54f07a517b4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4319466
Reviewed-by: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Auto-Submit: Nan Lin <linnan@chromium.org>
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: John Delaney <johnidel@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1115853}
This is a follow up for crrev.com/c/4048260. As the Android API to get
the flag is synchronous, the flag can be obtained once and cached in
`AttributionOsLevelManagerAndroid` for later use. The renderer can be
initialized with the flag directly and there's no need to update the
existing renderers as we don't listen to the flag changes.
Note that the flag can only change when the user changes the setting
on the device and should be "static" for most part.
Bug: 1417278
Change-Id: I2ab954a2f9dcc5de043cc0a14d7cbaea9160b2e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4284643
Commit-Queue: Nan Lin <linnan@chromium.org>
Reviewed-by: Andrew Paseltiner <apaseltiner@chromium.org>
Reviewed-by: Garrett Tanzer <gtanzer@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1109683}
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}
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}
This is a reland of commit cbf66397e1
fuchsia dbg bots failed due to a linker issue. The fix is to add
export_class_attribute, export_define, and export_header params
in the fuchsia_media mojom target to include the dependency and avoid
possible runtime linker error.
Original change's description:
> [fuchsia] Surfacing hardware decoder capabilities in GPU factories
>
> Created CodecFactory to assist GpuVideoAcceleratorFactoriesImpl on
> hardware decoder and encoder functionalities. Its derived classes has
> different implementation to connect to hardware decoder resources.
>
> CodecFactoryFuchsia uses media::mojom::FuchsiaMediaCodecProvider to
> get the supported decoder configs and create a video decoder.
>
> Unit tests are added for GpuVideoAcceleratorFactoriesImpl.
>
> Bug: 1198266, 1207991, 1368710, 1134719
> Change-Id: I2babc333181c2a53e5aa85125d9d628d401f055d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3936347
> Reviewed-by: Bryant Chandler <bryantchandler@chromium.org>
> Reviewed-by: Peng Huang <penghuang@chromium.org>
> Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Commit-Queue: Guocheng Wei <guochengwei@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1086434}
Bug: 1198266, 1207991, 1368710, 1134719
Change-Id: I66cacee1b0f0bf05494d57b6d8abe4f36666cc06
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4122748
Reviewed-by: Peng Huang <penghuang@chromium.org>
Reviewed-by: Bryant Chandler <bryantchandler@chromium.org>
Commit-Queue: Guocheng Wei <guochengwei@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1089444}
