This change introduces a Handle object so that Mojo services can
preserve the security state beyond the lifetime of the
RenderProcessHostImpl object. This allows consistent security
checks to occur even during the period when the renderer process is
shutting down and there are still pending Mojo operations in flight.
This will be used to remove all remaining uses of
ChildProcessSecurityPolicyImpl::HasSecurityState() in follow-up CLs.
- Implements new Handle object that allows security checks to provide
consistent results after ChildProcessSecurityPolicyImpl::Remove() is
called.
- Convert blob code to use Handle instead of the HasSecurityState()
workaround.
This is an updated version of https://crrev.com/c/1534368 . Further
discussion of the history and reasons for this CL can be found there.
Bug: 1035399, 943887
Change-Id: I6165fad4308643a1ddc845690443e8efceac65f4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1975165
Reviewed-by: Aaron Colwell <acolwell@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#732296}
This CL adds a DumpWithoutCrashing call when a destructor of
content::BrowserContext gets called without an earlier call
to BrowserContext::NotifyWillBeDestroyed.
This CL will hopefully help
1) verify if there are scenarios in the wild, where a
BrowserContext/Profile gets destroyed without calling
BrowserContext::NotifyWillBeDestroyed first
2) find root cause of these scenarios
Bug: 1038844
Change-Id: Ifb40daa27b7b4a4fc301df2ea6f09ffa499fe7d1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1986262
Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#728321}
As a part of moving to storage service, the indexeddb code can't depend
on BrowserThread::IO and will need some other new IO thread. To handle
this, the idb context now exposes an IOTaskRunner (which for now is
still the browser IO thread) which is plumbed everywhere that is needed.
Change-Id: Idef64cb47ab4483b2584ce6d7b19aee25d6add18
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1954724
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#722662}
The service always runs in the browser process. This stuffs a service
instance directly into the MultiDeviceSetupClientFactory KeyedService
and makes it accessible directly to browser code.
Where necessary, minimal changes have been made to allow code outside
of chrome/browser to get at the service instance to bind interfaces.
Bug: 977637
Change-Id: I795683f352dac09cff4fc36cc4eb225df0c03d6a
Tbr: avi@chromium.org
No-Presubmit: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1931563
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#722179}
This sticks a Content Service instance directly in each BrowserContext
rather than having them owned indirectly by BrowserContext via
Service Manager APIs.
The two existing uses are refactored to get NavigableContentsFactory
receivers bound directly through the BrowserContext rather than using
a Service Manager Connector.
Bug: 977637
Change-Id: I4a3e41235e15a8b93973f152e8313d8612bfc290
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1931444
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#721729}
Guest mode on Chrome OS is stored in a in-memory file system anyway,
so using the disk backed sandboxed file system backend should be fine.
This in turn should then make QuickOffice work again in guest mode, as
the disk backed backend supports some PPAPI features that QuickOffice
depends on, which aren't supported by the in-memory backend.
Bug: 1005594
Change-Id: Id65760efe278d5479b68fb7b4cba2df4336c6f73
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1922431
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Ramin Halavati <rhalavati@chromium.org>
Cr-Commit-Position: refs/heads/master@{#719691}
In the past, "content/*/file_system" was renamed to "fileapi"
to contain both the code for the filesystem API and the blob system.
But the blob system moved out to separate directories,
we have the confusing situation that we have directories named
after one API that contain the implementation of a different API.
This patch rename "storage/browser/fileapi" to "file_system"
to actually match for reducing confusion.
Bug: 921260
Change-Id: I18a391b43c054e647d938832f2055580a083437a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1858542
Commit-Queue: DongJun Kim <djmix.kim@samsung.com>
Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Yusuke Sato <yusukes@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#707702}
This reduces the number of preprocessor tokens in
content_browser_client.h from 1,335,281 to 754,474. Since this is a
widely included file, reducing build times a fair bit (see bug).
TBR=tsepez for content/browser/child_process_security_policy_*
Bug: 1014009
Change-Id: Id3c2de29f5b08cab80820d01aff722afeb1618e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1857126
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Ken Rockot <rockot@google.com>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Camille Lamy <clamy@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#706388}
This patch introduces two enterprise policies, one is
kCorsLegacyModeEnabled, and the other is kCorsMitigationList.
kCorsLegacyModeEnabled disbles OOR-CORS feature completely,
and uses the legacy Blink CORS instead. The policy can not be
dynamically modified, and a consistent value is managed by
per-profile instance in the browser process.
Call sites in the browser process checks the OOR-CORS mode
via BrowserContext, and if the actual instance inherits
Profile class, it counts in the policy. If call sites do
not have a corresponding BrowserContext, it directly checks
base::FeatureList.
Call sites in the renderer processes are managed via a
command line flag. The browser process properly sets the
flag based on the OOR-CORS mode that is checked by the steps
described above.
Call sites in the network process should ask the relevant
NetworkContext. Each NetworkContext should initialize the
OOR-CORS mode based on the NetworkContextParams that should
be properly set by the browser process. If the constructor
that does not have the NetworkContextParams argument is called,
base::FeatureList is directly checked to initialize the mode.
Thus, all components for chromium can use a consistent CORS
mode during each profile session.
kCorsMitigationList still activate the OOR-CORS as long as the
feature is not disabled for other reasons. But it adopts
compatibility mitigation to mimic the legacy behavior. E.g.,
it enforces all Extensions to call webRequest API with
"extraHeaders" option, and specified header names are assumed
as CORS-safelisted so that it does not trigger CORS preflights.
Bug: 1000977, 1000984, 1000982
Change-Id: I4166e26405482e479c895db639bb73a4388fc0b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1830253
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#706301}
This removes almost all remaining usage of Connector from child
processes, instead preferring use of ChildProcessHost.BindHostReceiver
to acquire process-scoped interfaces from the browser.
The one remaining use case after this CL is for the Device Service's
PowerMonitor API. This is left as a separate change because it requires
substantial additional support code for testing.
Bug: 977637
Change-Id: I679c6d7f5ec01d1bc1bb6852e0f79a3f1650df34
Tbr: penghuang@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1815731
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#700317}
This is a reland of 749dcc3bc7
PS1->PS4 shows the exclusive delta from the original patch, fixing a subtle
lifetime issue in FileService. This turns out to have always been wrong:
LevelDBServiceImpl can be destroyed before its created
LevelDBDatabaseImpl objects have received all messages, and the service
impl owns the shared message pipe for the associated database interfaces; thus
messages can be dropped and data lost. This never mattered before because
FileService instances effectively lived forever anyway.
The fix here makes LevelDBServiceImpl lifetime independent of FileService
lifetime, tying it instead to client lifetime.
Original change's description:
> Move File Service off Service Manager
>
> This is a first step towards eliminating the File Service and migrating
> DOM Storage code into the Storage Service.
>
> File Service and its only clients (DOM storage objects) are moved off of
> Service Manager APIs. LocalStorageContextMojo and
> SessionStorageContextMojo are changed to own their own FileService
> instance, now constructed directly over a directory path.
>
> No functional changes intended in this CL.
>
> Bug: 994911,977637
> Change-Id: I2ffd0bef670304a0dc3c103981139603521a14ac
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1778801
> Commit-Queue: Ken Rockot <rockot@google.com>
> Reviewed-by: Avi Drissman <avi@chromium.org>
> Reviewed-by: Robert Sesek <rsesek@chromium.org>
> Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#698487}
NOPRESUBMIT=true
Bug: 994911, 977637
Change-Id: I12658247e428f2e5eee32a2e3eabe3eb35381238
Tbr: avi@chromium.org
Tbr: mek@chromium.org
Tbr: rsesek@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1816582
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#699231}
This is a first step towards eliminating the File Service and migrating
DOM Storage code into the Storage Service.
File Service and its only clients (DOM storage objects) are moved off of
Service Manager APIs. LocalStorageContextMojo and
SessionStorageContextMojo are changed to own their own FileService
instance, now constructed directly over a directory path.
No functional changes intended in this CL.
Bug: 994911,977637
Change-Id: I2ffd0bef670304a0dc3c103981139603521a14ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1778801
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#698487}
This CL converts BlobPtr in //third_party/blink and //storage
to mojo::PendingRemote or mojo::Remote.
It also renames GetBlobPtr() to GetBlobRemote() from
BrowserContext and cleans up TakeBlobPtr() from
storage/browser/blob/blob_handle.h.
Bug: 955171, 978694
Change-Id: Iff9bc1862ba9fda0de0a5c29d982dfcd7ec87dd9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1792210
Commit-Queue: Julie Kim <jkim@igalia.com>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#695456}
This CL adds a singleton LearningSession to BrowserContext. This
provides a single location from which to get LearningTaskControllers,
which will allow aggregating observations accross multiple frames.
Bug: 994831
Change-Id: Ibeaf47a09ae7408d0afab9bc113a98e9f1532199
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1758625
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Commit-Queue: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/master@{#688733}
leveldb_proto is a component that allows storing proto objects in a
leveldb database. A client can get a leveldb_proto database by calling a
static method.
This simple API made it easy for developers to integrate leveldb_proto
in their components, this resulted in a large amount of clients, with
each one using a unique leveldb instance. Having multiple db instances
increases memory consumption, as each database caches frequently used
contents.
There has been an effort to move leveldb_proto databases from multiple
instances to a shared instance, to decrease memory consumption and
simplify configuration. As part of this effort the leveldb_proto
database retrieval API was moved from a static method into
db provider given by StoragePartition
This CL migrates VideoDecodeStatsDB to the new API.
Bug: 943170
Change-Id: I1d78286589612a2cf733e3c057af35d9c1396246
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1592193
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Xi Han <hanxi@chromium.org>
Reviewed-by: ssid <ssid@chromium.org>
Commit-Queue: ssid <ssid@chromium.org>
Cr-Commit-Position: refs/heads/master@{#687037}
*** Note: There is no behavior change from this patch. ***
The PostTask APIs will shortly be changed to require all tasks to explicitly
specify their thread affinity, i.e., whether the task should run on the thread
pool or a specific named thread such as a BrowserThread. This patch updates all
call sites with thread affinity annotation. We also remove the "WithTraits"
suffix to make the call sites more readable.
Before:
// Thread pool task.
base::PostTaskWithTraits(FROM_HERE, {...}, ...);
// UI thread task.
base::PostTaskWithTraits(FROM_HERE, {BrowserThread::UI, ...}, ...);
After:
// Thread pool task.
base::PostTask(FROM_HERE, {base::ThreadPool(), ...}, ...);
// UI thread task.
base::PostTask(FROM_HERE, {BrowserThread::UI, ...}, ...);
This patch was semi-automatically prepared with these steps:
1. Patch in https://chromium-review.googlesource.com/c/chromium/src/+/1635827
to make thread affinity a build-time requirement.
2. Run an initial pass with a clang rewriter:
https://chromium-review.googlesource.com/c/chromium/src/+/1635623
3. ninja -C out/Debug | grep 'requested here' | cut -d: -f1-3 | sort | \
uniq > errors.txt
4. while read line; do
f=$(echo $line | cut -d: -f 1)
r=$(echo $line | cut -d: -f 2)
c=$(echo $line | cut -d: -f 3)
sed -i "${r}s/./&base::ThreadPool(),/$c" $f
done < errors.txt
5. GOTO 3 until build succeeds.
6. Remove the "WithTraits" suffix from task API call sites:
$ tools/git/mffr.py -i <(cat <<EOF
[
["PostTaskWithTraits", "PostTask"],
["PostDelayedTaskWithTraits", "PostDelayedTask"],
["PostTaskWithTraitsAndReply", "PostTaskAndReply"],
["CreateTaskRunnerWithTraits", "CreateTaskRunner"],
["CreateSequencedTaskRunnerWithTraits", "CreateSequencedTaskRunner"],
["CreateUpdateableSequencedTaskRunnerWithTraits", "CreateUpdateableSequencedTaskRunner"],
["CreateSingleThreadTaskRunnerWithTraits", "CreateSingleThreadTaskRunner"],
["CreateCOMSTATaskRunnerWithTraits", "CreateCOMSTATaskRunner"]
]
EOF
)
This CL was uploaded by git cl split.
R=boliu@chromium.org, tsepez@chromium.org
Bug: 968047
Change-Id: I346372d16a3856186ea74d14e0dd8a12f7cacae5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1729589
Commit-Queue: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#683554}
We tear down BrowserContext-bound Service Manager services when the
BrowserContext is being torn down, but the relevant state which receives
service requests from the Service Manager is on the IO thread. This
means we can end up hitting races where some client of a service
reconnects to the service and triggers the service-startup path
immediately after BrowserContext destruction, which in turn can violate
service's expectations about shutdown behavior.
This CL fixes that by explicitly posting to disable all service request
handling prior to initiating any service instance destruction.
Bug: 987473
Change-Id: I488d8fbed19bc50efc1b8ea4eee80b0cb36d9bdc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1717914
Reviewed-by: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Ken Rockot <rockot@google.com>
Cr-Commit-Position: refs/heads/master@{#681034}
There isn't any browser-specific implementation of SmsService and
it isn't part of the contract of what embeders need to provide, so
there is no reason for it to be in content/public.
Originally, an interface SmsService was created because something
needed to manage an incoming queue of SMS messages which are global
per device. To accomplish that, a SmsKeyedService was created to
hang instances on Profiles, which are in chrome/.
We were anticipating the needed for a chrome/ specific element to
exist in preparation for an integration with Sync to support
Desktop, so SmsKeyedService made sense.
Upon further investigation, we find that this architecture abuses the
contract of content/public artificially and leads to a complicated
relationship between the content-browser separation.
To avoid premature generalization and clarify the architecture,
this CL removes SmsService from the content/public interface, removes
SmsKeyedService and hangs instances of SmsService directly into
BrowserMainLoop.
We'll revisit how to factor Desktop in once we take a few more steps,
bringing a bit more clarity as we go along.
Change-Id: I4a73af1d148ce12d1050d02c91a94a499bdbbf2e
Bug: 984083
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700645
Commit-Queue: Sam Goto <goto@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/master@{#677527}
ServiceManagerConnection is slated for imminent deletion. This
replaces most usage around //content/browser with the simpler
GetSystemConnector(). Split out from a much larger CL.
Bug: 904240
Change-Id: Ia88322f607cb6fbf3c5fdf3fd4b6762c8074c0c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1666778
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: Becca Hughes <beccahughes@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#671047}
Aiming to be both general enough to support whatever lifetime and
scope for permission grants as we could want, while not being more
complicated than necessary. Follow up CLs will implement an actual
permission model on top of this in //chrome, as well as the UI that
goes with that.
Bug: 878585
Change-Id: I372b07c33f2b945c6b4f70cf85dc6ed046201f2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1663453
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#670732}
InMemoryDB is usually reserved for Guest and Incognito accounts. But
recent experiments by liberato@ hinted (noisy stats, other factors may
be responsible) that forgetting all your data at the boundary of each
browsing session might be good for prediction quality. Lets see :)
Bug: 968331
Change-Id: I6803a206266bf7ff6c39d4f6b4c12534c391900d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1636475
Reviewed-by: Frank Liberato <liberato@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Auto-Submit: Chrome Cunningham <chcunningham@chromium.org>
Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
Cr-Commit-Position: refs/heads/master@{#664868}
We need to move this out of //content and into Blink in order to have
these definitions available to be used from Blink itself, which is
where the communication with //content/browser will happen from once
the whole PushMessaging feature has been Onion Soup'ed.
Bug: 939943
Change-Id: Iae5a41122f82a77b9456ea2a23052313eb112b3d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1591930
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Mario Sanchez Prada <mario@igalia.com>
Cr-Commit-Position: refs/heads/master@{#657166}
This change restores the behavior of clearing BrowserContext information
in ChildProcessSecurityPolicyImpl::Remove() instead of in response to
BrowserContext::NotifyWillBeDestroyed(). This is to fix "crashes" in
BlobURLStore::Revoke() that appear to observe the null context in the
brief period between BrowserContext::NotifyWillBeDestroyed() &
ChildProcessSecurityPolicyImpl::Remove() being called.
Note: This is not identical to the original changes because
|pending_remove_state_| was deleted after this change was landed.
Bug: 948069
Change-Id: I6a5a39529212626138a771fe1cfc75f73e5e240b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1548053
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Aaron Colwell <acolwell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646537}
As part of fixing bug 943887 we need to be able to have SecurityState
live beyond the Remove() call. This change defers clearing the
BrowserContext & ResourceContext in the SecurityState to the moment
when the BrowserContext itself is shutting down. This will make
extending the lifetime of the SecurityState object much easier in
a followup CL.
Bug: 943887
Change-Id: Ia32c938a5a0290edb1d908a797d492a966344c2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1542475
Auto-Submit: Aaron Colwell <acolwell@chromium.org>
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#645542}
Previously, isolated origins would apply globally for all profiles in
the entire browser. This CL introduces support for associating
isolated origins with specific BrowserContexts (i.e., profiles):
1. The API for adding new isolated origins,
ChildProcessSecurityPolicyImpl::AddIsolatedOrigins(), can now take
a BrowserContext in which the origin should apply.
2. Entries in the map of isolated origins are extended to optionally
contain the BrowserContext to which they apply. If this is not
specified, the corresponding isolated origin still applies globally
to all profiles. To facilitate checks on the IO thread, the
ResourceContext (BrowserContext's representation on the IO thread)
is also stored in the entry.
3. IsolationContext now also carries profile information (as
BrowserOrResourceContext), and GetMatchingIsolatedOrigin() consults
it to see if the profiles match when looking for matching isolated
origins. Various tests are updated to pass a proper BrowserContext
to the IsolationContexts they construct.
Bug: 905513
Change-Id: Iad1fd2ca4ea701f9e088d30fa1b8582de9fbed67
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1497794
Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#638360}
This CL adds BrowserFeatureProvider, as a place where we can start
adding common features to the learning framework. It currently
supports a single feature for the network connection type (wired,
3G, etc.), as an example. Future CLs will add more.
This CL also updates the MediaCapabilities learning experiment to
include a task that uses the new feature.
Change-Id: I25ecb50c88d6b26b53fe01bbc089d235a8e2ccb4
Reviewed-on: https://chromium-review.googlesource.com/c/1437710
Commit-Queue: Frank Liberato <liberato@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#630883}
SharedCorsOriginAccessList was implemented in BrowserContext, and
OffTheRecordProfile didn't share the original profile's access lists
but had own lists. This is not correct, and having a proxy to access
the original lists with read-only permission is what the incognito
mode actually needs.
Also this patch redesigns how we implement the access lists.
Now BrowserContext provides virtual methods to implement the feature
in sub-classes in sub-class specific ways.
IncognitoProfileMainNetworkContext/NetworkContextConfigurationBrowserTest.
ThirdPartyCookiesAllowedForExtensions/{0,1,2} started failing with
--enable-features=OutOfBlinkCors after recent test side changes,
but now they also pass.
Bug: 914968
Change-Id: I39fb604e96ed14cea0b6ff33c4d0be629647e4d1
Reviewed-on: https://chromium-review.googlesource.com/c/1379793
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624527}
