summaryrefslogtreecommitdiffstats
path: root/chrome/plugin/webplugin_proxy.cc
Commit message (Collapse)AuthorAgeFilesLines
* Make sure that seekable streams are removed from the list of resource ↵ananta@chromium.org2009-05-231-0/+14
| | | | | | | | | | | | | | | | | | | | clients maintained by WebPluginProxy. The PluginStreamUrl object ensures that it notifies the webplugin object that it is being deleted in its destructor. The other change is to remove the call to CancelRequest in WebPluginDelegateImpl::CreateResourceClient for seekable streams, as this call does not do anything for manual streams created with a resource id of -1. In any case for byte range requests, receiving a new response does not mean that earlier requests should be cancelled. This fixes bug http://code.google.com/p/chromium/issues/detail?id=12445 BUG=12445 Review URL: http://codereview.chromium.org/113772 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16828 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI gears drag drop and renderer IPC.michaeln@google.com2009-05-221-0/+52
| | | | | | | | | | | | | | | CPAPI (0.10) functions for gears drag drop; one to extract thedrag type/data given an NPObject *event, one to override thedrop effect (drag cursor). Gears drag drop API receives a browser event as an NPObject* sothe event is untrusted. Provide IPC calls to the renderer sogears can pass the event to renderer/V8 for checking, prior todrag type/data extraction, or the setting of the drop effect. Original patch by Noel Gordon via: http://codereview.chromium.org/99240 BUG=7995 TEST=none Review URL: http://codereview.chromium.org/112056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16808 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeCanvas->gfx::Canvasben@chromium.org2009-05-151-1/+1
| | | | | | | | | | | Rename files too. TBR=brettw http://crbug.com/11387 Review URL: http://codereview.chromium.org/113443 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16148 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 15986.michaeln@google.com2009-05-131-52/+0
| | | | | | Review URL: http://codereview.chromium.org/113359 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15987 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI gears drag drop and renderer IPC....michaeln@google.com2009-05-131-0/+52
| | | | | | | | | | | | | | | | | | | | | | CPAPI (0.10) functions for gears drag drop; one to extract the drag type/data given an NPObject *event, one to override the drop effect (drag cursor). Gears drag drop API receives a browser event as an NPObject* so the event is untrusted. Provide IPC calls to the renderer so gears can pass the event to renderer/V8 for checking, prior to drag type/data extraction, or the setting of the drop effect. V8 event checking is a TODO(noel), http://mondrian/10947778 for the CPAPI (0.10) change submitted to gears. BUG=7995 Original patch by Noel Gordon via: http://codereview.chromium.org/99240 Review URL: http://codereview.chromium.org/115280 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15986 0039d316-1c4b-4281-b951-d872f2087c98
* Move win_util.h from common to app.ben@chromium.org2009-05-081-1/+3
| | | | | | | | http://crbug.com/11387 Review URL: http://codereview.chromium.org/113169 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15694 0039d316-1c4b-4281-b951-d872f2087c98
* Move chrome_canvas to app/gfxben@chromium.org2009-05-061-1/+1
| | | | | | | | http://crbug.com/11387 Review URL: http://codereview.chromium.org/113011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15361 0039d316-1c4b-4281-b951-d872f2087c98
* Fail the plugin initialization if we are unable to duplicate the event ↵ananta@chromium.org2009-04-271-2/+6
| | | | | | | | | | | | | | handle which is used for deciding whether we need to pump window messages in outgoing sync calls from the plugin. The theory is that the DuplicateHandle call could fail if the renderer process exited. It is unclear as to what a reliable test for this would be. Will think over and possibly add in a future CB. Fixes http://code.google.com/p/chromium/issues/detail?id=10972 Bug=10972 Review URL: http://codereview.chromium.org/99018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14662 0039d316-1c4b-4281-b951-d872f2087c98
* linux (and some posix): multiprocess plugins compiling.evan@chromium.org2009-04-231-9/+34
| | | | | | | | | | | | | | | | | | | 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
* Fix hang seen in plugin process because plugin creation ended up having to ↵jam@chromium.org2009-04-211-30/+9
| | | | | | | | | | 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
* Fix Mac build break.jam@chromium.org2009-04-011-1/+1
| | | | | | Review URL: http://codereview.chromium.org/56137 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12931 0039d316-1c4b-4281-b951-d872f2087c98
* Port plugin messages.jam@chromium.org2009-04-011-34/+40
| | | | | | Review URL: http://codereview.chromium.org/49050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12928 0039d316-1c4b-4281-b951-d872f2087c98
* We need to set the clipping region of the HDC passed in to a windowless ↵ananta@chromium.org2009-03-271-0/+7
| | | | | | | | | | | | | | | | | | flash plugin instance in NPP_HandleEvent for WM_PAINT. The windowless flash plugin instance queries the clipping region of the DC and on not finding it proceeds to paint the plugin window rect, which causes unnecessary CPU spikes. This fixes bug http://code.google.com/p/chromium/issues/detail?id=8835, where the plugin process would consume CPU even when we scrolled down to the static video images. With this fix the CPU usage for windowless flash plugins is on par with Firefox. Added a uitest which validates whether the hdc passed in to HandleEvent for WM_PAINT has a valid clipping region. Bug=8835 Review URL: http://codereview.chromium.org/53106 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12651 0039d316-1c4b-4281-b951-d872f2087c98
* Expose whether we're in private browsing mode to plugins.I chose to ↵jam@chromium.org2009-03-261-0/+4
| | | | | | | | | 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
* Report the plugin position to windowed plugins as (0,0)jam@chromium.org2009-03-261-1/+3
| | | | | | | | | | . the NPAPI documentation says it should be reported relative to the parent HWND, which is the plugin's coordinates on the page. This assumption breaks in Chrome because we have an intermediate HWND. I've tested on a bunch of pages to see if this change causes regressions, if we find any in the future we can reconsider this. BUG=6742 Review URL: http://codereview.chromium.org/42626 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12587 0039d316-1c4b-4281-b951-d872f2087c98
* Add more info to a dcheck to see why DuplicateHandle is failing on the buildbot.jam@chromium.org2009-03-121-1/+2
| | | | | | Review URL: http://codereview.chromium.org/42109 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11514 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGE.maruel@google.com2009-03-101-1/+2
| | | | | | | Fix files with lines > 80 cols. Part 2. Review URL: http://codereview.chromium.org/40226 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11326 0039d316-1c4b-4281-b951-d872f2087c98
* Coalesce more hardcoded schemes to using predefined constants.brettw@chromium.org2009-02-261-2/+4
| | | | | | Review URL: http://codereview.chromium.org/31008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10437 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-211-2/+2
| | | | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=10080 Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10144 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 10080.jam@chromium.org2009-02-201-2/+2
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10082 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-201-2/+2
| | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10080 0039d316-1c4b-4281-b951-d872f2087c98
* Lots of small nits to help to split off webkit.dll.maruel@chromium.org2009-02-121-16/+17
| | | | | | | | | - Stop directly referencing WebPluginDelegateImpl. - Make the password manager to not allocation the data on heap. - Remove some unneeded includes. Review URL: http://codereview.chromium.org/20208 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9692 0039d316-1c4b-4281-b951-d872f2087c98
* Improve scrolling performance when there are many windowed plugins in a page.jam@chromium.org2009-01-161-7/+32
| | | | | | | | This works by parenting windowed plugins with an HWND that's hosted in the browser process, so that no synchronous cross process messages are used when scrolling. BUG=5428 Review URL: http://codereview.chromium.org/18082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8239 0039d316-1c4b-4281-b951-d872f2087c98
* Block Adobe Reader from issuing NPN_GetURL/NPN_GetURLRequests for URL ↵ananta@chromium.org2009-01-161-0/+13
| | | | | | | | schemes other than http/https/ftp. This mimics Firefox behavior and works around bug http://b/issue?id=1543405 which is a XSS vulnerability in the Adobe Reader plugin where it allows javascript in the parameters passed in to the URL.Bug=1543405R=jam Review URL: http://codereview.chromium.org/18070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8159 0039d316-1c4b-4281-b951-d872f2087c98
* WaitableEvent is the replacement for Windows events. Previously in the code, ↵agl@chromium.org2009-01-151-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a HANDLE from CreateEvent was used for signaling, both within a process and across processes. WaitableEvent is the cross platform replacement for this. To convert: * HANDLE -> base::WaitableEvent* * ScopedHandle -> scoped_ptr<base::WaitableEvent> * CreateEvent -> new base::WaitableEvent * SetEvent -> base::WaitableEvent::Signal * ResetEvent -> base::WaitableEvent::Reset * ObjectWatcher -> base::WaitableEventWatcher * WaitForMultipleObjects -> static base::WaitableEvent::WaitMany ObjectWatcher remains for Windows specific code. WaitableEventWatcher has an identical interface save, * It uses WaitableEvents, not HANDLEs * It returns void from StartWatching and StopWatcher, rather than errors. System internal errors are fatal to the address space IMPORTANT: There are semantic differences between the different platforms. WaitableEvents on Windows are implemented on top of events. Windows events work across process and this is used mostly for modal dialog support. Windows events can be duplicated with DuplicateHandle. On other platforms, WaitableEvent works only within a single process. In the future we shall have to replace the current uses of cross-process events with IPCs. BEWARE: HANDLE, on Windows, is a void *. Since any pointer type coerces to void *, you can pass a WaitableEvent * where a HANDLE is expected without any build-time errors. Review URL: http://codereview.chromium.org/16554 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8126 0039d316-1c4b-4281-b951-d872f2087c98
* Move the "platform" wrappers in skia/ext to the skia namespace.brettw@google.com2008-12-171-1/+1
| | | | | | Review URL: http://codereview.chromium.org/14110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7182 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing build bustage. Adding files which were part of the original changeananta@chromium.org2008-12-051-0/+4
| | | | | | | | | | branch r6396, which was reverted partially. TBR=jam Review URL: http://codereview.chromium.org/13215 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6460 0039d316-1c4b-4281-b951-d872f2087c98
* Don't cancel the original manual data stream request when the plugin invokesananta@chromium.org2008-12-041-4/+0
| | | | | | | | | | | | | | | | | | | | NPN_RequestRead to initiate seekable byte range requests on the stream. While the contract on the plugins part is not fully clear from the mozilla docs, this is what Firefox does. This also improves performance greatly as the manual data stream already has most of the data which the plugin requests anyway. I verified this with large PDF files around 14-15MB. We are twice as faster with this fix. This fixes http://code.google.com/p/chromium/issues/detail?id=5009, which is an issue with the PDF file not loading at times. The problem also occurs at times in Firefox when we set breakpoints and thus slow down the operation. The Reader plugin displays its UI in child windows on a separate thread in the plugin process. These are parented to the plugin window which lives on the plugin thread. The plugin thread unfortunately is treated as an IO thread by the plugin and it uses the SendMessage API to send messages to the plugin thread and back. If the plugin fails to receive data for the PDF file in a reasonable time, it just destroys the PDF window hierarchy causing this issue. Handing the data off the manual data stream along with the byte range data speeds up the whole operation and thus avoids this issue to a great extent. Bug=5009 R=jam Review URL: http://codereview.chromium.org/12960 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6396 0039d316-1c4b-4281-b951-d872f2087c98
* Remove base versions of the graphics headers, which previously just ↵brettw@google.com2008-11-221-1/+1
| | | | | | | | forwarded to the skia ones. Review URL: http://codereview.chromium.org/11588 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5894 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding this fix. The earlier attempt broke test_shell_tests. The fixananta@chromium.org2008-11-211-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | has been added to this CB. Fix Silverlight windowless plugin painting issues. This fixes the following issues:- 1. http://code.google.com/p/chromium/issues/detail?id=4272 2. http://code.google.com/p/chromium/issues/detail?id=301 (Partially) The fixes are as below:- 1. Silverlight in the NPP_HandleEvent call for WM_PAINT, calls NPN_GetProperty for a bunch of properties like pageXOffset, pageYOffset, etc. It expects these properties to have integer types on return. We always return double. Firefox returns integer for these properties. Added a check in the conversion to NPVariant function in v8 to check for whether the value is an integer and return the intger type. 2. When the windowless plugin calls NPN_InvalidateRect we ask the plugin to paint in the same call, which the Silverlight plugin does not like. It relies on the fact that browsers would initiate invalidation asynchronously and eventually paint. This is a perfectly legal assumption. The Flash plugin does work if we synchronously ask it to paint. However other plugins could have similar issues. I verified with worldofwarcraft.com to see if the async paint has any sideeffects and there were none. 3.If the Silverlight plugin is not visible initially as on msdn.microsoft.com, it does not paint. This occurs because the plugin expects proper paints to come from the browser. It does not invalidate itself in UpdateGeometry as Flash. The plugin widget on msdn is not dynamic. It does call NPN_InvalidateRect initially when it is not visible. We don't send the call to the renderer as the plugin is not visible. To workaround this we now track the damaged rect even if the rect does not intersect the clipping rect of the plugin. In a geometry update if the plugin is visible, we send over the accumulated damaged rect to the renderer. The Silverlight plugin instance on msdn.microsoft.com does not work correctly even with these fixes. However it paints correctly. R=jam Bug=4272,301 Review URL: http://codereview.chromium.org/11569 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5829 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r5816 due to InvokeMethods failures in test_shell_tests.sgk@google.com2008-11-211-22/+6
| | | | | | Review URL: http://codereview.chromium.org/11342 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5818 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Silverlight windowless plugin painting issues. This fixes theananta@chromium.org2008-11-211-6/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | following issues:- 1. http://code.google.com/p/chromium/issues/detail?id=4272 2. http://code.google.com/p/chromium/issues/detail?id=301 (Partially) The fixes are as below:- 1. Silverlight in the NPP_HandleEvent call for WM_PAINT, calls NPN_GetProperty for a bunch of properties like pageXOffset, pageYOffset, etc. It expects these properties to have integer types on return. We always return double. Firefox returns integer for these properties. Added a check in the conversion to NPVariant function in v8 to check for whether the value is an integer and return the intger type. 2. When the windowless plugin calls NPN_InvalidateRect we ask the plugin to paint in the same call, which the Silverlight plugin does not like. It relies on the fact that browsers would initiate invalidation asynchronously and eventually paint. This is a perfectly legal assumption. The Flash plugin does work if we synchronously ask it to paint. However other plugins could have similar issues. I verified with worldofwarcraft.com to see if the async paint has any sideeffects and there were none. 3.If the Silverlight plugin is not visible initially as on msdn.microsoft.com, it does not paint. This occurs because the plugin expects proper paints to come from the browser. It does not invalidate itself in UpdateGeometry as Flash. The plugin widget on msdn is not dynamic. It does call NPN_InvalidateRect initially when it is not visible. We don't send the call to the renderer as the plugin is not visible. To workaround this we now track the damaged rect even if the rect does not intersect the clipping rect of the plugin. In a geometry update if the plugin is visible, we send over the accumulated damaged rect to the renderer. The Silverlight plugin instance on msdn.microsoft.com does not work correctly even with these fixes. However it paints correctly. R=jam Bug=4272,301 Review URL: http://codereview.chromium.org/11492 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5816 0039d316-1c4b-4281-b951-d872f2087c98
* Add Terminate() to the Process object, have RenderProcessHost use this to ↵brettw@google.com2008-11-141-6/+6
| | | | | | | | | | avoid some more Windows specific code. Move Process and SharedMemory into the base namespace (most changes). Review URL: http://codereview.chromium.org/10895 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5446 0039d316-1c4b-4281-b951-d872f2087c98
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-091-2/+3
| | | | | | | | | | | | | | | Implement "iframe shim" behavior for windowed plugins. In FF and IE on windows, iframes are implemented as native HWNDs. This has the side effect that iframes display on top of windowed plugins. This side effect has long been known as a workaround for allowing HTML elements to appear above plugin content. BUG=1788 Review URL: http://codereview.chromium.org/7032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3137 0039d316-1c4b-4281-b951-d872f2087c98
* Fix videos stopping playing. Only send an invalidate to the renderer if ↵jam@chromium.org2008-10-091-2/+4
| | | | | | | | | it's within the clipping region, otherwise we'll wait forever for a did paint message that doesn't come. BUG=115 Review URL: http://codereview.chromium.org/6257 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3123 0039d316-1c4b-4281-b951-d872f2087c98
* Fix painting problem with transparent plugins because plugins were ignoring ↵jam@chromium.org2008-10-011-47/+68
| | | | | | | | | | | | | | | the alpha channel sometimes. This change introduces another buffer which holds the background image for transparent plugins. Before painting these plugins, their backing store is overwritten with the background data. This change also uses an ACK from the renderer to figure out when it can paint, similar to how the renderer does it, which gives us throttling and also doesn't lead to painting when the tab is hidden. Review URL: http://codereview.chromium.org/5040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2744 0039d316-1c4b-4281-b951-d872f2087c98
* Desynchronize windowless plugin painting. This greatly improves the paintingjam@chromium.org2008-09-221-25/+120
| | | | | | | | performance when there are multiple plugins, or when scrolling. Review URL: http://codereview.chromium.org/3133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2459 0039d316-1c4b-4281-b951-d872f2087c98
* This CB fixes the following issue1. ↵iyengar@google.com2008-09-191-0/+14
| | | | | | | | http://code.google.com/p/chromium/issues/detail?id=206This is a performance issue while loading PDF documents. The fix is to support PDF fast webview, which is basically support for the NPN_RequestRead API, which allows a plugin to request specific byte ranges in HTTP GET requests. This also needs support for seekable streams. Our support for seekable streams is limited to HTTP servers which allow byte range requests. Firefox also supports a mode in which the the browser caches the file on disk for servers which don't support byte range requests. The plugin_data_stream.cc/.h files are being removed as there is not much value in their existence. The needed functionality is available in the PluginStreamUrl class, which now services manual data streams as well. Testing this is a touch tricky as we need a HTTP server which serves byte range requests. Will add those in a subsequent CB.Also fixed a bug in the multipart parser where we need to ignore leading newline characters while parsing the header.Bug=206 Review URL: http://codereview.chromium.org/2896 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2400 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* Add chrome to the repository.initial.commit2008-07-261-0/+269
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-20 08:17:23 +0000