| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
BUG=17129
Review URL: http://codereview.chromium.org/155946
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21323 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
Add a unittest that pretends to be the UtilityProcessHost and launches a chrome utility process for unpacking a theme.
Review URL: http://codereview.chromium.org/147001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19181 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
and stores it in user prefs, where it can be used by the new tab page.
BUG = http://crbug.com/13363
Review URL: http://codereview.chromium.org/125052
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18766 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trying to send decoded images over IPC didn't work too well. Instead, we'll
write them to a file and have the browser slurp them in from there. My first
instinct was to use SharedMemory, but that would require us to impose a limit
on the size of the decoded image data.
Also made sure that the undecoded images are deleted when we install.
BUG=13455
TEST=Try the repro steps in bug 13455 several times and make sure it works
every time.
Review URL: http://codereview.chromium.org/119255
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17797 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
| |
that the extension unpacker process parsed.
BUG=11680
Review URL: http://codereview.chromium.org/115595
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16768 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
of extension packages.
This is a first pass. In the second pass, I will add support for transcoding
the manifest and any images in the browser process.
BUG=11680
Review URL: http://codereview.chromium.org/114027
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16198 0039d316-1c4b-4281-b951-d872f2087c98
|
