This policy makes explicit which schemes are allowed to participate
in webui bundled bytecode in the renderer.
The intention is to make it easier to identify whether schemes opted
into bundled code caching are in scope when analyzing attack
surfaces.
Bug: 378504631
Change-Id: I985f0bceeed0d0b9b58d6b500eddf3ea7aa5662b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6207229
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Hiroshige Hayashizaki <hiroshige@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417056}
Replace WebVector (which has been an alias of std::vector since
crrev.com/c/6204022) with std::vector.
function cg() {
git grep --name-only "$1" -- *.mm *.h *.cc
}
sed -i 's/include.*web_vector.h"/include <vector>/' `cg web_vector.h`
sed -i '/^using blink::WebVector;/d' `cg 'using blink::WebVector'`
sed -i '/^using ::blink::WebVector;/d' `cg 'using ::blink::WebVector'`
sed -i 's/blink::WebVector\b/std::vector/g' `cg blink::WebVector`
sed -i 's/\bWebVector\b/std::vector/g' `cg WebVector`
git checkout -- third_party/blink/public/platform/web_vector.h
git cl format
Only manual changes are to remove unused "#include <vector>" added by
the above script, based on presubmit warnings.
BYPASS_LARGE_CHANGE_WARNING=`git cl split` will create too many CLs needing too many reviewers while this CL doesn't need much manual review.
Bug: 40865165
Change-Id: Ib70af44863ceaa73f470c77abe74d8994e2822a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6209609
Owners-Override: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412669}
This is a reland of commit 235af46635
Reason for revert:
LUCI Bisection has identified this change as the cause of a test failure. See the analysis: https://ci.chromium.org/ui/p/chromium/bisection/test-analysis/b/5650878292819968
Fix: initialize TraceEventHandle to 0 to avoid
MemorySanitizer: use-of-uninitialized-value error
Original change's description:
> [tracing] Cleanup up trace_log
>
> This CL cleans up some of the unused functionalities in trace_log
> - legacy metadata
> - member AddTraceEvent* function: replaced by static ones
> - SetTrackDescriptor: covered by TrackNameRecorder
> We no longer update SetTrackDescriptor on UpdateProcessLabel;
> this is unnecessary because TrackNameRecorder calls
> SetTrackDescriptor when the session ends.
>
> Bug: 343404899
> Change-Id: Ia3c4524cd3b3dd4d4ad12a0348e60480b5d03f67
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6120057
> Reviewed-by: Derek Schuff <dschuff@chromium.org>
> Reviewed-by: Gabriel Charette <gab@chromium.org>
> Reviewed-by: Alexander Timin <altimin@chromium.org>
> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
> Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
> Cr-Commit-Position: refs/heads/main@{#1403710}
Bug: 343404899
Change-Id: Icb14722297b39f3b8fc7be0985452182a7b5846f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6163823
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1404225}
This CL cleans up some of the unused functionalities in trace_log
- legacy metadata
- member AddTraceEvent* function: replaced by static ones
- SetTrackDescriptor: covered by TrackNameRecorder
We no longer update SetTrackDescriptor on UpdateProcessLabel;
this is unnecessary because TrackNameRecorder calls
SetTrackDescriptor when the session ends.
Bug: 343404899
Change-Id: Ia3c4524cd3b3dd4d4ad12a0348e60480b5d03f67
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6120057
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Reviewed-by: Mikhail Khokhlov <khokhlov@google.com>
Cr-Commit-Position: refs/heads/main@{#1403710}
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}
- Remove IS_CHROMEOS_LACROS code
- Replace IS_CHROMEOS_ASH with the equivalent IS_CHROMEOS
- Similarly for is_chromeos_lacros/is_chromeos_ash.
- Drop obsolete includes/build dependencies.
- Drop lacros-chrome browser tag from gpu tests
- Drop obsolete skip directives from gpu tests
No change in behavior.
Bug: b:365742770 , b:365741912
AX-Relnotes: n/a.
Change-Id: I594d3677a9855d0649deba3ad836a1b3804440f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6097832
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1398368}
It was previously possible for pickers like <select>'s picker to be
shown on top of the not-currently-focused tab, confusing the user.
With this change, the select picker must be the currently-focused
tab for the picker to be opened. This is akin to existing protections
for the tab being visible.
Fixed: 365089001
Change-Id: Id2b15f5d310cce877341d7e9d5a5c5d6da882887
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5909884
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1377731}
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}
NOTREACHED() and NOTREACHED_IN_MIGRATION() are both CHECK-fatal now.
The former is [[noreturn]] so this CL also performs dead-code removal
after the NOTREACHED().
This CL does not attempt to do additional rewrites of any surrounding
code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
This does clean up kCrashOnDanglingBrowserContext as both paths of the
kill switch are currently fatal. This has been rolled out for a long
time.
Bug: 40580068, 40062641
Change-Id: Ib88e710d003e2e48df3fc502ca54d2341d157a0e
Cq-Include-Trybots: luci.chromium.try:linux-dcheck-off-rel
Low-Coverage-Reason: OTHER Should-be-unreachable code
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5974816
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1376522}
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}
In preparation of patches that will allow V4L2 decoding to work by
default on Linux.
The VA-API and V4L2 backends provide essenitaly the same output -
DMABufs in formats like NV12/P010 etc. - and face similar restrictions
e.g. GL driver features. It therefore makes sense to have the same media
switches and in fact some of them - most importantly
`VaapiVideoDecodeLinux` - already apply to V4L2.
Thus in order to reduce confusion and avoid code duplication, rename
some of the `Vaapi` swiches used in common code to `Accelerated` but
keep the `Linux` suffix, making it clearer to what they apply. Also
ensure they are used for both APIs the same way and update the
`vaapi.md`.
Finally, add `AcceleratedVideoDecodeLinuxZeroCopyGL` to the VA-API
documentation.
Bug: b:334110478
Change-Id: Iea58966d6ab94ce995defb1cf1099dd9ba9fae26
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5893615
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Commit-Queue: Fritz Koenig <frkoenig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363231}
In the previous CL, we programmatically enable the runtime feature for
prompt API in order to expose the JS handle to the self namespace, and
then copy the value to chrome.aiOriginTrial then reset it to
undefined.
The flow is now improved by getting the AIAssistantFactory directly
from the v8_context, with that, we can clear a lot of runtime features
check and unnecessary workaround code to make the implementation
cleaner.
Bug: 350642260
Change-Id: I71c99dddc7f6d0980a7819110f6d82f073c94aa2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5889515
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Commit-Queue: Mingyu Lei <leimy@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1360984}
* 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}
This is a no-op on most platforms because kDisplayCritical and kCompositing are equivalent already, as desired after progress
on crbug.com/1329208
On Linux and Fuchsia: kDisplayCritical is not equivalent to kCompositing, so this CL introduces change in behavior.
On Linux, this CL aligns behavior to ChromeOS (ChromeOS is already
running kCompositing threads with the same priority as kDisplayCritical).
Population is generally too small to draw reliable conclusion from
an experiment, so it's more robust to align with ChromeOS.
On Fuchsia, we simply drop kCompositing.
Effectively, this CL brings all kCompositing threads (each process' main thread, compositor thread and IO thread) to a higher priority than it was before.
Bug: 1329208
Change-Id: I6331a3eacb2396117e20d833eb993a91eadd1d47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4842549
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Owners-Override: Gabriel Charette <gab@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1344860}
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}
This is a reland of commit 7f04022ea0.
The original commit was reverted due to test failures in component
builds. These failures came in two flavors and this reland contains
fixes for both. They are:
1. Failures caused by the ProtectedMemory variable being initialized
not being in the proper memory address range. This is caused by the
memory segment code being defined in the .h file which means that
different DSOs can define different sections, and cross DSO calls
will show the memory in the wrong section. The fix is simply to
disable ProtectedMemory for component builds. Component builds are
never shipped so there is no value in supporting it for them.
2. The new get_{{feature.data_member_name}}() method added for
ProtectedMemory RuntimeEnabledFeatures, which is the method where the
static initializer was added, was defined in the include file instead
of the cc file. Thus the static initializer could be rerun in different DSOs. This resulted in the MojoJS runtime enabled feature
not necessarily getting the right value, causing tests that needed it
to be true to fail with MojoInterfaceInterceptor (because MojoJS
bindings weren't enabled). By moving the definition to the CC file,
this problem went away.
Original change's description:
> Make static initialization of base::ProtectedMemory objects required
>
> This change makes it so that static initialization of
> base::ProtectedMemory instances is always required, even if the type
> provides constant initialization. This achieved by removing the bool
> ConstructLazily template parameter from ProtectedMemory and related
> classes, and making the case where it's "true" the only case. Thus the
> lazy construction through base::ProtectedMemoryInitializer is required.
>
> This change is made in preparation of adding support for ProtectedMemory
> to non-windows platforms. On some platforms there is an issue with
> initializing the protected memory section to readonly at build/link
> time. To combat this, the required initialization of ProtectedMemory
> instances will be used to initialize the protected section to readonly
> at runtime.
>
> This change also updates previously added use cases of ProtectedMemory
> to add the now required initialization.
>
> Bug: 41495919
> Change-Id: Ice3d39caee28a3fc956d4d9ebca8c6f51d03ce1c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5668250
> Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1324440}
Bug: 41495919
Change-Id: Ic8d416e4278d1bddf892e0ba967999b3ba4e8f1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5689823
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1326184}
This reverts commit 7f04022ea0.
Reason for revert: suspected cause of 351926112
Original change's description:
> Make static initialization of base::ProtectedMemory objects required
>
> This change makes it so that static initialization of
> base::ProtectedMemory instances is always required, even if the type
> provides constant initialization. This achieved by removing the bool
> ConstructLazily template parameter from ProtectedMemory and related
> classes, and making the case where it's "true" the only case. Thus the
> lazy construction through base::ProtectedMemoryInitializer is required.
>
> This change is made in preparation of adding support for ProtectedMemory
> to non-windows platforms. On some platforms there is an issue with
> initializing the protected memory section to readonly at build/link
> time. To combat this, the required initialization of ProtectedMemory
> instances will be used to initialize the protected section to readonly
> at runtime.
>
> This change also updates previously added use cases of ProtectedMemory
> to add the now required initialization.
>
> Bug: 41495919
> Change-Id: Ice3d39caee28a3fc956d4d9ebca8c6f51d03ce1c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5668250
> Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1324440}
Bug: 41495919,351994238
Change-Id: I7c3956923253affc5dad294d03f05e1a3c39fd17
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5688694
Reviewed-by: Trevor Perrier <perrier@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@google.com>
Owners-Override: Trevor Perrier <perrier@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1324954}
This change makes it so that static initialization of
base::ProtectedMemory instances is always required, even if the type
provides constant initialization. This achieved by removing the bool
ConstructLazily template parameter from ProtectedMemory and related
classes, and making the case where it's "true" the only case. Thus the
lazy construction through base::ProtectedMemoryInitializer is required.
This change is made in preparation of adding support for ProtectedMemory
to non-windows platforms. On some platforms there is an issue with
initializing the protected memory section to readonly at build/link
time. To combat this, the required initialization of ProtectedMemory
instances will be used to initialize the protected section to readonly
at runtime.
This change also updates previously added use cases of ProtectedMemory
to add the now required initialization.
Bug: 41495919
Change-Id: Ice3d39caee28a3fc956d4d9ebca8c6f51d03ce1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5668250
Commit-Queue: Jeffrey Gour <jegour@microsoft.com>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1324440}
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 manager is only used to report metrics calculated in cc/metrics.
It's location in cc/trees predates the cc/metrics folder.
This change moves it, ahead of some follow ups to it's ownership, and
potential new UKMs
Bug: 334977830
Change-Id: Icbab339fe18ea4ef0f06b42b03f023125f4801a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5648501
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Ian Vollick <vollick@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1322830}
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}
Suppress unsafe buffer usage on a file-by-file basis. Out of
approximately 5850 .cc and .h files only roughly 160 files fail
compilation with the unsafe buffers warning.
Suppress only, by inserting boilerplate into affected files. Do not
re-write any code to work around the issues. Properly fixing each file
will be done in follow-up CLs.
//content/ is not removed from unsafe_bufers_paths.txt file and will be
also done as a follow-up, so it makes potential reverts simpler.
Bug: 342213636
Change-Id: I4a936e63dea95a78951f7bfae6d5487708ae3c0b
AX-Relnotes: n/a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5608913
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1312393}
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}
