| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
while playing
playlists, etc. The message is displayed when we fail to create a channel for the plugin
process.
The problem occurs because of a race condition between the plugin channel information being
deleted from the channel map and the actual channel being deleted. This race occurs if
the plugin is in the context of a sync call to the renderer which results in the plugin
instance being deleted and the new one getting created in the same context. This results
in the plugin channel information getting deleted from the map. The actual channel gets
deleted only when the plugin sync call unwinds which occurs after the browser sends in
a request to create the channel for the new plugin instance.
Fix is to create the channel name with an incrementing number in the plugin process, if
the mode is server. The channel map is still keyed off the process id and renderer id
as before.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=43595
Bug=43595
Test=Covered by new ui test SelfDeleteCreatePluginInNPNEvaluate.
The other change is a fix in the test plugin to delete a windows timer correctly and
to add support for a new plugin test case.
Review URL: http://codereview.chromium.org/3142039
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57372 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test should now fit on an 800x600 display, which is apparently what the 10.6 bots have.
Removes the FLAKY marker since it should now pass on 10.6 bots.
BUG=36670
TEST=PluginConvertPointTest should pass on 10.6 bots
Review URL: http://codereview.chromium.org/2100008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47720 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=29457,31767
TEST=self-testing
Review URL: http://codereview.chromium.org/580019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38417 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
set. This emulates the
behavior of other browsers and fixes http://code.google.com/p/chromium/issues/detail?id=28800
I added a UI test to validate that the plugin source URL is set on outgoing GetURL requests issued
by the plugin. To validate that the document URL is set as the referrer on the initial URL request
would take some more work. Will try and add that in a future CL.
I also changed the WebPluginImpl::RouteToFrame function to set the referrer on similar lines.
Bug=28800
Test=Covered by UI test
Review URL: http://codereview.chromium.org/459003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33673 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
|
|
|
|
|
|
|
|
|
|
|
| |
NPP_Destroy.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/338050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30628 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
TEST=none
BUG=18020
Review URL: http://codereview.chromium.org/329013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30105 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
speculative fix was correct.
I tracked this down to my earlier change to not leak NPObjects on channel shutdown (which now happens a lot more often because of sudden termination for tab close). Since we now call an NPObject's deallocate function, it's possible that it leads to an NPObjectProxy being deleted, in which case we would delete an object in the listener's array while we're looping across it.
BUG=25439
Review URL: http://codereview.chromium.org/332013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29982 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
function crashes.
BUG=25104
Review URL: http://codereview.chromium.org/337004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29923 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28344 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
to the renderer so this instance is in the callstack, destruction will have to be asynchronous and so scripting still won't work. This change also fixes use of PluginChannel after it's deleted (if this was the last instance).
BUG=23713, 23706
TEST=added ui test
Review URL: http://codereview.chromium.org/258026
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28141 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This parameter is used to support _self and other names that
need to be evaluated relative to a subframe.
R=jam
BUG=23009
TEST=none
Review URL: http://codereview.chromium.org/257005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27646 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PluginStreamUrl::DidReceiveData
function. This crash occurs if the PluginStreamUrl instance is deleted in the context of
PluginStream::Write which occurs if the underlying NPP_Write call to the plugin returns
a negative value, indicating that the plugin did not accept data. We close the stream in
this case which releases existing references to the PluginStream which results in the object
being deleted.
Added a UI test for this case.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=19393
Bug=19393
Review URL: http://codereview.chromium.org/199093
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26011 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
context of NPP_NewStream.
The plugin would invoke NPN_Evaluate to display an alert in the context of NewStream. This would cause the didFail IPC to be dispatched which would cause the plugin to invoke another call to NPP_NewStream which would repeat these steps and crash.
The didFail call from the renderer did not honor the deferred load flag which we set in WebPluginImpl
prior to dispatching stream IPCs to the plugin.
Fix is to dispatch the didFail call when we receive an ack from the plugin indicating that it is ready to accept stream data.
This fixes bug http://code.google.com/p/chromium/issues/detail?id=20063
The other change is in WebPluginImpl::TearDownPluginInstance, where we run through the list of resource
clients and cancel them. We call didFail on these clients here, which occurs anyway through the PluginDestroyed
code path.
Bug=20063
Test=Convered by interactive UI test.
Review URL: http://codereview.chromium.org/174383
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24593 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
outgoing sync calls.
I will be watching the reliability test runs closely for any crashes which creep in due to reentrancies into plugins caused by this CL.
This fixes bug http://code.google.com/p/chromium/issues/detail?id=15985
It is a touch tricky to implement a test case for this. Will add one hopefully in a subsequent CL
Bug=15985
Test=Covered by UI test
Review URL: http://codereview.chromium.org/173211
TBR=ananta@chromium.org
Review URL: http://codereview.chromium.org/173384
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24296 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I will be watching the reliability test runs closely for any crashes which creep in due to reentrancies into plugins caused by this CL.
This fixes bug http://code.google.com/p/chromium/issues/detail?id=15985
It is a touch tricky to implement a test case for this. Will add one hopefully in a subsequent CL
Bug=15985
Test=Covered by UI test
Review URL: http://codereview.chromium.org/173211
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24266 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
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/115339
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16034 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
wait on UI thread. Instead of using sync messages, the plugin hwnd is initially parented to the RenderWidgetHost's HWND. It's then lazily reparented to an intermediate HWND on the UI thread when it comes time to move it.
BUG=10711
TEST=added regression tests, but testers please confirm plugins on top video sites are placed correctly.
Review URL: http://codereview.chromium.org/67285
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14137 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
implement this for multi-process mode only and not --single-process or --in-process-plugins, since I wanted to send this data from the browser process, not the renderer (in case it's exploited).
BUG=158
Review URL: http://codereview.chromium.org/52037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12588 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=4270
Review URL: http://codereview.chromium.org/10620
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5310 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as we need to simulate mousemoves here. ui tests run on machines which are locked,
causing this test to fail.
Moved the NPAPITester and NPAPIVisiblePluginTester classes to a common file
npapi_test_helper.cc so it can be used from both tests.
Relanding the SetCursor patch. It has already been approved by John.
Description below:-
Proposed fix for http://b/issue?id=1362948, which is a crash in the rendererwhen we invoke the setCursor call on the parent view in WebPluginImpl::handleEvent.
This crash occurs because the plugin is deleted in the context of a mouse down event. This could occur by invoking a javascript function via NPN_Evaluate. On return from the HandleEvent sync call we attempt to retreive the parent frame, which
returns NULL and hence the crash.
The fix is to retreive the parent frameview at the start of the WebPluginImpl::handleMouseEvent function and use it whereever needed.
Added a unit test which deletes the plugin instance in a mousemove event.
R=jam
Bug=1362948
Review URL: http://codereview.chromium.org/8691
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4115 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/8861
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4107 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rendererwhen we invoke the setCursor call on the parent view in WebPluginImpl::handleEvent.
This crash occurs because the plugin is deleted in the context of a mouse down event. This could occur by invoking a javascript function via NPN_Evaluate. On return from the HandleEvent sync call we attempt to retreive the parent frame, which
returns NULL and hence the crash.
The fix is to retreive the parent frameview at the start of the WebPluginImpl::handleMouseEvent function and use it whereever needed.
Added a unit test which deletes the plugin instance in a mousemove event.R=jamBug=1362948
Review URL: http://codereview.chromium.org/8178
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4094 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an issue with a windowed flash instance not rendering content at times.The bug occurs as a result of the following:-1. The flash plugin executes a script via GetURLNotify. This script calls window.open with the target as self, which shows up as a new tab in the browser. This causes a new RenderView object to be instantiated (See RenderView::CreateWebView).2. RenderView::CreateWebView sends over the ViewHostMsg_CreateWindow IPC message to the browser. The handler in the browser sends over an ack for this message with the window handle. This is used as the parent window for any plugins instantiated in the page.3. At times, the newly created view starts receiving data which is processed before the ViewMsg_CreatingNew_ACK message is received and processed by the view. This causes the plugin to be instantiated without a parent window thus ending up as a top level window.The fix is to queue up resource messages and process them after we receive the ack for the ViewHostMsg_CreateWindow IPC.
Tests :- Covered by UI tests.
R=jam
Review URL: http://codereview.chromium.org/7514
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3631 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
|