The CL tracks whether a process allocation is caused by a COOP mismatch.
Currently the browser will fail to reuse the process and allocate a new
one when receiving a COOP header in the response under partial site
isolation. The CL tracks this reuse failure when creating the site
instance after receiving the response header. The failure will be passed
to the ProcessAllocationContext when the new site instance tries to
allocate a process.
Bug: 388998723
Change-Id: Iea2135403ad428393e75c2d2966d3ffcabce8ff6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6238439
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Jiacheng Guo <gjc@google.com>
Cr-Commit-Position: refs/heads/main@{#1419680}
In doing the SiteInstanceGroup work, we came across
kProcessSharingWithStrictSiteInstances, which has not been experimented
with for a long time, and can be removed. SiteInstanceGroups serves a
similar purpose in that it allows for multiple SiteInstances to be in
the same process.
This change also removes the existing SiteInstanceGroupManager, which
was a previous implementation of SiteInstanceGroup for the strict
SiteInstance mode. Usage of SiteInstanceGroupManager is gated behind
the strict SiteInstances flag, so it also hasn't been used or
experimented with for a long time, and can be removed.
Test: Removing a feature, remove strict SiteInstance checks in tests
Bug: 40612450, 40737467, 40161396, 390571607
Change-Id: I300523b8dabfe6de19dbf457eea143181e8e5587
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6050878
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1418735}
This CL introduces multiple SiteInstances per SiteInstanceGroup for
subframe data: URLs. This feature is behind the feature flag
kSiteInstanceGroupsForDataUrls, which is disabled by default, so there
is no behaviour change in this CL.
Subframe data: URLs will now have their own
SiteInstance that goes in the same SiteInstanceGroup as its initiator.
Currently, sandboxed data: subframes are excluded, as they require
computing a variation of the initiator SiteInstance, which is out of
scope for this CL and will be added in a followup.
Because the new data: subframe shares a SiteInstanceGroup with its
initiator, the number of processes remains the same as before.
Test: Added SiteInstanceGroup browsertests
Change-Id: If784b21ceccd440e35c0020053823ae287cf931d
Bug: 40269084
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4675093
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Elly FJ <ellyjones@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1382080}
Resource thresholds may soon be added for other process reuse policies,
so this CL starts to generalize the code added for the ProcessPerSite
main frame reuse threshold.
Specifically, the policy in use for the current case is now passed into
the resource check function, and the main frame threshold is only
referenced there and not passed through other functions anymore.
SiteIsolationImpl::ProcessReusePolicy has also moved into its own file,
to make it easier to use in more places.
Low-Coverage-Reason: TRIVIAL_CHANGE Refactor with no behavior change.
Bug: 40259123
Change-Id: Ic1448b68b8e5a6a2b33081849e67ee1c83019d3f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5837830
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1351731}
In preparation for implementing a subframe process reuse memory
threshold, this CL refactors to split REUSE_PENDING_OR_COMMITTED_SITE
into two values, one for subframes and one for service workers.
The memory threshold will only apply to process reuse by subframes, at
least initially. If/when we consider the case of process reuse for
workers, it's likely that the threshold/algorithms will be different,
so having a separate policy identifier for subframes and workers will
still be necessary.
This CL introduces no behavioral changes.
Bug: 40600119, 40259123
Change-Id: I219c7f0e5ef68e2236d95972a5b680874a7faf8c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5813084
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1347440}
This change implements support for:
* DefaultJavaScriptOptimizerSetting
* JavaScriptOptimizerAllowedForSites
* JavaScriptOptimizerBlockedForSites
By:
* Adding a method to ContentBrowserClient called
AreV8OptimizationsDisabledForSite(), and implementing it in
ChromeContentBrowserClient by checking the associated content setting
* Storing whether v8 optimizations are disabled for a site in SiteInfo
(sadly by adding a new constructor argument to it)
* Storing whether v8 optimizations should be disabled as part of
RenderProcessHost
* Starting render processes with --disable-optimizing-compilers if a
given RenderProcessHost should have optimizations disabled
* Adding a browser test to ensure this logic works
Bug: 338434846
Change-Id: Idb9a85d4eb73a7cc5bfc60d303809c714959a666
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5689960
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Calder Kitagawa <ckitagawa@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Yann Dago <ydago@chromium.org>
Commit-Queue: Elly FJ <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1343526}
This CL implements process isolation of documents that set
Document-Isolation-Policy. It introduces an AgentClusterKey passed to SiteInfo,
which is used to isolate pages with DIP from pages without DIP. In this CL, the
AgentClusterKey is only computed for pages with DIP. Pages without DIP only get
an AgentClusterKey with an empty URL. Follow-up work will properly compute the
AgentClusterKey for all navigations.
Bug: 333047378
Change-Id: I86f1fa637f68dfe0932be7b2373323472c19ac7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5588626
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Camille Lamy <clamy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1323878}
There are comparisons that currently use the SiteInstance ID from the
content public API that should be instead using the SiteInstanceGroup
ID. Introduce and use the SiteInstanceGroup ID.
http/tests/loading/simple-subframe.html fails when comparing
SiteInstance IDs
Test: With data: URLs in SiteInstanceGroup enabled, the blink_web_test
Bug: 40269084
Change-Id: If24045558420a16a067e34b60f7a1eef0222815d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5625177
Reviewed-by: Joe Mason <joenotcharles@google.com>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1316059}
At present, all sandboxed extension frames (regardless of whether they
are listed as sandboxed in the manifest) are treated the same: when
IsolateSandboxedIframes is enabled, they are placed in a separate
process for the extension with all the other sandboxed frames for the
extension. This process is listed in the extension process map, so
any attempt to limit API access could be thwarted by a compromised
renderer.
The goals for this CL are:
1) Non-manifest sandboxed extension URLs are changed so that they stay
in the main extension process, and continue to have API access. This
reduces the process count in cases where the extra process wasn't
providing much security benefit. Continued API access for these sandboxed
frames is important, since these documents may not be able to control
their sandbox status (e.g. they might be embedded in a web page that
is itself sandboxed, in which case the extension document inherits the
sandbox, possibly unexpectedly).
2) Manifest-sandboxed extension URLs, sandboxed about:srcdoc and data
urls remain isolated. They continue to not have API privileges, but
their process is not included in the extensions ProcessMap, which
improves security and fixes the linked bug.
Summary:
This CL makes sure that, when IsolateSandboxedIframes is enabled,
sandboxed extension frames are not placed into the ProcessMap if they
are (i) manifest sandboxed, (ii) sandboxed about:srcdoc or
(iii) sandboxed data urls; but as of this CL their process is not
included in the extensions ProcessMap, which improves security and
fixes the linked bug. Any other sandboxed extension frame is
placed in the main extension process which is in the ProcessMap.
Bug: 40243274
Change-Id: Ia3d2c855f86b84d46e01a0bc7812af00b50de7bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5535370
Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1315183}
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}
Move files related to the implementation of COOP into their own
subdirectory.
modifying code. The dangling pointer in question is an existing one.
DanglingUntriaged-notes: This CL is simply renaming files and not
Bug: 333861718
Change-Id: I18ed55283f9f3fd61cbe4feb7fa5241c7814e585
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5447013
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Camille Lamy <clamy@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1288452}
This new bit will make the storage partition config to preserved
across navigation (similar to the "is_guest" bit).
Also switch the isolated PWA to use this instead of guest SiteInstance.
Bug: b/304851565
Change-Id: I43755d6bce622749dbe6cca2ae5ac170e381bbba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5012192
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Jason Lin <lxj@google.com>
Reviewed-by: Glen Robertson <glenrob@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1227266}
In crrev.com/c/4445209 we added some metrics detailing related active
contents to investigate the conditions of a page that is not bfcached
because of related active contents existence, but since it uses the
count of documents in each SiteInstance, it can't differentiate when
the documents are actually cross-site and can never be same origin
even after document.domain modification (i.e. they can never access
each other synchronously) but share the same SiteInstance (the default SiteInstance), which is possible on Android.
This CL make us use per-url-derived-SiteInfo document counts instead,
which will handle the default SiteInstance case, because it uses the
navigation's real UrlInfo instead of the SiteInstance's SiteInfo
which would be set to unisolated.invalid. This means documents that
can never be same origin (because their 'real' site URLs are
completely different from each other) won't be counted.
Bug: 1444759
Change-Id: I6bc460083256bbcede6d6177c08edee5fad2cb0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4603703
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1159349}
Currently, two unit tests are relying on
ContentBrowserClient::SiteInstanceDeleting() to ensure that
SiteInstance lifetimes are managed properly. However, it is
undesirable to allow //content embedders to run arbitrary code during
SiteInstance destruction, per the linked bug. Hence, this CL converts
SiteInstanceDeleting() usage to a test-specific callback instead and
removes it from ContentBrowserClient.
Bug: 1444438
Change-Id: I2affcb4a40ccfbf3bd715d7b225976a687405616
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4564316
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1149171}
Currently the existence of related active contents prevents a page
from getting into BFCache. We are interested in lifting that
restriction (for the non-synchronously accessible cases), and need
some data on the patterns (and to determine whether we should pursue
the synchronously accessible case too) first.
This CL adds metrics to track the number of related active contents
and whether a navigated away page is potentially synchronously
accessible by other pages, which will be useful to figure out how
much we need to care about potentially synchronously accessible vs
only asynchronously accessible pages.
WIP Doc: https://docs.google.com/document/d/1m92DOkGeU15iUzxnXWVj8CpslOyz1YrAVp7gAkOl7O4/edit#
Bug: 1444759
Change-Id: I7caff0c822a5ccf0daf2a463d2b6b91f153dcedc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4445209
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1147623}
This patch adds simple UnguessableTokens in BrowsingInstance and
CoopRelatedGroup, with accessors in SiteInstanceImpl. These will be used
to verify cross-BrowsingInstance window accesses in the renderer.
Because the usages of the CoopRelatedGroupId can all be replaced by the
token, we update current usages with the token flow and remove
the Id altogether.
This patch makes no behavior change.
Bug: 1221127
Change-Id: I08b07ac8eca540c38f34e001260c2628832a3cf2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4224333
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1142728}
This patch implements proxy management that supports cross-
BrowsingContext group communication. Proxy creation takes into account
the properties restrictions that will be applied, and only provide the
minimal number of proxies to support the valid use cases:
- Only the opener and openee are exposed across the BrowsingContextGroup
boundary.
- Proxies may be created on demand to support postMessage's
event.source.
- A minimal chain of ancestors for subframe proxies, required by the
way Chrome implements proxies.
This prevents XSLeaks by scanning proxies existence. Details are
available here:
https://docs.google.com/document/d/1TaC1gk_54B_hpBeIopqG4wgkTk1kZOha7I_P2nMRKSs/edit?usp=sharing&resourcekey=0-TiQk3dQsHngZMIsQOueDug
Proxy creation implies modifications mostly to RenderFrameHostManager,
while deletion is a simple change in BrowsingContextGroupSwap.
The rest of this patch makes sure that we are actually considering
proxies that might now exist across BrowsingInstances. In practice,
this is all the call sites of SiteInstance::IsRelatedSiteInstance().
In particular:
- postMessage should be permitted across BrowsingInstances in the same
CoopRelatedGroup.
- Navigation should not be permitted across BrowsingInstances.
- Closing windows should not be permitted across BrowsingInstances.
- Proxy can exist across BrowsingInstances, and the sanity check
planned in BrowsingContextState now needs to be about
CoopRelatedGroup.
New browser tests are added to verify the behaviors listed above. WPTs
are updated to reflect the current state of development: openers now
provide access to cross-origin properties (apart from some that are
validated by the browser, like window.close() and navigations). They
will be restricted to only window.closed and window.postMessage() in a
follow-up patch, by renderer-side checks.
Low-Coverage-Reason: BrowsingContextState new mode is unfinished
and untestable in conjunction with COOP. A disabled test was added with
a TODO to cover this code once the feature is implemented.
Bug: 1221127, 1370346
Change-Id: I681daa22583e05cce8051349ed38658248185e0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4200260
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1136447}
There are corner cases where about:blank can't stay in the source
SiteInstance, such as when the navigation to about:blank occurs from
an error page SiteInstance or if it requires a new BrowsingInstance.
Currently, in such cases, we place about:blank in an unassigned
SiteInstance and an unlocked process. However, this is problematic if
the navigation is renderer-initiated and carries an initiator origin,
since it might result in committing about:blank in an unlocked process
but with an initiator origin for a site that requires a dedicated
process. This fails Citadel enforcements that we're hoping to enable
for desktop platforms in issue 764958.
This situation happens in a couple of existing tests:
- UnassignedSiteInstanceBrowserTest.RendererInitiatedNavigationTo uses
a renderer-initiated navigation to about:blank where the old page
may get bfcached, and with bfcache the about:blank document must
commit in a new BrowsingInstance and new SiteInstance, which is
currently unassigned, yet about:blank still carries the initiator's
origin which might require a dedicated process.
- ChromeNavigationBrowserTest.RedirectErrorPageReloadToAboutBlank uses
an extension that redirects navigations to about:blank via
webRequest, starting from an error page which makes the source
SiteInstance incompatible. This CL adds a test for a similar
scenario that also involves navigating to about:blank from an error
page, but without an extension redirect. See the linked bug for
more details.
This CL modifies UrlInfo's origin to carry the initiator origin for
renderer-initiated about:blank navigations. This origin is not going
to be used in the common case where about:blank is left in the source
SiteInstance and an existing process. But if we end up needing to
create a new SiteInstance and compute its SiteInfo and ProcessLock for
an about:blank navigation, this will ensure that we would honor the
initiator origin, if it was present. As a result, about:blank in such
a case will now load in a SiteInstance corresponding to the
initiator's site, and its process will also be locked to that site (if
the site requires a dedicated process).
Bug: 1426928
Change-Id: I19d0265a4f0e6aae7ad732fe92b28c58bcb17c1e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4362801
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1124841}
This function has expanded in its use and is no longer used solely for
reusing the current SiteInstance's process. In particular, it can now
also be used for reusing other kinds of processes, including a
speculative RFH's process (for COOP) and an embedder's process (for
fenced frames). So rename the function to be more generic. This is
a followup to CL:4205941.
Bug: 1411606
Change-Id: I12e09e3e311f34155b46ecd2a68a75253c82b9a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4383216
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1124278}
Previously, SiteInstanceGroup held a BrowsingInstanceId. By having
SiteInstanceGroup hold a scoped_refptr to BrowsingInstance, it ensures
the BrowsingInstance outlives all of the SiteInstanceGroups that exist
in it. This prevents lifetime issues like use-after-frees of
BrowsingInstance.
Test: SiteInstanceGroupTest.BrowsingInstanceLifetime
Bug: 1195535
Change-Id: I2d636ceaa970717439ec9949a6782ad25a630d6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4240375
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1116707}
This is the core patch of the COOP: restrict-properties
implementation. It introduces an important abstraction, the
CoopRelatedGroup. It represents a grouping of BrowsingContext groups
(BrowsingInstance) that are capable of a limited set of asynchronous
interactions, namely postMessage and closed.
It is built as closely as possible to how BrowsingInstance is built
on SiteInstance:
- It is fully private, and interacted with through SiteInstance and
BrowsingInstance. SiteInstance exposes a single new method,
GetCoopRelatedSiteInstance(), that works similarly to the
GetRelatedSiteInstance() method, but at the CoopRelatedGroup level.
- It is collectively owned by the BrowsingInstances that are part of
it. A register/unregister mechanism is used to know about the
BrowsingInstances that are still part of the group.
- It might reuse an existing BrowsingInstance when necessary, similar
to how SiteInstance's are reused within a BrowsingInstance.
To support BrowsingInstance reuse, some information needs to be
available to the CoopRelatedGroup when doing the selection. In
particular it needs to know whether the BrowsingInstance
hosts COOP: restrict-properties pages, and from which origin. We
record that information from the NavigationRequest into UrlInfo.
The SiteInstance picking algorithm is updated to output a SiteInstance
created via GetCoopRelatedSiteInstance() when a
BrowsingContextGroupSwap::kCoopRelatedSwap is requested.
Added browser tests and unit tests cover the newly introduced code.
Bug: 1221127, 1385827
Change-Id: Ief8436b5d532b6aadc5d9a29d94346e3fae2641c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3948564
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1112861}
This patch is the second implementation step for COOP:
restrict-properties. It passes the value produced by CoopStatus into
the SiteInstance picking process to decide what
BrowsingContextGroupSwap to produce.
Before this patch, CoopStatus knows about the different type of swaps, but does not pass the information into the SiteInstance picking process.
A related swap is considered as a no swap.
After this patch, the SiteInstance picking process gets the
information and produces correct internal representation. It enforces
it in the same way as other COOP swaps, however. Implementing the COOP
group to produce visible differences between COOP swaps is the next
step.
Bug: 1221127
Change-Id: If74c44a73c0f1dd7bce2f8125556c636c08feb81
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3945190
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1099288}
This removes 22 static_cast<SiteInstanceImpl*> instances and makes
RenderFrameHostManager consistent about using SiteInstanceImpl.
This also cleans up several related files that required similar
changes in order to compile.
No behavior change is expected.
Bug: 1394513
Change-Id: Ib10d9fec454fdfbd77ce41a8e90bafa2173e9df5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4129800
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1090871}
This code does not appear to be doing anything useful at this
point. This is because in the session restore flow, we already
create the restored SiteInstance via CreateForURL from:
tab_util::GetSiteInstanceForNewTab()
chrome::(anonymous namespace)::CreateRestoredTab()
chrome::AddRestoredTab()
It appears that the behavior of
tab_util::GetSiteInstanceForNewTab() might've evolved, but now it
calls CreateForURL() for all URLs except for those where
ShouldAssignSiteForURL(url) is false (but this case is also
skipped by the logic being removed here).
The implementation of CreateForURL() already calls SetSite(),
which means that when we get to DetermineSiteInstanceForURL(),
`current_instance`'s HasSite() will be true and we will never hit
the dest_is_restore logic.
Other considerations for removing this logic include:
- DetermineSiteInstanceForURL() shouldn't really have side
effects.
- session restore no longer loads all the restored tabs right
away, deferring most of them until the user focuses them.
- the process-per-site behavior of restored tabs should also be
ensured outside of this function. In particular, GetProcess()
is already called before getting to DetermineSiteInstanceForURL
on restored SiteInstances, via the following stack:
content::RenderProcessHostImpl::GetProcessHostForSiteInstance()
content::SiteInstanceImpl::GetProcess()
content::RenderFrameHostManager::CreateRenderFrameHost()
content::RenderFrameHostManager::InitRoot()
content::FrameTree::Init()
content::WebContentsImpl::Init()
content::WebContents::CreateWithSessionStorage()
chrome::(anonymous namespace)::CreateRestoredTab()
chrome::AddRestoredTab()
Thus, GetProcessHostForSiteInstance() should be able to ensure that
process-per-site cases behave correctly. Unfortunately, there's
currently an independent bug with that for NTP in crbug.com/1399874,
but it should be fixed in a different way; the logic being removed
here won't help it due to the reasons explained above.
Change-Id: Ia0695a861b01b8c2167e5a32fa10ee92b5675b42
Bug: 1394513, 1399874
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4089811
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1084596}
In per-origin mode for process-isolated sandboxed iframes, at present
a sandboxed srcdoc iframe will attempt to clone its parent's
SiteInstance, with the only difference being that the sandbox flag is
set. But the parent's SiteInstance will be using a site-based site-url,
and this will cause the child to attempt to load itself in a process
with a site-based, and not origin-based, site_url.
This CL revises the cloning process to take into account the parent's
origin (which the srcdoc frame will use), and creating a consistent
SiteInstance by recreating the SiteInfo via SiteInfo::Create. This will
use the same pathways for creation of the SiteInfo as if it had been
created for a navigation.
Bug: 1345491
Change-Id: I2870d01f3e916f28784b3d5adb749d9c58edacc2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3854030
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1047598}
With kIsolateFencedFrames enabled, ServiceWorkers created by a fenced
frame are not allowed to be put in the same process as the fenced
frame due to is_fenced not being set for their SiteInstances. This
CL sets is_fenced based on the ancestor type of the ServiceWorker.
Bug: 1340662
Change-Id: I8a6309d3d62594933a5dac928dc98c934aee8f07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3854989
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1044033}
This CL implements process isolation for fenced frames (isolating
fenced frames from their embedders) behind a flag. It adds an
'is_fenced' attribute to SiteInfo and IsolationContext to help enforce
this isolation. Having the is_fenced bit in IsolationContext is used to
maintain the same value of is_fenced for all related SiteInstances
created in a particular BrowsingInstance (e.g., for subframes of a
fenced frame).
The changes here currently only have an effect when
the flag is enabled and strict site isolation is enabled. Changes for
other site isolation modes will be in future CLs. See attached bug for
more details on design (design doc, explainer).
Bug: 1340662
Change-Id: I821943158286c9fa69639ad1156112bd74a4410e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3821704
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1041755}
In crrev.com/c/3645368, we made the initial fenced frame SiteInstance
reuse its embedder's process - and then relied on
REUSE_PENDING_OR_COMMITTED_SITE to force process reuse for future
navigations in the frame. However, this doesn't work when strict site
isolation isn't enabled. Setting the initial fenced frame SiteInstance
would set the process correctly for the default SiteInstance
initially, but if we navigated the frame to a site that required a
dedicated process, and then back to a site that didn't, we would
create a new default SiteInstance and allocate it a brand new
process instead of reusing the embedder's process.
This change adds logic in RFHM::GetSiteInstanceForNavigation that
tries to make BrowsingInstances of a non-fenced FrameTree and any
embedded fenced FrameTrees share the same default process. It does so
by searching through these frame trees and proactively reusing their
default process when returning a SiteInstance in a BrowsingInstance
that doesn't have a default process yet.
Change-Id: Icbb4d29f581f56bc0bc0d495e134a5e4bd42092f
Bug: 1326594
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3749074
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1029354}
This CL adds a "per-document" isolation grouping for isolation of
sandboxed iframes using the kIsolatedSandboxedIframes flag. This CL
parameterizes the flag to add "per-document", and when this new
parameter is present it creates a unique document identifier on every
SiteInfo associated with a sandboxed iframe in order to force each
document into its own process. This grouping is expected to be the most
granular option for isolated sandboxed iframes.
Bug: 510122
Change-Id: I217bf5c57f8e9badaa84c0fab9261c432e766fcb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3727308
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1029273}
With the advent of OriginAgentCluster(OAC)-by-default, the number of
navigations getting OAC isolation is expected to increase dramatically. Prior to this CL, each time a navigation got OAC (either via header or
OAC-by-default) we had to check if the navigation's origin had ever
been isolated before, and if not do a potentially expensive search of
the frame tree and session history to verify that we hadn't previously
encountered the origin in the current BrowsingInstance.
To avoid OAC-by-default causing a performance regression due to many
additional global walks, this CL refactors the global walk logic so
that it is only invoked when the OAC header is explicitly present,
either for opt-in or opt-out, and not invoked when an origin gets
OAC-by-default. Since the number of sites explicitly opting-out is expected to be small, this should help keep the total number of global walks small.
When OAC-by-default is enabled, we will explicitly track all origins
that have sent the OAC header, along with the requested opt-in or
opt-out state. All untracked origins will be assumed to have the
default OAC-enabled state.
When OAC-by-default is not enabled, we continue to track only origins
that have explicitly requested opt-in via the header.
This CL also renames a number of functions used in the global walk
to make their behavior more easily understood.
More details about the global walk and this refactor/redesign can
be found at
https://docs.google.com/document/d/1zrMXDOXDhp4-qFZvkZkDVSuqsT718Y-kRVRPqestiMY/edit?usp=sharing
Bug: 1259920
Change-Id: I0a31641eebe187f3961ddfcb2a2d1977a7a3f1f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3763843
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1027872}
Before, a SiteInstanceGroup had a RenderProcessHost
(and AgentSchedulingGroup) that could go away and be set again. This
change makes it so that the SiteInstanceGroup goes away when its
RenderProcessHost gets destroyed. This only happens after all
RenderFrameHosts, RenderFrameProxyHosts and workers in a
RenderProcessHost go away. This usually only happens when a SiteInstance
is solely kept alive in session history (i.e. NavigationEntry).
SiteInstances belonging to this group will get a new SiteInstanceGroup
with a new RenderProcessHost on the next call to
SiteInstanceImpl::GetProcess.
Bug: 1294045
Change-Id: Ic372fe33d3b968a9ee9919d1c03e207b5df6db85
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3440449
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1002957}
With MPArch, we can have nested frame trees and so FTN::IsMainFrame
cannot be used to determine if the frame is outermost. This CL changes
a number of simpler cases where semantics match outermost. This should
have no effect outside the use of MPArch-based nested frame trees (only
fenced frames at the moment).
A number of usages do not have tests included in this CL, but I have
added TODOs for these, similar to the approach taken in
crrev.com/c/2988476.
This is a follow on to crrev.com/c/3577677
This CL also removes a number of expired histograms:
- Navigation.CommitTimeout.ErrorCode
- Navigation.CommitTimeout.IsMainFrame
- Navigation.CommitTimeout.IsRendererProcessReady
Bug: 1314749,1053061
Change-Id: I09507b1dce358507999e706b9ea81b087b16fc9f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3584183
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Ian Vollick <vollick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#993707}
The OriginAgentCluster (OAC) metrics for process overhead,
Memory.RenderProcessHost.Count.OriginAgentClusterOverhead and
Memory.RenderProcessHost.Percent.OriginAgentClusterOverhead
do not allow us to distinguish between the cases where a user just
hasn't encountered any origins using OAC, and those where an origin
is process isolated, but doesn't incur any process overhead.
This CL adds logic to activate a synthetic trial group the first time
a browsing session process-isolates an origin. This will allow us to
distinguish between the two no-overhead cases.
Bug: 1171269
Change-Id: I4cd7e6d83106ed7d821079c6a22af250688d0bee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3542930
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#985514}
Use the new ability to write typed messages into the untyped and untyped
into typed to eliminate WriteIntoTrace(TracedValue) /
WriteIntoTrace(TracedProto) duplicated methods in //content.
After this patch, all key //content types listed below now have
corresponding proto messages (with DebugAnnotation support) and
WriteIntoTrace(TracedValue) methods have been removed:
- BrowserContext
- BrowsingContextState
- FrameTreeNode
- NavigationRequest
- RenderFrameHost
- RenderFrameProxyHost
- RenderViewHost
- SiteInstance
- SiteInstanceGroup
- GlobalRenderFrameHostId
This patch also adds a few `const` qualifiers to the appropriate methods
in //content to ensure that all WriteIntoTrace methods can be marked as
const.
R=rakina@chromium.org
Bug: 1137154
Change-Id: I306e7619f594e2a02ca24183720714f234661ff4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3540169
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alex Ilin <alexilin@chromium.org>
Commit-Queue: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#984436}
This CL implements process isolation for origin-restricted sandboxed
iframes, i.e. those with the 'sandbox' attribute but no 'allow-origin'
modifier.
At present this CL implements a model where all the sandboxed iframes
for a site are placed in the same process, though this could be modified
to be (i) origin-specific, and/or (ii) place each sandbox into its own
process regardless of site-/origin-keying of the sandboxes.
Bug: 510122
Change-Id: If02a02d05a02552ef4b1a0a01145e7c26d9dc98e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3416475
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#969578}
This change moves functionality on SiteInstanceImpl to
SiteInstanceGroup, as it will be group-based. This includes the Observer
interface, and the AgentSchedulingGroupHost and RenderProcessHost
members.
A SiteInstanceGroup always starts with a RPH and ASGH, but it can lose
them and later gain new ones. A SiteInstance starts without a
SiteInstanceGroup, but once it gets one it never changes. A SiteInstance
relies on SiteInstanceGroup for its RPH and ASGH. In a followup, we
intend to allow SiteInstances to change their SiteInstanceGroup after
the RPH goes away. See https://crbug.com/1294045.
When RFH is created, we can assume SiteInstance exists, and has a
SiteInstanceGroup, a RPH and an ASGH. Similarly, when RFPH is created,
SiteInstanceGroup, RPH, and ASGH all exist.
Test: No behaviour change
Bug: 1261963
Change-Id: I9dee2331c359c833b3df1748cf9d9a21781a0b59
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3286326
Reviewed-by: Charles Reis <creis@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Sharon Yang <yangsharon@chromium.org>
Cr-Commit-Position: refs/heads/main@{#969118}
This CL adds initial support for enabling site isolation inside
<webview> guests. This mode is behind a new feature called
SiteIsolationForGuests.
The overall approach is to stop using special chrome-guest: site URLs
when creating SiteInfos for guests. Instead, site-isolated guests use
real site URLs that are computed with the existing process model code,
and rely on SiteInfo::storage_partition_config to keep navigations
within guests in the same StoragePartition and in guest SiteInstances.
This CL supports cross-process navigations in guests, OOPIFs, and
cross-BrowsingInstance navigations in guests. A particular guest will
no longer be restricted to a single SiteInstance and BrowsingInstance,
though it will always stay in the same StoragePartition, and for all
SiteInstances in a guest, SiteInstance::IsGuest() will be true.
In the current SiteInstance assignment paths, there are various early
returns that make guests always in the same SiteInstance. Those are
now only used when the new feature is off. Since guests will now
descend much deeper into the SiteInstance assignment paths, we needed
an additional signal as to whether the new SiteInstance/SiteInfo would
be for a guest. To do this, instead of plumbing an additional flag to
places like SiteInfo::CreateInternal, is_guest is added to
IsolationContext which is already plumbed into all the needed code
paths (see SiteInfo::CreateInternal for how it's used). Conceptually,
IsolationContext::is_guest just says whether a particular
BrowsingInstance is for a guest or not, so that any related
SiteInstances within it stay in the guest.
To handle cross-BrowsingInstance navigations in guests,
SiteInstanceImpl::CreateForUrlInfo (which is normally used to create
a new SiteInstance in a new BrowsingInstance) is updated to be able to
handle guests, in which case the StoragePartition info needs to be
transferred into the new SiteInstance/BrowsingInstance.
The following are some things that are not part of this CL and will be
addressed in future CLs:
- converting <webview> tests to run in both the legacy and site
isolation modes. (This CL does add standalone tests to validate
site isolation properties.)
- embedder navigating <webview> to about:blank and siteless
SiteInstances.
- error page navigations, WebViewRendererState, loadDataWithBaseURL.
Bug: 1267977
Change-Id: I3b747640c083a302dc07ee4106af4f6d33928165
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3380343
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Reviewed-by: Charles Reis <creis@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#965525}
(original CL by acolwell@, rebased and submitted by alexmos@)
This is the final patch in the series to migrate the
NavigationControllerImpl::session_storage_namespace_map_ to use a
StoragePartitionConfig instead of a partition ID string. It removes the
StoragePartitionId class and updates all the existing usage to
StoragePartitionConfig. This should not introduce user visible behavior
changes because the current StoragePartitionId implementation is
essentially a wrapper around a StoragePartitionConfig. That change was
made in https://crrev.com/c/2808670, which has reached stable in M93
and raised no issues.
- Removes the StoragePartitionId object and replace usage with
StoragePartitionConfig.
- Removed NavigationControllerImpl::partition_config_to_id_map_ since
it is no longer needed.
- Removed SiteInfo usage from RenderViewHostImpl now that we only
need a StoragePartitionConfig to get the SessionStorageNamespace.
- Added GetStoragePartitionConfig() method to SiteInstance to make
it easier to get the StoragePartitionConfig for a SiteInstance.
This will also make it easier to remove GetSiteURL() usage related
to storage partitions in followup CLs.
- Removed SiteInstanceImpl::GetSiteInfoForRenderViewHost() and
move code that enabled storage partition verification to the new
GetStoragePartitionConfig() method.
Bug: 1166021
Change-Id: Iefc00108e2d1274dc69bd31a7e4d8f667ffea960
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2811120
Reviewed-by: Charles Reis <creis@chromium.org>
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#965388}
