| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47090 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47070 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
This occurs when the renderer sends an async message with the unblock flag, and then a sync message right after. If the plugin process just made a sync (with no unblock) call to the renderer, it'll dispatch the first message, and if that leads to a sync call to the renderer, then the unblock flag won't get sent and a deadlock occurs.
BUG=43617
Review URL: http://codereview.chromium.org/2045012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47063 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
TBR=darin
BUG=none
TEST=none
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41812 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
other side's address
space. Basically the way this works is if an NPObject is marshaled over to the other side, an
NPObjectStub is created in the caller address space and a NPObjectProxy is created on the other side.
The NPObjectProxy is passed the raw NPObject pointer which is used as a cookie.
If the original NPObject needs to be passed back we pass the underlying NPObject saved in the NPObjectProxy.
The receiver does not validate whether this NPObject is valid before invoking on it.
While this is mostly fine, in the case of a compromised renderer invalid addresses could be passed back
to the plugin which would invoke on these addresses and crash.
Fix is to never pass raw object pointers across and just pass the corresponding routing id of the NPObjectStub.
The receiver validates this object by invoking a new method GetNPObjectListenerForRoute on the PluginChannelBase.
This method returns the corresponding NPObject listener for the routing id. We then retrieve the underlying NPObject
from the listener and use it.
The map of NPObjectListeners which is maintained by PluginChannelBase has been changed to hold NPObjectBase
pointers instead. NPObjectStub and NPObjectProxy implement the new NPObjectBase interface which provides
methods to return the underlying NPObject and the IPC::Channel::Listener pointer.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=31880
I verified with the steps outlined in the bug that this fix does address the underlying crash.
Bug=31880
Test=We need a framework to test PluginChannel and NPObjectProxy/Stub. Will add a test case for this
once we have this in place.
Review URL: http://codereview.chromium.org/548046
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36618 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
to send an NPN_SetException back to the correct renderer if necessary. BUG=26764 TEST=none
Review URL: http://codereview.chromium.org/375005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32419 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=22210 (this is not a partial mitigation, not a fix)
Review URL: http://codereview.chromium.org/399043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32397 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
the really hard ones which will need actual review instead of rubber-stamping.)
Review URL: http://codereview.chromium.org/386026
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31932 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
BUG=26749
Review URL: http://codereview.chromium.org/360043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31167 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
app/gfx in preparation for removing the base_gfx project. This also moves
base/window_impl.cc to app/win/window_impl because this file shouldn't be in
base.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/273017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28691 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
processes to run nested message loops when a dialog is shown. Instead use an async message that's broadcast from the renderer to all plugin processes that are connected to it, and which is dispatched on the plugin IO thread to set a process-local waitable event. This fixes showModalDialog on Linux/Mac.
BUG=15891
TEST=covered by UI tests, undef's them for POSIX
Review URL: http://codereview.chromium.org/242043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27456 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
|
|
|
|
|
|
|
|
|
|
| |
IPC channel (doh!).
BUG=119052
TEST=covered by ui test that Amit added
Review URL: http://codereview.chromium.org/119158
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17712 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involves two plugin instances with second instance making
sync calls to the renderer while the first one is still servicing
an incoming sync request.
Our logic to unblock the renderer during the sync call fails
since the 'in_dispatch_' counter is maintained per plugin channel
(each plugin instance uses its own separate channel). Making
'in_dispatch_' counter static member of PluginChannelBase fixes this
deadlock.
Added a new NPAPI UI test for this scenario.
BUG=12624
TEST=MultipleInstancesSyncCalls
Review URL: http://codereview.chromium.org/119052
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17492 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal of this change is to *not* make any behavioral change, but to
instead just get all the plugin-related files linking on Linux with
a bunch of NOTIMPLEMENTED()s in the appropriate places. It's enormous
enough already without any refactorings or new features.
Changes include:
- Lots of gcc warning fixes.
- Use portable replacements for Windows-specific functions (_strdup, etc.).
- Use TransportDIB instead of just shared memory in the plugin messaging.
Note that this is not fleshed out on Linux and on Windows it just hacks
in the existing handles so there should be no functional change.
- Fix --plugin-launcher to use cross-platform APIs.
Review URL: http://codereview.chromium.org/79020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14338 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
|
|
|
|
|
|
|
|
|
|
|
| |
which does the right thing based on whatever platform we're
compiling for, along with changing the hardcoded "stdext::",
which is a MSVC++ism to use base::hash_{map,set}.
B=1869
Review URL: http://codereview.chromium.org/1629
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1862 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
|