| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
excluding the broken ones.
The change of GURL -> const GURL& caused some nasty crash and the change got reverted.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/164095
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22682 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused an easily reproducible crash:
1. Start with a fresh profile
2. Navigate to google.com
3. Restart
4. Navigate to google.com
5. crash
The change from pass-by-value to pass-by-ref in
fav_icon_helper.* seems to be to blame, but I can't see it
right off.
TBR=phajdan.jr@chromium.org
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22595 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/159862
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22559 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
worker tests failures.
Review URL: http://codereview.chromium.org/159276
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21412 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
crashes on reliability. It also seems to be causing
valgrind error.
Original change:
Switch the first thread in a child process to be the main thread, and make theIO thread be the second thread. The change is needed for plugins on mac.
Review URL: http://codereview.chromium.org/159274
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21398 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
theIO thread be the second thread. The change is needed for plugins on mac.
Review URL: http://codereview.chromium.org/155944
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21355 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the ipc code from the common project. The 'common' project pulls in
all of webkit, the v8 bindings, skia, googleurl, and a number of other projects
which makes it very difficult to deal with especially for external projects
wanting just to use some of Chromium's infrastructure. This puts the ipc code
into its top-level ipc/ directory with a dependency only on base. The common
project depends on the new ipc/ipc.gyp:ipc target so that all projects currently
pulling common in to get the IPC code still have it available. This mostly
follows agl's pre-gyp attempt to do this which was r13062.
Known issues:
- Currently a number of projects depend on chrome/chrome.gyp:common in order to
use the IPC infrastructure. Rather than fixing all of these dependencies I have
made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules
section of DEPS so that checkdeps.py doesn't complain. Over time projects that
need IPC should depend on the IPC project themselves and dependencies on common
removed, although I don't think many projects that need IPC will be able to get
away without common currently.
- ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a
ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve
this since it's really an IDE bug
- the named pipe name (windows+linux) and the logging event name (all) + env
variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion
of ipc/ being an independent library. I think this should be examined in a
subsequent, much smaller patch.
- I've eliminated the IPC.SendMsgCount counter since it was implemented in a way
to create a dependency from ipc/ to chrome/common/chrome_counters. This is the
same approach that r13062 took.
http://codereview.chromium.org/155905
(Patch from James Robinson)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
Also included in this revert: r21165, r21180, and a couple valgrind suppression edits
TBR=huanr
Review URL: http://codereview.chromium.org/155876
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21216 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
argh, this used to work in my previous change but it must have regressed before checkin.
Review URL: http://codereview.chromium.org/155846
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21180 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
the IO thread be the second thread. The change is needed for plugins on mac.
Review URL: http://codereview.chromium.org/149558
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21117 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
proxy the loading requests through.
BUG=4361
TEST=none
Review URL: http://codereview.chromium.org/126070
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18465 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
They're ASCII anyway.
TEST=covered by existing tests
Review URL: http://codereview.chromium.org/119131
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17682 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
- reduce header dependencies
- miscellanous cleanups (whitespace, explicit deps)
Review URL: http://codereview.chromium.org/113945
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17177 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
|
|
|
|
|
|
|
|
| |
ChildThread so that the same code is used by the plugin process (and soon, workers).
Review URL: http://codereview.chromium.org/42108
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11581 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
doesn't work when there are Send calls to plugins (i.e. Gears). So instead, just use PostNonNestableTask to delete RenderWidget. I
(Note I still don't know how my change affected this, it seems to have been broken before as well.)
BUG=7951
Review URL: http://codereview.chromium.org/28090
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10298 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things.
Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses.
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=10080
Review URL: http://codereview.chromium.org/21502
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10144 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10082 0039d316-1c4b-4281-b951-d872f2087c98
|
|
ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things.
Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses.
Review URL: http://codereview.chromium.org/21502
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10080 0039d316-1c4b-4281-b951-d872f2087c98
|