| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/87072
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14243 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SafeBrowsing check has completed. The problem occurs since the
SafeBrowsingResourceHandler is not deleted when its associated
URLRequest is cleaned up *and* a SafeBrowsing check is in progress.
When the check completes, the next resource handler in the chain
(the AsyncResourceHandler which caches a pointer the now deleted
ResourceMessageFilter) will crash.
This CL adds a notification for objects to know when the
ResourceMessageFilter is destroyed.
BUG=8544 (http://crbug.com)
Review URL: http://codereview.chromium.org/63036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13644 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
without domain.
Review URL: http://codereview.chromium.org/63147
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13451 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
reuse processes.
Also add a test mode --webworker-process-per-core to create a worker process per worker until we hit the number of cores, then reuse.
Review URL: http://codereview.chromium.org/61001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13279 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
This reverts commit r13062 which, unsurprisingly, broke the build.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13063 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
(No review URL: Rietvelt couldn't cope)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13062 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
shutdown, to avoid races in which the browser process thinks the process is fine to use while it's shutting down. I also removed PluginProcess/WorkerProcess since they didn't have any code in them now.
I removed the plugin process code which waits 10 seconds before shutting itself down. That was a premature optimization, since testing with/without this didn't show any difference (see http://www/~jabdelmalek/chrome/test/plugins/processes.html). In both cases, the plugin on a page would get recreated in less than 100ms, even with reusing or starting a plugin process from scratch. We already spawn new renderer processes on back and forth if it's a different origin, and the plugin will be in the cache anyways.
Review URL: http://codereview.chromium.org/53091
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12703 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
the title in the task manager, and show an infobar when a page's workers die.
I also cleaned up the code in RenderView which creates a window and widget, since when I originally wrote it I wasn't aware of RenderViewHost::FromID.
Review URL: http://codereview.chromium.org/45025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12335 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/42311
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12038 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/48098
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11928 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
The usage of RDH is now like RD, the client sends the message to RDH to see if it should handle it. I added methods to the Receiver interface so that RDH can get to the process id/handle/type when starting requests.
Review URL: http://codereview.chromium.org/42202
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11816 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
to ~400.
Review URL: http://codereview.chromium.org/46039
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11651 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/42155
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11593 0039d316-1c4b-4281-b951-d872f2087c98
|
|
WebWorkerClient/WebWorker are parallel interfaces of WebCore::{WorkerObjectProxy, WorkerContextProxy} that use Chrome data types. When WebKit requests a WorkerObjectProxy, we create an instance of WebWorkerClientImpl. This class creates an object that implements a Chromium version of WorkerObjectProxy (i.e. with Chrome data types) through WebViewDelegate. That object is a WebWorkerProxy and talks over IPC to a WebWorker object in the worker process. The WebWorker object creates the actual WebCore::Worker object using another class in glue: WebWorkerImpl.
When the WebCore::Worker object running in the worker process wants to talk back to the code running in the renderer, it talks to WebWorkerImpl which implements WebCore::WorkerObjectProxy. WebWorkerImpl converts the data types to Chrome compatible ones, and then calls the WebWorkerClient version which does IPC to get to the renderer process. This ends up at WebWorkerProxy, which calls WebWorkerClientImpl (the original class).
In future changes, sandboxing, multiple worker processes etc will be added. Note that I also had to make two small changes to WebKit, since WorkerMessagingProxy couldn't be created as is for the nested worker case. I'll either check it in myself or work with Jian to do so.
Review URL: http://codereview.chromium.org/27157
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10847 0039d316-1c4b-4281-b951-d872f2087c98
|