summaryrefslogtreecommitdiffstats
path: root/chrome/test/data/npapi
Commit message (Collapse)AuthorAgeFilesLines
* Fix for the missing plugin message displayed at times on sites like youtube ↵ananta@chromium.org2010-08-251-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Shrink the window used for the NPN_ConvertPoint teststuartmorgan@chromium.org2010-05-191-1/+1
| | | | | | | | | | | | | 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
* Finish implementing NPN_ConvertPoint, and add a unit test for itstuartmorgan@chromium.org2010-02-091-0/+27
| | | | | | | | | 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
* Don't set referrers on outgoing plugin requests if the load_manually flag is ↵ananta@chromium.org2009-12-033-0/+47
| | | | | | | | | | | | | | | | | | | 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
* If an NP_* function is called on an out of process plugin, save enough info ↵japhet@chromium.org2009-11-181-0/+24
| | | | | | | | 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
* Ensure that NPN_PluginThreadAsyncCall callbacks are not invoked after ↵apatrick@google.com2009-10-301-0/+42
| | | | | | | | | | | 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
* Implemented NPN_ScheduleTimer and NPN_UnscheduleTimer.apatrick@google.com2009-10-261-0/+25
| | | | | | | | | 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
* Add a regression test for the PluginChannel::CleanUp. My earlier ↵jam@chromium.org2009-10-241-0/+50
| | | | | | | | | | | 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
* Add a regression test for the renderer hang when a plugin's NP_Initialize ↵jam@chromium.org2009-10-231-0/+28
| | | | | | | | | 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
* fix error in js from previous checkinjam@chromium.org2009-10-071-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28344 0039d316-1c4b-4281-b951-d872f2087c98
* Fix scripting during NPP_Destroy. Note that if the plugin is making a call ↵jam@chromium.org2009-10-062-0/+54
| | | | | | | | | | 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
* Add an optional WebFrame parameter to WebView::findFrameByName.darin@chromium.org2009-09-302-0/+27
| | | | | | | | | | | | | 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
* Fixes a crash in the plugin process specifically in the ↵ananta@chromium.org2009-09-113-0/+32
| | | | | | | | | | | | | | | | | | | | 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
* Fixes a crash caused due to a call to NPP_DestroyStream occuring in the ↵ananta@chromium.org2009-08-271-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert 24266 - This CL ensures that plugins always peek in the context of ↵ananta@chromium.org2009-08-251-39/+0
| | | | | | | | | | | | | | | | | | | | | 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
* This CL ensures that plugins always peek in the context of outgoing sync calls. ananta@chromium.org2009-08-251-0/+39
| | | | | | | | | | | | | | | 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
* Fix browser hang due to plugin deadlockamit@chromium.org2009-06-031-0/+38
| | | | | | | | | | | | | | | | | | | | | 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
* Check in missing html.jam@chromium.org2009-05-141-0/+37
| | | | | | Review URL: http://codereview.chromium.org/115339 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16034 0039d316-1c4b-4281-b951-d872f2087c98
* Fix hang seen in plugin process because plugin creation ended up having to ↵jam@chromium.org2009-04-211-0/+44
| | | | | | | | | | 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
* Expose whether we're in private browsing mode to plugins.I chose to ↵jam@chromium.org2009-03-261-0/+25
| | | | | | | | | 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
* Fix http://code.google.com/p/chromium/issues/detail?id=4270. Test case added.mpcomplete@google.com2008-11-121-0/+43
| | | | | | | | 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
* Moved the SelfDeletePluginInvokeInSynchronousMouseMove to interactive ui testsananta@chromium.org2008-10-291-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r4094; ui_tests failures in SelfDeletePluginInvokeInSynchronousMouseMove.sgk@google.com2008-10-281-39/+0
| | | | | | Review URL: http://codereview.chromium.org/8861 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4107 0039d316-1c4b-4281-b951-d872f2087c98
* Proposed fix for http://b/issue?id=1362948, which is a crash in the ↵ananta@chromium.org2008-10-281-0/+39
| | | | | | | | | | | | | | 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
* This fixes http://code.google.com/p/chromium/issues/detail?id=205, which was ↵ananta@chromium.org2008-10-202-0/+54
| | | | | | | | | | | | | 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
* Add chrome to the repository.initial.commit2008-07-2616-0/+579
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98