Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CEF3: Introduce BrowsingInstance and SiteInstance concepts #1044

Open
GoogleCodeExporter opened this issue Jun 29, 2015 · 8 comments
Open

CEF3: Introduce BrowsingInstance and SiteInstance concepts #1044

GoogleCodeExporter opened this issue Jun 29, 2015 · 8 comments

Comments

@GoogleCodeExporter
Copy link

Chromium's site isolation model introduces the concepts of BrowsingInstance and 
SiteInstance.

BrowsingInstance: Corresponds to the notion of a "unit of related browsing 
contexts" in the HTML5 spec. It includes all browser objects that might be able 
to script each other because of how they were created (e.g., window.open or 
targeted links).

SiteInstance: Represents the documents within each BrowsingInstance that are 
from the same site and thus can have script access to each other. Here, a 
"site" is similar to the page's origin, but it only includes the registered 
domain name and scheme, not the port or subdomains. This accounts for the fact 
that changes to document.domain allow similar origin pages with different ports 
or subdomains to script each other. Different SiteInstances can safely run in 
different renderer processes because their documents cannot access each other's 
contents (due to the same origin policy).

Cookies, cache, HTML5 storage, etc. are associated with a SiteInstance. An 
arbitrary SiteInstance can be associated with a new WebContents when the 
WebContents is created via WebContents::Create (for example, as a result 
calling CefBrowserHost::CreateBrowser). Currently, all frames, iframes and 
browser objects created using window.open or targeted links will share the same 
SiteInstance or BrowsingInstance. With out-of-process (oop) iframes it will 
become possible for an iframe to have a different SiteInstance than the parent 
frame.

The likely implementation for CEF is:

1. Introduce a new CefSiteInstance class that has capabilities similar to 
Chromium's SiteInstance class (content/public/browser/site_instance.h).
A. The CefSiteInstance static constructor method will accept a CefSiteHandler 
argument.
B. Most network-related callbacks will move from CefRequestHandler to 
CefSiteHandler.
2. Pass a CefSiteInstance into the CefBrowserHost::CreateBrowser static methods.
3. Add the ability to retrieve the CefSiteInstance associated with a 
CefBrowserHost.

Additional refactoring will be required once oop-iframes are supported.

Related reading:
http://www.chromium.org/developers/design-documents/process-models
http://www.chromium.org/developers/design-documents/site-isolation
http://www.chromium.org/developers/design-documents/oop-iframes
http://www.chromium.org/developers/design-documents/isolated-sites

Original issue reported on code.google.com by magreenb...@gmail.com on 3 Aug 2013 at 3:01

@GoogleCodeExporter
Copy link
Author

Issue 1043 has been merged into this issue.

Original comment by magreenb...@gmail.com on 3 Aug 2013 at 3:04

@GoogleCodeExporter
Copy link
Author

Exposing SiteInstance functionality might not be the best approach. The 
underlying object utilized by BrowsingInstance and SiteInstance to control 
access and storage is BrowserContext. BrowserContext exposes the following 
functionality:

- Cache path location.
- URL request context (network-related callbacks, cookie store, etc).
- Resource context (microphone and camera access).
- Download manager.
- Geolocation permissions.
- Storage permissions.

A BrowserContext instance is passed into WebContents::Create. When a new 
WebContents is created in WebContentsImpl::CreateNewWindow (due to window.open 
or targeted links) the new WebContents will be assigned the same BrowserContext 
as the source WebContents. Therefore, by default, all associated WebContents 
will share the same BrowserContext irrespective of render process or scripting 
relationships.

The BrowserContext object is only accessed on the UI thread. It exposes 
URLRequestContext and ResourceContext objects which are accessed on the IO 
thread. Most IO thread callbacks are associated with either one of these 
objects (URLRequestContext or ResourceContext) or with a 
render_process_id/render_view_id pair. It will therefore be necessary to map 
these objects or ID pairs the correct CefBrowserContext object.

The implementation would then be as follows:

1. Introduce a new CefBrowserContext class.
A. The CefBrowserContext static constructor method will accept a handler 
argument (CefBrowserContextHandler?).
B. The CefRequestHandler, CefDownloadHandler and CefGeolocationHandler 
accessors moves from CefClient to the new handler.
C. Cache path specification becomes dynamic and moves from CefSettings to the 
CefBrowserContext class.
2. Pass a CefBrowserContext into the CefBrowserHost::CreateBrowser static 
methods.
3. By default all associated browsers will share the same CefBrowserContext.
4. To assign a different CefBrowserContext cancel the associated browser 
creation in CefLifeSpanHandler::OnBeforePopup and create the new browser using 
CefBrowserHost::CreateBrowser instead.

Original comment by magreenb...@gmail.com on 27 Aug 2013 at 11:27

@GoogleCodeExporter
Copy link
Author

Trunk revision 1424 introduces structural improvements for request handling.
- Add new CefRequestContext and CefRequestContextHandler classes.
- Add CefRequestContext argument to CefBrowserHost static factory methods.
- Move GetCookieManager from CefRequestHandler to CefRequestContextHandler.
- Use BrowserContext as the root proxy object for network requests.
- Move accessors for CefBrowserMainParts members from CefContext to 
CefContentBrowserClient.

Original comment by magreenb...@gmail.com on 3 Sep 2013 at 4:45

@GoogleCodeExporter
Copy link
Author

Great job! So it looks like separate cookie managers are already working.

Original comment by czarek.t...@gmail.com on 3 Sep 2013 at 7:26

@GoogleCodeExporter
Copy link
Author

@comment#4: Yes, but in multi-process mode only. See related comments on the 
CefRequestContext class.

Original comment by magreenb...@gmail.com on 3 Sep 2013 at 7:30

@GoogleCodeExporter
Copy link
Author

Trunk revision 2032 fixes issues related to request and context object lifespan.
- Simplify and document the relationship between the various context object 
types. See browser_context.h for a description of the new relationships.
- cefclient: Add `request-context-per-browser` command-line flag for testing 
multiple CefRequestContext instances.
- cefclient: Add a CefURLRequest example.

Original comment by magreenb...@gmail.com on 13 Feb 2015 at 11:18

@GoogleCodeExporter
Copy link
Author

Trunk revision 2040 adds support for complete isolation of storage and 
permissions (cache, cookies, localStorage, access grants, etc) on a 
per-request-context basis:
- CefRequestContext instances can be configured using a new 
CefRequestContextSettings structure passed to CefRequestContext::CreateContext.
- Scheme registration is now per-request-context using new 
CefRequestContext::RegisterSchemeHandlerFactory and ClearSchemeHandlerFactories 
methods.
- Cookie managers are now per-request-context by default and can be retrieved 
using a new CefRequestContext::GetDefaultCookieManager method.
- CefURLRequest::Create now accepts an optional CefRequestContext argument for 
associating a URL request with a context (browser process only).
- The CefRequestContextHandler associated with a CefRequestContext will not be 
released until all objects related to that context have been destroyed.
- When the cache path is empty an in-memory cache ("incognito mode") will be 
used for storage and no data will be persisted to disk.
- Add CefSettings.user_data_path which specifies the location where user data 
such as spell checking dictionary files will be stored on disk.
- Add asynchronous callbacks for all CefCookieManager methods.
- Add PK_LOCAL_APP_DATA and PK_USER_DATA path keys for retrieving user 
directories via CefGetPath.
- cefclient: Add "New Window" test that creates a new window unrelated to 
existing windows. When used in combination with `--request-context-per-browser` 
the new window will be given a new and isolated request context.

Original comment by magreenb...@gmail.com on 2 Mar 2015 at 8:26

@GoogleCodeExporter
Copy link
Author

CEF is transitioning from Google Code to Bitbucket project hosting. If you 
would like to continue receiving notifications on this issue please add 
yourself as a Watcher at the new location: 
https://bitbucket.org/chromiumembedded/cef/issue/1044

Original comment by magreenb...@gmail.com on 14 Mar 2015 at 3:26

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant