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}
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}
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}
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 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 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}
Default SiteInstances and cross-origin isolation interactions are not
tested. They require site isolation to be off for default SiteInstances
and COOP isolation heuristic to be off (by default). Adding a simple
content browser test to check that SiteInstances can indeed end up in a
default SiteInstance.
BUG=1250349
Change-Id: I18040855e58398f51f610c95ff64de8d64aed797
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3427505
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/main@{#966650}
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}
UrlInfos are converted to SiteInfos to create and compare security
principals. In certain cases it is even converted to a ProcessLock such
as in RenderProcessHostImpl::IsSuitableHost(). When a navigation is
at the speculative stage (and some other niche cases) we won't have a
WebExposedIsolationInfo yet, because we haven't received security
headers or are outside of the standard security model (about:blank for
example). UrlInfo carries an optional WebExposedIsolationInfo but
SiteInfo represents a real object and must have a non optional value.
What do we put in the SiteInfos when converting if it's optional?
That's what this patch is trying to address, by doing the following:
- UrlInfo() and UrlInfoInit() are created with a nullopt value instead
of a CreateNonIsolated() value. If people converting use explicit
UrlInfo constructor, generally to make clear what attributes they're
trying to compare, we will get nullopt in places where we do the
conversions.
- When we're converting using half a UrlInfo, half a
SiteInstance/BrowsingInstance, for example in DeriveSiteInfo(), we
DCHECK that the WebExposedIsolationInfos are compatible. This way we
avoid complicated semantics and possible interpretations.
- We override any optional value with a value that makes sense (usually
the WebExposedIsolationInfo of the class we're half-using.)
- We add one single conversion point from optional to
CreateNonIsolated() at the heart of the SiteInfo constructor, to
accommodate for the cases where a new SiteInstance/BrowsingInstance
must be created at a speculative stage for example.
Bug: 1243449
Change-Id: Ibd7a815c162a789403b1ac9dbd2efdc6f7475315
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3377183
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Cr-Commit-Position: refs/heads/main@{#958524}
This is a reland of 7c47ce7c55
Original change's description:
> Implement OAC Process Count Overhead Metric.
>
> This CL introduces a "process count overhead" metric, based on an
> estimate of how many additional processes are needed for
> OriginAgentCluster (OAC). It's an estimate since we can't control for
> all variables, like the coalescing of SiteInstances from multiple
> BrowsingInstances in a single RenderProcess, or the effects of all
> possible configurations of the SiteInfo parameters.
>
> The estimate is based on counting the total number of HTTPS
> SiteInstances (OAC is only used for HTTPS) by seeing how many unique
> SiteInfos they generate in each BrowsingInstance, then converting each
> SiteInfo to its non-OAC equivalent and counting again, and comparing
> the two counts. The difference is the overhead estimate. This value
> should only be reported for users with cross-process OAC enabled.
>
> Basically, this is a best effort approach because knowing the exact
> process count requires too much knowledge of process creation history.
> It ignores process sharing, which is usually (but not always) an upper
> bound on the actual overhead.
>
> Bug: 1171269
> Change-Id: I31781bc8dedcb7c4849776d82aacb2890f255142
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3182871
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
> Reviewed-by: Tom Sepez <tsepez@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#941335}
Bug: 1171269
Change-Id: Ia37fed48f67732d1604f749e4baa98badab85bfb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3281181
Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Benoit L <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#942296}
This reverts commit 7c47ce7c55.
Reason for revert: Hit submit too quickly, still needs histograms.xml review.
Original change's description:
> Implement OAC Process Count Overhead Metric.
>
> This CL introduces a "process count overhead" metric, based on an
> estimate of how many additional processes are needed for
> OriginAgentCluster (OAC). It's an estimate since we can't control for
> all variables, like the coalescing of SiteInstances from multiple
> BrowsingInstances in a single RenderProcess, or the effects of all
> possible configurations of the SiteInfo parameters.
>
> The estimate is based on counting the total number of HTTPS
> SiteInstances (OAC is only used for HTTPS) by seeing how many unique
> SiteInfos they generate in each BrowsingInstance, then converting each
> SiteInfo to its non-OAC equivalent and counting again, and comparing
> the two counts. The difference is the overhead estimate. This value
> should only be reported for users with cross-process OAC enabled.
>
> Basically, this is a best effort approach because knowing the exact
> process count requires too much knowledge of process creation history.
> It ignores process sharing, which is usually (but not always) an upper
> bound on the actual overhead.
>
> Bug: 1171269
> Change-Id: I31781bc8dedcb7c4849776d82aacb2890f255142
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3182871
> Reviewed-by: Charlie Reis <creis@chromium.org>
> Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
> Reviewed-by: Tom Sepez <tsepez@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#941335}
TBR=creis@chromium.org,tsepez@chromium.org,alexmos@chromium.org,lizeb@chromium.org,wjmaclean@chromium.org,caitlinfischer@google.com,chromium-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: Icc51b7a8d4b894f968c9805baa2cafaa73cdd385
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1171269
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3278353
Reviewed-by: W. James MacLean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Katie Dektar <katie@chromium.org>
Owners-Override: Katie Dektar <katie@chromium.org>
Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941341}
This CL introduces a "process count overhead" metric, based on an
estimate of how many additional processes are needed for
OriginAgentCluster (OAC). It's an estimate since we can't control for
all variables, like the coalescing of SiteInstances from multiple
BrowsingInstances in a single RenderProcess, or the effects of all
possible configurations of the SiteInfo parameters.
The estimate is based on counting the total number of HTTPS
SiteInstances (OAC is only used for HTTPS) by seeing how many unique
SiteInfos they generate in each BrowsingInstance, then converting each
SiteInfo to its non-OAC equivalent and counting again, and comparing
the two counts. The difference is the overhead estimate. This value
should only be reported for users with cross-process OAC enabled.
Basically, this is a best effort approach because knowing the exact
process count requires too much knowledge of process creation history.
It ignores process sharing, which is usually (but not always) an upper
bound on the actual overhead.
Bug: 1171269
Change-Id: I31781bc8dedcb7c4849776d82aacb2890f255142
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3182871
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Caitlin Fischer <caitlinfischer@google.com>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: W. James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941335}
This inlines all remaining DISALLOW_* macros in content/. This is done
manually (vim regex + manually finding insertion position).
IWYU cleanup is left as a separate pass that is easier when these macros
go away.
Bug: 1010217
Change-Id: I8b5ea6dd9f8a3f584cf3eef82634017a38b15be8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3193883
Commit-Queue: Peter Boström <pbos@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#936160}
We pass the WebExposedIsolationInfo all around the process model code,
but we already have a structure that is meant to package all the
information needed take these decisions: UrlInfo.
This patch bundles WebExposedIsolationInfo into UrlInfo, hopefully
simplifying and clearing up the code base.
The way we achieve this:
- Add WebExposedIsolationInfo into UrlInfo in site_instance_impl.h
- Move the computation of WebExposedIsolationInfo from
RenderFrameHostManager::GetWebExposedIsolationInfo to
NavigationRequest::ComputeWebExposedIsolationInfo, as a part of
NavigationRequest::GetUrlInfo, effectively embedding isolation status
into UrlInfo.
- Remove WebExposedIsolationInfo parameters in functions where we also
pass UrlInfo.
Change-Id: I4f808bf168e71da8d492a09be76a9c164fb4b867
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3101045
Commit-Queue: Arthur Hemery <ahemery@chromium.org>
Reviewed-by: W. James MacLean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#916398}
This CL enforces that all SiteInstances in a BrowsingInstance use the
same StoragePartition, and makes all related sites inherit their
StoragePartition rather than always asking the embedder which to use.
More specifically, this CL makes the following changes:
* Updates BrowsingInstance to CHECK that all member SiteInstances have
the same StoragePartitionConfig (SPC).
* Makes BrowsingInstance:: ComputeSiteInfoForURL propagate the existing
SPC into the new SiteInfo. This function is used when creating
related SiteInstances, and ensures that related sites inherit the SPC
of their parent.
* Refactor SiteInstanceImpl::IsNavigationSameSite to reuse some of its
logic in RFHM::ShouldSwapBrowsingInstancesForNavigation's
StoragePartition check to avoid breaking hosted apps.
ShouldSwapBrowsingInstancesForNavigation will now force a
BrowsingInstance swap when navigating a top-level frame to a URL that
requires a different StoragePartition.
Bug: 1212266, 1229912
Change-Id: Id94c1ca09879eed09c20f7c23fec5f5ca2aa4677
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3025080
Commit-Queue: Robbie McElrath <rmcelrath@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#908340}
This is the first in a series of changes that will implement the
SiteInstance groups feature. This change simply introduces a new class
to implement the SiteInstance grouping policies and moves the logic
related to the "default process" model into this class. Actual
grouping logic will be added in follow up CLs and build upon the hooks
that are used for the "default process" mode.
Bug: 1195535
Change-Id: I0b37552a0d35498cfeef3e83c05c04f143ea124c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2803671
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#870209}
Refactor default SiteInstance code so that most of it is in
SiteInstanceImpl instead of BrowsingInstance. This makes the code
simpler and easier to follow.
Bug: 1085275
Change-Id: I40eee7f12500616ff8b7d61e088fe1d717e7eeef
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2538363
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#829006}
This CL plumbs a bit from NavigationRequest::OnResponseStarted() via
all pathways to ShouldOriginGetOptInIsolation(). This will allow
removing the scoping mechanism previous used to determine when a
NavigationRequest is trying to opt an origin into isolation, and
resolve the associated bug in the process.
Bug: 1099718
Change-Id: I98e0a9cf5974aae84d4895468734efefd427ddc4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2411423
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/master@{#812744}
Renamed the single param version of GetSiteInfoForURL() to
ComputeSiteInfoForURL() to make it a little more clear that these
functions behave differently in subtle ways. The new name reflects
that this method behaves like SiteInstanceImpl::ComputeSiteInfo().
This change also updates a few pieces of code to go through this
renamed method so that it is clear that each of these places expect the
same behavior. There are no behavior changes.
Bug: 1085275
Change-Id: Ie1a1911c5d92ba620789f456f10cdc732ee95244
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2399450
Auto-Submit: Aaron Colwell <acolwell@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#805320}
The third CL in implementing origin-/site-keying of SiteInstances.
https://crbug.com/1085275/#c2 lists the sequence of CLs and what each
will accomplish.
This CL replaces uses of site URL as map keys with SiteInfo in
BrowsingInstance and RenderProcessHostImpl. As a result, maps will be
able to distinguish SiteInfos based on additional criteria, such as
site vs origin keying.
Bug: 1067389, 1085275
Change-Id: Iae821dfb6314968fbe059732ff3c97e84add4212
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2261216
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#789285}
The second CL in implementing origin-/site-keying of SiteInstances.
https://crbug.com/1085275/#c2 lists the sequence of CLs and what each
will accomplish.
This CL is a refactor to introduce the ProcessLock class to replace
the GURLs returned by GetOriginLock() and related functions.
It also combines some argument lists that take both a SiteURL and a
LockURL and instead uses SiteInfo or ProcessLock. One notable example
is RenderProcessHostImpl::IsSuitableHost().
Bug: 1067389, 846155
Change-Id: I3c6f67f2bf6f1ce3ed2bc394dbd92827ebd8a50a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2246923
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#788226}
If the file just needs the CHECK/CHECK_OP/NOTREACHED
macros, use the appropriate header for that instead.
Or if logging.h is not needed at all, remove it.
This is both a nice cleanup (logging.h is a big header,
and including it unnecessarily has compile-time costs),
and part of the final step towards making logging.h no
longer include check.h and the others.
Bug: 1031540
Change-Id: I3985bda6743382d5c0a612e43890a35c02182258
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2254123
Commit-Queue: Avi Drissman <avi@chromium.org>
Auto-Submit: Hans Wennborg <hans@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#780586}
The first CL in implementing origin-/site-keying of SiteInstances.
https://crbug.com/1085275/#c2 lists the sequence of CLs and what each
will accomplish.
This CL introduces a SiteInfo class, which contains the site url, and in
future will contain other state. This CL also modifies call sites in
content/ to GetSiteURL() and GetSiteForURL() to use SiteInfo.
Bug: 1067389
Change-Id: Ie1ae511a259414f22a71dd139896b11bfb029b01
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2236236
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#777845}
This change allows a top-level empty SiteInstance to become the default
SiteInstance if the URL for the top-level frame does not require a
dedicated process. This allows the top-level frame and any subframes
that do not require a dedicated process to share the same default
SiteInstance process.
Bug: 958060,78757
Change-Id: I920860b822474157897a0f3e3534cca87984599c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1693778
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#680472}
- Added code that enables the default SiteInstance to use an unmatched
service worker process for a site that is handled by the default SiteInstance.
- Remove default SiteInstance specific conditions from tests that were
testing process reuse and unmatched service worker process behavior.
- Added code to BrowsingInstance that tracks what site URLs are associated
with its default SiteInstance. This allows process reuse to be constrained
to sites explicitly associated with a specific default SiteInstance.
Bug: 958060
Change-Id: I9ce95dbd5ecc192cba8cd4e6046787d248ff3532
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1668449
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#672681}
Removing reference cycle between BrowsingInstance and default
SiteInstance that was accidentally introduced in
http://crrev.com/c/1452714 .
This is an updated version of http://crrev.com/c/1610991 which
fixes the two issues in that original change.
- It fixes a bug where the default SiteInstance was accidentally
getting added to |site_instance_map_|
- It prevents the new test case from running on build bots that run
with --site-per-process since default SiteInstances are not created
in that situation.
Bug: 958683
Change-Id: I6803898c96604998380dd2ec56b7fdba2527b573
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1614497
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#660558}
These changes are primarily to reduce the number of unique
SiteInstanceImpl::GetSiteForURL() call sites to make it easier to
transition these pieces of code to handle default SiteInstance URLs.
- Added BrowsingInstance::GetSiteForURL() helper to ensure all code
inside the class is using the same method to compute site URLs.
- Added NavigationRequest::GetSiteForCommonParamsURL() to help ensure
that |site_url_| is consistently updated with a site URL generated
from common_params_.url.
Bug: 787576
Change-Id: Ife661aa4d10ee649f367dae91bf82e3b364b702a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1582275
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Auto-Submit: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#654068}
This CL removes BrowserContext from BrowsingInstance, since it is
already stored in the BrowsingInstance's IsolationContext. It also
removes BrowserContext from GetSiteForURL functions.
Future CLs will clean up other process model functions that take both
a BrowserContext and IsolationContext (such as
DoesSiteRequireDedicatedProcess) to only take IsolationContext.
Bug: 905513
Change-Id: Ibea91690930445a5c2d192476ad7180642dd2168
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1516098
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#639678}
This changes SiteInstance's site URL to unisolated.invalid for any
SiteInstances that can be shared among multiple sites. A SiteInstance
with a valid site URL will only contain documents from that site URL.
Note that this will cause more documents to end up in the
BrowsingInstance's default SiteInstance when full Site Isolation is
not enabled.
This change fixes some cases where same-origin iframes of a page might
have ended up in different processes from each other, when partial
Site Isolation is enabled.
Specifically:
- Added a default SiteInstanceImpl that can be used for URLs that are
not already associated with a SiteInstanceImpl AND do not need to be
in their own process.
- Added a test case that verifies that iframes that do not need to be
in their own process do share a SiteInstanceImpl with their parent.
Bug: 787576
Change-Id: I3915f4d5e2e1d1074250de649c63cb33290fc50b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1452714
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#638857}
This should guarantee that a SiteInstance only contains a single site
url which accurately reflects the documents it contains, rather than
allowing a SiteInstance to contain documents from multiple sites when
strict site isolation is disabled.
The renderer process will have separate FrameTrees for each
SiteInstance, so when this mode is enabled without strict site
isolation, we will attempt to co-locate SiteInstances from the same
BrowsingInstance in a single process, to minimize the creation of
unnecessary processes.
Bug: 928390
Change-Id: I45b643912676b6fcec4b0c8ae5fd1c3dc7dd4176
Reviewed-on: https://chromium-review.googlesource.com/c/1423134
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#628978}
This CL introduces an ability to add isolated origins at any time, rather
than only at browser startup. Isolated origins added dynamically will
apply only to future BrowsingInstances and processes.
To do this, the calls involved in making process model decisions and
looking up isolated origins, such as DoesSiteRequireDedicatedProcess,
need to be aware of which BrowsingInstance is asking. This CL adds
the required plumbing in the form of a new IsolationContext object.
For now, IsolationContext only contains the BrowsingInstance ID, but
in the future it will be extended to include BrowserContext info as
well, allowing isolated origins to also be scoped to particular
profiles. Calls that currently take both BrowserContext and
IsolationContext will be able to simply pass an IsolationContext.
Design doc: https://goo.gl/4xVPKW
Bug: 905513
Change-Id: I5d6fb7724524e85efe492da26077209fa90be1bf
Reviewed-on: https://chromium-review.googlesource.com/c/1377616
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622715}
