summaryrefslogtreecommitdiffstats
path: root/ipc/ipc_message_utils.h
Commit message (Collapse)AuthorAgeFilesLines
* ipc: delete wchar_t IPC traitevan@chromium.org2010-08-261-24/+0
| | | | | | | | | | We don't send wchars over IPC, so I'm not sure where this came from. TEST=still compiles Review URL: http://codereview.chromium.org/3106034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57433 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Move individual XXXMsg_Params structs to a new file.erg@google.com2010-08-241-8/+1
| | | | | | | | | | | | | | | | The new file, render_messages_params.h, is included in 57 files, while render_messages.h is included in 176 files. Moving the Params structs to their own file allow pruning the included headers. (Part 2 of this cleanup will be sorting the individual structs into themes to further minimize header inclusion.) BUG=51411 TEST=compiles Review URL: http://codereview.chromium.org/3119035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57229 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for the new IPC system on gcc 4.5 and greater.erg@google.com2010-08-191-0/+8
| | | | | | | | | | | | | | We need the new noclone attribute since gcc tries to specialize many of the ::Read() members for the subtypes since they're only invoked from Log(). Reported by some dude named flo on IRC. BUG=none TEST=none Review URL: http://codereview.chromium.org/3133025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56734 0039d316-1c4b-4281-b951-d872f2087c98
* Remove all wstrings from the IPC logging subsystem.erg@google.com2010-08-181-98/+80
| | | | | | | | | | | | | | | | Changes all IPC Log methods from wstring to string. All static logging debug data changed from wchar[] to char[]. Various string conversion/numeric headers no longer need to be included in ipc_message_utils.h and have been removed (and added in all implementation files that require them). BUG=none TEST=none Review URL: http://codereview.chromium.org/3159013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56563 0039d316-1c4b-4281-b951-d872f2087c98
* Reapplies all the IPC system work (reverts the revert r56272).erg@google.com2010-08-171-181/+110
| | | | | | | | | | | That patch wasn't what caused the regression in the page cycler. BUG=51411,52103 TEST=still compiles Review URL: http://codereview.chromium.org/3106018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56390 0039d316-1c4b-4281-b951-d872f2087c98
* Completely revert all my IPC work to see if this was what regressed the page ↵erg@google.com2010-08-171-110/+181
| | | | | | | | | | | cycler. BUG=51411,52103 TEST=page cycler Review URL: http://codereview.chromium.org/3170020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56272 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Mark the Read methods in the IPC subsystem as noinline.erg@google.com2010-08-131-24/+20
| | | | | | | | | | | | | | | | This forces all the ReadParam template junk to expand once in the *_messages.cc file, instead of at every Read() call site. Without the compiler-specific annotation, this builds and links in debug mode, but doesn't link in release mode because the individual Read() methods generated were inlined into the subclass Log() methods, causing disaster on the release builders, but not on the trybots or locally. BUG=51411 TEST=none Review URL: http://codereview.chromium.org/3160008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56081 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove all the easy headers from *_messages.h.erg@google.com2010-08-121-91/+17
| | | | | | | | | BUG=51411 TEST=compiles Review URL: http://codereview.chromium.org/3174002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55902 0039d316-1c4b-4281-b951-d872f2087c98
* Reapplies r55735, fixing some message code that was checked in that I ↵erg@google.com2010-08-111-54/+63
| | | | | | | | | | | | collided with. BUG=51411 TEST=none TBR=mpcomplete Review URL: http://codereview.chromium.org/3118009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55749 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "FBTF: Allow forward declaration of classes passed to sync IPC messages."erg@google.com2010-08-111-63/+54
| | | | | | | | | | | | This reverts commit r55735. BUG=none TEST=none TBR=mirandac Review URL: http://codereview.chromium.org/3152007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55738 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Allow forward declaration of classes passed to sync IPC messages.erg@google.com2010-08-111-54/+63
| | | | | | | | | | | | | This is a continuation of r55259, where we convert the remaining IPC messages to the new system. At this point, all the messages should be able to accept forward declared classes/structs as parameters. BUG=51411 TEST=none Review URL: http://codereview.chromium.org/3018045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55735 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Reapplies r55259, the first new IPC definition patch.erg@google.com2010-08-101-28/+26
| | | | | | | | | | | | | This moves MessageWithTuple::Read() back into the main ipc_message_utils.h header from the private ipc_messsage_utils_impl.h header. In release mode, this was causing link failures. BUG=51411 TEST=none Review URL: http://codereview.chromium.org/3069034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55587 0039d316-1c4b-4281-b951-d872f2087c98
* 1. ipc_video_decoder.cc/h is media pipeline filter which use the gpu decoder ↵jiesun@google.com2010-08-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | facilities in video stack. it is only enabled when (a) hardware composition is on (b) hardware decoding command line is on (c) h264 codec is specified. 2. gpu_video_service.cc/h is a singleton in gpu process which provide video services for renderer process, through it we could create decoder. ( in my imagination, in the future, we could create encoder or capturer too) 3. gpu_video_decoder.cc/h. abstract interface for hardware decoder. 4. gpu_video_service_host.cc/h is singleton in renderer process which provide proxy for gpu_video_service. 5. gpu_video_decoder_host.cc/h is proxy for gpu_video_decoder. (1 to 1 map).basically there is one global GpuVideoService in GPU process, one GpuVideoServiceHost in Renderer process. for each renderer process, there are could be multiple renderer view, each could had multiple GpuVideoDecoderHost the connect to GpuVideoDeocder through GPUCHannelHOst/GpuChannel. 6. gpu_video_common.cc/h: IPC message definition and pickle/marshaling support. ISSUES: 1. in media pipeline, we need let decoder to determine if bit stream filter should be used instead of let command line to determine it. 2. stop readback from D3D surface use ANGLE. 3. Flush logic still need fine tuning. 4. CreateThread in GpuVideoDecoder, and post message in message handler, and derived classs handle message loop. ? 5. Error handling. 6. Input ring buffer implementation. Current impl is naive. 7.Add output queue for MFT decoder. 8. Query Capabilities at GetVideoServices()... BUG=None TEST=Windows7 Review URL: http://codereview.chromium.org/2873089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55516 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 55405 - Special thanks for in-ming cheng's MFT hardware decodering code.ananta@chromium.org2010-08-091-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. ipc_video_decoder.cc/h is media pipeline filter which use the gpu decoder facilities in video stack. it is only enabled when (a) hardware composition is on (b) hardware decoding command line is on (c) h264 codec is specified. 2. gpu_video_service.cc/h is a singleton in gpu process which provide video services for renderer process, through it we could create decoder. ( in my imagination, in the future, we could create encoder or capturer too) 3. gpu_video_decoder.cc/h. abstract interface for hardware decoder. 4. gpu_video_decoder_mft.cc/h media foundation transform hardware decoder which run on windows 7 only. 5. gpu_video_service_host.cc/h is singleton in renderer process which provide proxy for gpu_video_service. 6. gpu_video_decoder_host.cc/h is proxy for gpu_video_decoder. (1 to 1 map).basically there is one global GpuVideoService in GPU process, one GpuVideoServiceHost in Renderer process. for each renderer process, there are could be multiple renderer view, each could had multiple GpuVideoDecoderHost the connect to GpuVideoDeocder through GPUCHannelHOst/GpuChannel. 7. gpu_video_common.cc/h: IPC message definition and pickle/marshaling support. ISSUES: 1. in media pipeline, we need let decoder to determine if bit stream filter should be used instead of let command line to determine it. 2. stop readback from D3D surface use ANGLE. 3. Flush logic still need fine tuning. 4. CreateThread in GpuVideoDecoder, and post message in message handler, and derived classs handle message loop. ? 5. Error handling. 6. Input ring buffer implementation. Current impl is naive. 7.Add output queue for MFT decoder. 8. Query Capabilities at GetVideoServices()... BUG=None TEST=Windows7 Review URL: http://codereview.chromium.org/2873089 TBR=jiesun@google.com Review URL: http://codereview.chromium.org/3020077 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55419 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 55259 - FBTF: New IPC definitions, only applied to async ROUTED and ↵pinkerton@google.com2010-08-091-24/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONTROL messages. The slowest cc files in chrome include render_messages.h and other IPC message definitions. Including one of these files will bring in half of chrome because in the IPC system previously required full class definitions due to implementation details. The new system allows forward declarations and places the implementations of functions that need the full class definitions (ctor/dtor()/Log() and superclass ctor/Read() methods) into a separate xxx_messages.cc file using a parallel set of macros to ipc_message_macros.h. This has the added benefit of moving most of the template instantiation junk into a small number of files. Pros: - Will speed up compiling by a lot once everything is forward declared. - Already, intermediary .o/.a files are smaller. Cons: - Adds a 4th pass to the messages system, this time in a different header. BUG=51411 TEST=none Review URL: http://codereview.chromium.org/2873090 TBR=erg@google.com Review URL: http://codereview.chromium.org/3080040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55406 0039d316-1c4b-4281-b951-d872f2087c98
* Special thanks for in-ming cheng's MFT hardware decodering code.jiesun@google.com2010-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. ipc_video_decoder.cc/h is media pipeline filter which use the gpu decoder facilities in video stack. it is only enabled when (a) hardware composition is on (b) hardware decoding command line is on (c) h264 codec is specified. 2. gpu_video_service.cc/h is a singleton in gpu process which provide video services for renderer process, through it we could create decoder. ( in my imagination, in the future, we could create encoder or capturer too) 3. gpu_video_decoder.cc/h. abstract interface for hardware decoder. 4. gpu_video_decoder_mft.cc/h media foundation transform hardware decoder which run on windows 7 only. 5. gpu_video_service_host.cc/h is singleton in renderer process which provide proxy for gpu_video_service. 6. gpu_video_decoder_host.cc/h is proxy for gpu_video_decoder. (1 to 1 map).basically there is one global GpuVideoService in GPU process, one GpuVideoServiceHost in Renderer process. for each renderer process, there are could be multiple renderer view, each could had multiple GpuVideoDecoderHost the connect to GpuVideoDeocder through GPUCHannelHOst/GpuChannel. 7. gpu_video_common.cc/h: IPC message definition and pickle/marshaling support. ISSUES: 1. in media pipeline, we need let decoder to determine if bit stream filter should be used instead of let command line to determine it. 2. stop readback from D3D surface use ANGLE. 3. Flush logic still need fine tuning. 4. CreateThread in GpuVideoDecoder, and post message in message handler, and derived classs handle message loop. ? 5. Error handling. 6. Input ring buffer implementation. Current impl is naive. 7.Add output queue for MFT decoder. 8. Query Capabilities at GetVideoServices()... BUG=None TEST=Windows7 Review URL: http://codereview.chromium.org/2873089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55405 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: New IPC definitions, only applied to async ROUTED and CONTROL messages.erg@google.com2010-08-061-36/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The slowest cc files in chrome include render_messages.h and other IPC message definitions. Including one of these files will bring in half of chrome because in the IPC system previously required full class definitions due to implementation details. The new system allows forward declarations and places the implementations of functions that need the full class definitions (ctor/dtor()/Log() and superclass ctor/Read() methods) into a separate xxx_messages.cc file using a parallel set of macros to ipc_message_macros.h. This has the added benefit of moving most of the template instantiation junk into a small number of files. Pros: - Will speed up compiling by a lot once everything is forward declared. - Already, intermediary .o/.a files are smaller. Cons: - Adds a 4th pass to the messages system, this time in a different header. BUG=51411 TEST=none Review URL: http://codereview.chromium.org/2873090 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55259 0039d316-1c4b-4281-b951-d872f2087c98
* Add #include utf_string_conversions.h to all files that use ASCIIToWide andbrettw@chromium.org2010-08-031-1/+1
| | | | | | | | | | | | | | | ASCIIToUTF16. I removed string_util includes from a few places where it obviously wasn't needed. In a separate pass, I'm going to remove ASCIITo* from string_util, then I'm going to do an even later pass to find the unnecessary string_util.h includes and remove them. TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/3058027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54746 0039d316-1c4b-4281-b951-d872f2087c98
* Added an IPC server in the service process to listen to commands. This is ↵sanjeevr@chromium.org2010-07-311-0/+2
| | | | | | | | | | | not used yet. BUG=None TEST=None for now since this code is not enabled. Review URL: http://codereview.chromium.org/3041036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54440 0039d316-1c4b-4281-b951-d872f2087c98
* Move the number conversions from string_util to a new file.brettw@chromium.org2010-07-301-2/+3
| | | | | | | | | | | | | Use the base namespace in the new file. Update callers. I removed all wstring variants and also the string->number ones that ignore the return value. That encourages people to write code and forget about error handling. TEST=included unit tests BUG=none Review URL: http://codereview.chromium.org/3056029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54355 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: More pluming for OOP font loadingjeremy@chromium.org2010-06-171-8/+31
| | | | | | | | | | | | | * Add font_descriptor and corresponding pluming to send an NSFont over IPC. * Rejigger font_loader to accept an NSFont as input and output an ATSFontContainerRef. The reasoning behind this is that WebKit ultimately controls the font lifetime and we can only deactivate the font container once the font is no longer in use. BUG=29729 Test=Unit tests should pass. Review URL: http://codereview.chromium.org/2804001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50076 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 49982 - patchthakis@chromium.org2010-06-161-4/+2
| | | | | | | TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/2825006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50002 0039d316-1c4b-4281-b951-d872f2087c98
* patchthakis@chromium.org2010-06-161-2/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49982 0039d316-1c4b-4281-b951-d872f2087c98
* Add new ipc message utility and new message types in preparation for OOP ↵mirandac@chromium.org2010-05-131-1/+30
| | | | | | | | | | import patch. This patch adds the ability to move a set across IPC, and adds two new message types. BUG= 18774 TEST= none Review URL: http://codereview.chromium.org/2097001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47172 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a typo in ipc_message_utils.h.evan@chromium.org2010-03-261-1/+1
| | | | | | Review URL: http://codereview.chromium.org/1455001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42844 0039d316-1c4b-4281-b951-d872f2087c98
* base: string_util.h -> utf_string_conversions.h fix.jhawkins@chromium.org2010-03-091-1/+3
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/678001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40972 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for opening a GPU command buffer from a renderer processes ↵apatrick@chromium.org2010-03-051-1/+2
| | | | | | | | | | | | through a GPU channel. Probably only works in windows only so far. TEST=none BUG=none Review URL: http://codereview.chromium.org/657046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40783 0039d316-1c4b-4281-b951-d872f2087c98
* Take out intptr_t IPC serialization support to prevent people from sending ↵jam@chromium.org2010-02-091-15/+11
| | | | | | | | pointers between trusted and untrusted processes. Move HWNDs and other Windows HANDLEs serialization to use 32 bits even on 64 bit platforms since that's all that's needed. Review URL: http://codereview.chromium.org/565001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38455 0039d316-1c4b-4281-b951-d872f2087c98
* linux: build with -Wextraevan@chromium.org2010-02-051-2/+2
| | | | | | | | | | | | 95% of this is removing "const" from return types, but turning this on found one bug! (A "for" loop that expected its iterator to go negative but which was using an unsigned type.) BUG=34160 Review URL: http://codereview.chromium.org/570012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38266 0039d316-1c4b-4281-b951-d872f2087c98
* Add the ability for the GPU process to be used to paint the backing store of abrettw@chromium.org2010-01-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tab. This is the first pass and is currently a bit buggy and incomplete. This patch refactors the backing store to make it a virtual interface which is then implemented by the platform-specific backing stores. This cleans up the multi-platform aspects of the old code, and also makes it possible to create different backing stores (such as ones in another process). This renames the BackingStore::PaintRect function to PaintToBackingStore which clears up what it does. I would often get confused and think that it paints the backing store to the screen. This makes a common way to capture backing store information and adds it to the backing store API. This removed a bunch of ugly ifdefs. This adds the ability for a backing store to specify that the TransportDIB should not be freed by RenderWidgetHost when painting is complete. This is necessary since the out-of-process version needs to use it after the RenderWidget paint function has returned. This pushes up the vector of copy_rect from RenderWidgetHost to the actual BackingStores. This prevents us from sending duplicate data over IPC. It also makes the common non-IPC case more efficient, since we end up setting up various surfaces only once when there are multiple update rects. BUG=none TEST=none Review URL: http://codereview.chromium.org/523028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36075 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid calling vector resize() with excessive size parameter: fix broken ↵cevans@chromium.org2009-12-311-13/+7
| | | | | | | | | | | integer overflow checks, or remove resize() calls to simplify non-hot-path cases, or add stronger validations as appropriate. BUG=31364 TEST=NONE Review URL: http://codereview.chromium.org/519031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35414 0039d316-1c4b-4281-b951-d872f2087c98
* Defense-in-depth: initialize some variables.cevans@chromium.org2009-12-301-2/+2
| | | | | | | | | BUG=NONE TEST=NONE Review URL: http://codereview.chromium.org/517025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35387 0039d316-1c4b-4281-b951-d872f2087c98
* Move the utility process messages to their own file now that we have more thanbrettw@chromium.org2009-12-151-0/+2
| | | | | | | | | | 16 message types. BUG=none TEST=none Review URL: http://codereview.chromium.org/460119 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34597 0039d316-1c4b-4281-b951-d872f2087c98
* Added CommandBufferProxy, CommandBufferStub. Replaced NPAPI with IPC for ↵apatrick@google.com2009-12-121-4/+1
| | | | | | | | | | | synchronous messages. WebPluginDelegateImpl can instantiate a command buffer. Removed remaining dependencies on NPAPI. TEST=none BUG=none Review URL: http://codereview.chromium.org/465040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34397 0039d316-1c4b-4281-b951-d872f2087c98
* Added new IPC message class for CommandBuffer.apatrick@google.com2009-12-041-6/+4
| | | | | | | | | | Increased IPC message header type from 16 bits to 32 bits so it can accomodate more message classes. TEST=none BUG=none Review URL: http://codereview.chromium.org/399013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33832 0039d316-1c4b-4281-b951-d872f2087c98
* First step towards NaCl-Chrome integration:1. NaCl plugin becomes a built-in ↵gregoryd@google.com2009-09-291-0/+1
| | | | | | | | | | | plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. Command line flag "--internal-nacl" is required to enable the built-in NaCl plugin. NaCl still cannot run in Chrome sandbox, the flag automatically disables the sandboxCommitted: http://src.chromium.org/viewvc/chrome?view=rev&revision=27315 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=27324 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=27397 Review URL: http://codereview.chromium.org/153002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27445 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 27397 - First step towards NaClChrome integration:1. NaCl plugin ↵gregoryd@google.com2009-09-281-1/+0
| | | | | | | | | | | | | becomes a builtin plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. Command line flag "internalnacl" is required to enable the builtin NaCl plugin. NaCl still cannot run in Chrome sandbox, the flag automatically disables the sandboxCommitted: http://src.chromium.org/viewvc/chrome?view=rev&revision=27315 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=27324 Review URL: http://codereview.chromium.org/153002 TBR=gregoryd@google.com Review URL: http://codereview.chromium.org/235042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27400 0039d316-1c4b-4281-b951-d872f2087c98
* First step towards NaCl-Chrome integration:1. NaCl plugin becomes a built-in ↵gregoryd@google.com2009-09-281-0/+1
| | | | | | | | | plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. Command line flag "--internal-nacl" is required to enable the built-in NaCl plugin. NaCl still cannot run in Chrome sandbox, the flag automatically disables the sandboxCommitted: http://src.chromium.org/viewvc/chrome?view=rev&revision=27315 Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=27324 Review URL: http://codereview.chromium.org/153002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27397 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 27324 - First step towards NaClChrome integration:1. NaCl plugin ↵gregoryd@google.com2009-09-261-1/+0
| | | | | | | | | | | | becomes a builtin plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. Command line flag "internalnacl" is required to enable the builtin NaCl plugin. NaCl still cannot run in Chrome sandbox, the flag automatically disables the sandboxCommitted: http://src.chromium.org/viewvc/chrome?view=rev&revision=27315 Review URL: http://codereview.chromium.org/153002 TBR=bradnelson@google.com Review URL: http://codereview.chromium.org/244017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27326 0039d316-1c4b-4281-b951-d872f2087c98
* First step towards NaCl-Chrome integration:1. NaCl plugin becomes a built-in ↵gregoryd@google.com2009-09-261-0/+1
| | | | | | | | plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. Command line flag "--internal-nacl" is required to enable the built-in NaCl plugin. NaCl still cannot run in Chrome sandbox, the flag automatically disables the sandboxCommitted: http://src.chromium.org/viewvc/chrome?view=rev&revision=27315 Review URL: http://codereview.chromium.org/153002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27324 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 27315 - First step towards NaClChrome integration:1. NaCl plugin ↵gregoryd@google.com2009-09-261-1/+0
| | | | | | | | | | | | becomes a builtin plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. Command line flag "internalnacl" is required to enable the builtin NaCl plugin. NaCl still cannot run in Chrome sandbox, the flag automatically disables the sandbox Review URL: http://codereview.chromium.org/153002 TBR=gregoryd@google.com Review URL: http://codereview.chromium.org/244014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27317 0039d316-1c4b-4281-b951-d872f2087c98
* First step towards NaCl-Chrome integration:1. NaCl plugin becomes a built-in ↵gregoryd@google.com2009-09-261-0/+1
| | | | | | | | plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. Command line flag "--internal-nacl" is required to enable the built-in NaCl plugin. NaCl still cannot run in Chrome sandbox, the flag automatically disables the sandbox Review URL: http://codereview.chromium.org/153002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27315 0039d316-1c4b-4281-b951-d872f2087c98
* Preparing rollback in case things don't work out.bradnelson@google.com2009-09-181-1/+0
| | | | | | | | | | | This rolls back 26540, gregoryd's attempt at a nacl landing. BUG=None TEST=None Review URL: http://codereview.chromium.org/213019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26543 0039d316-1c4b-4281-b951-d872f2087c98
* This is a copy of http://codereview.chromium.org/153002/showgregoryd@google.com2009-09-181-0/+1
| | | | | | | | | | First step towards NaCl-Chrome integration:1. NaCl plugin becomes a built-in plugin in Chrome and runs in the renderer process.2. Most of the changes are related to launching the NaCl process (that loads and runs the NaCl module) and establishing the initial communication between that process and the NaCl plugin.3. This CL relies on another CL that contains the changes on the Native Client side: http://codereview.chromium.org/1501904. Command line flag "--internal-nacl" is required to enable the built-in NaCl plugin.5. NaCl still cannot run in Chrome sandbox, so the "--no-sandbox" flag is also required TBR=bradnelson Review URL: http://codereview.chromium.org/207025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26540 0039d316-1c4b-4281-b951-d872f2087c98
* Add a nullable string16 class to base. It combines a string16 + a null paramjorlow@chromium.org2009-08-271-0/+27
| | | | | | | | | | | | | | | | | | in order to cover all the possible states of a WebKit string. For strings where the null state is not meaninfully different from the empty state, this class should NOT be used. There are, however, some cases where we do need to track null. LocalStorage is an example. This class should be a fairly light weight way to do so. This change also adds implicit conversion to and from WebStrings. This also switches LocalStorage's IPCs over to using this new class. BUG=17343 TEST=none Review URL: http://codereview.chromium.org/174484 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24574 0039d316-1c4b-4281-b951-d872f2087c98
* Implementation of getBackgroundPage(), getToolstrips(), andaa@chromium.org2009-08-141-5/+13
| | | | | | | | | | | | | | | getTabContentses(). This lands http://codereview.chromium.org/159067. Raf, the only thing you need to look at is the changes to extensions_process_bindings.js and extension_api.json. BUG=13577 TEST=Browser tests added Review URL: http://codereview.chromium.org/164458 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23422 0039d316-1c4b-4281-b951-d872f2087c98
* Cross-process Message Port implementation.jam@chromium.org2009-08-041-0/+19
| | | | | | | | | I'm sending this first, then I'll add support to workers in another changelist to avoid making this change larger. TEST=running message port related layout tests in ui_tests Review URL: http://codereview.chromium.org/159372 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22356 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the massive type confusion for ParamTraits in the IPC code.deanm@chromium.org2009-07-281-49/+22
| | | | | | | | | | | | | By using non-primitive types (like size_t), we are constantly having problems with duplicate definitions for the same type. Just implement all of the IPC using the primitive types (int, long, etc), and there is no confusion. Also fix a bunch of incorrect format specifiers. Review URL: http://codereview.chromium.org/159520 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21872 0039d316-1c4b-4281-b951-d872f2087c98
* posix: cut down on IPC logging spew a bitevan@chromium.org2009-07-281-1/+1
| | | | | | | | We don't need to show the message type if we know the message name. Review URL: http://codereview.chromium.org/159511 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21851 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-30 17:35:18 +0000