summaryrefslogtreecommitdiffstats
path: root/chrome/common/appcache
Commit message (Collapse)AuthorAgeFilesLines
* Move initialization of ChromeURLRequestContexts to the IO thread.eroman@chromium.org2009-10-233-39/+28
| | | | | | | | | | | | | | | | | | | | | | | Before, these URLRequestContexts were lazily created from the UI thread. Unfortunately that model made it easy for consumers on the UI thread to poke at stuff which was being used from the IO thread, and introduce races. So instead of providing a URLRequestContext*, the Profile now vends a URLRequestContextGetter*. The consequence of this is: * Consumers on the UI thread can no longer get access to a URLRequestContext. * Consumers on the IO thread need to call URLRequestContextGetter::GetURLRequestContext() to get at the context. This uses the same style lazy-creation of URLRequestContexts, albeit from the IO thread. OK, so now the smelly part: There were a couple of consumers of URLRequestContext on the UI thread that can't easily be moved to the IO thread -- these are the consumers of the cookie store. Before they could happily mess with the cookie store from the UI thread, and this was fine since CookieStore is threadsafe. However under the new model, they have no way to get at the URLRequestContext from the UI thread, hence can't get a pointer to the cookie store. To support that use-cases, I bastardized the API some by adding a URLRequestContextGetter::GetCookieStore() method that lets UI thread consumers get a pointer to the cookie store, since we know this particular cross-thread usage is safe. BUG=http://crbug.com/22294 Review URL: http://codereview.chromium.org/258008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29880 0039d316-1c4b-4281-b951-d872f2087c98
* AppCache: Kill bad renderers when we receive bad IPC messages.michaeln@google.com2009-10-132-37/+100
| | | | | | | | | TEST=none BUG=none Review URL: http://codereview.chromium.org/273012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28849 0039d316-1c4b-4281-b951-d872f2087c98
* Fix appcache_service and request_context referencing.michaeln@google.com2009-09-221-8/+10
| | | | | | | | | | | | There is one appcache service per profile and several request context per profile. The profile holds a reference to the appcache service. Those request contexts which are subject to retrieval from appcaches hold a reference to the appcache service too. The appcache service is provided with a pointer back to the 'main' request context, this context is used when updating appcaches. Initialization is a little tricky because profiles can't be used on the IO thread and request contexts can't be used on the UI thread. BUG=22597,22125 TEST=many existing tests exercise profile/context creation Review URL: http://codereview.chromium.org/215024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26844 0039d316-1c4b-4281-b951-d872f2087c98
* * Fleshed out AppCacheHost class a fair amount, in particular the cache ↵michaeln@google.com2009-09-151-0/+3
| | | | | | | | | | | | | | | | selection algorithm. * Added some AppCacheHost unit tests. * Introduced AppCacheRequestHandler class, which replaces the clunkyApp CacheInterceptor::ExtraInfo struct. This impl is entirely skeletal stubs for now. TEST=appcache_unittest.cc, but really needs more BUG=none Review URL: http://codereview.chromium.org/192043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26275 0039d316-1c4b-4281-b951-d872f2087c98
* 1) Tell the AppCacheService which request context to use when fetching ↵michaeln@google.com2009-09-151-0/+2
| | | | | | | | | | | | | resources for updates. Done for both chrome and test_shell. The service does not yet take a reference to that context, because the extra reference apparently gives some tests grief. 2) Added methods to generate new storage ids for different object types on the IO thread. BUG=none TEST=none Review URL: http://codereview.chromium.org/195077 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26253 0039d316-1c4b-4281-b951-d872f2087c98
* Plumb request interception into the appcache library for both chrome and ↵michaeln@google.com2009-09-015-26/+154
| | | | | | | | | | | | | | | | | | | | | | | | test_shell. AppCache library: * Added AppCacheInterceptor, which is derived from URLRequest::Interceptor. Chrome: * Each UserProfile instantiates a ChromeAppCacheService, which is derived from an appcache library class. * Each ChromeURLRequestContext associated with that profile has a reference to that instance. * ResourceDispatcherHost pokes AppCacheInterceptor when initiating URLRequests and when returning the response head. TestShell: * Added SimpleAppCacheSystem which bundles together appcache lib components for use in a single process with an UI and IO thread. * TestShellWebKit instantiates and initializes an instance of the above, aimed at at temp directory that will get cleaned up when the test run is over. * SimpleResourceLoaderBridge pokes the system when initiating URLRequests and when returning the response head. TEST=none, although many existing tests exercise this stuff BUG=none Review URL: http://codereview.chromium.org/173406 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25099 0039d316-1c4b-4281-b951-d872f2087c98
* Retrofit the pre-existing appache message dispatching with the new WebKit ↵michaeln@google.com2009-08-218-0/+339
APIs and concrete classes defined in our new appcache library, and get rid of the old files. There are many files in the CL, mostly to pickup constant values now defined in our new appcache library, and to reflect a terminilogy change (from 'context' to 'host'). TEST=some existing unit tests apply BUG=none Review URL: http://codereview.chromium.org/170003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24022 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-11 03:55:37 +0000