summaryrefslogtreecommitdiffstats
path: root/webkit/glue/webplugin.h
Commit message (Collapse)AuthorAgeFilesLines
* POSIX: gfx::NativeViewId and CrossProcessEventagl@chromium.org2009-01-271-4/+5
| | | | | | | | | | | | | | | | | | | Create a couple new typedefs for porting work. Firstly, gfx::NativeViewId is a handle to a platform specific widget in the renderer process. For Windows, this is just a HWND as before. However, in other platforms the ids used in the renderer process will be something else. CrossProcessEvent is the type of a HANDLE to a Windows event object which is used across processes. Since we aren't going to support these sorts of events on non-Windows platforms, this will have to go away at some point. For now, however, this lets us build code without too many ifdefs all over the place. Review URL: http://codereview.chromium.org/18768 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8756 0039d316-1c4b-4281-b951-d872f2087c98
* No functional change. Delete trailing whitespace and word-wrap to 80 columns.evan@chromium.org2009-01-241-2/+5
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8609 0039d316-1c4b-4281-b951-d872f2087c98
* Fix layout test failures. Looks like keying the plugins based on ↵jam@chromium.org2009-01-131-5/+0
| | | | | | | | OriginalFileName didn't work, since different filenames might still have the same value (i.e. QuickTime). Instead I did what Firefox does, which is collect the list of directories in one pass, then crawl them in another. Review URL: http://codereview.chromium.org/17367 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7907 0039d316-1c4b-4281-b951-d872f2087c98
* Get rid of lowercasing plugin filenames in order to determine if two paths ↵jam@chromium.org2009-01-121-1/+6
| | | | | | | | point to the same plugin. Check plugin versions and load the latest version if multiple versions are found.I've also refactored and cleaned PluginList so that it doesn't depend on PluginLib, which only made sense a long time ago when plugins were loaded in process. Now PluginLib will only be loaded in the plugin process (and not in the browser process as well). Review URL: http://codereview.chromium.org/17451 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7888 0039d316-1c4b-4281-b951-d872f2087c98
* Move plugins to FilePaths, some cleanupavi@google.com2009-01-061-3/+4
| | | | | | Review URL: http://codereview.chromium.org/16456 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7588 0039d316-1c4b-4281-b951-d872f2087c98
* Handle HTTP 200 responses received in response to byte range requests issued ↵ananta@chromium.org2008-12-171-0/+4
| | | | | | | | by the plugin. This means that the server does not support byte range requests. Firefox handles this by destroying the current plugin instance and creating a new instance to handle the response. The stream which is created to pass the data off to the plugin is not seekable.Fix is to emulate Firefox behavior. Will work on unit testing the NPN_RequestRead related code in a separate CB. This fixes http://code.google.com/p/chromium/issues/detail?id=5403Bug=5403 Review URL: http://codereview.chromium.org/14122 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7139 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting r6396 the PDF fix to not cancel the manual data streamananta@chromium.org2008-12-051-0/+3
| | | | | | | | | | | | load when the plugin calls NPN_RequestRead. I was looking at the wrong stream implementation in Firefox :( Bug=5009 TBR=jam Review URL: http://codereview.chromium.org/13212 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6454 0039d316-1c4b-4281-b951-d872f2087c98
* Don't cancel the original manual data stream request when the plugin invokesananta@chromium.org2008-12-041-3/+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
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-091-0/+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
* This CB fixes the following issue1. ↵iyengar@google.com2008-09-191-1/+12
| | | | | | | | 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
* fix build issue on Linux with GCC 4.1.2evanm@google.com2008-09-081-0/+1
| | | | | | | | | | | related to non-virtual destructors in classes having virtual methods BUG=1859 Patch from Paweł Hajdan jr <phajdan.jr@gmail.com>. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1860 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
* Step 1 at making Gears run in the renderer process (enabled by switchmpcomplete@google.com2008-08-151-0/+3
| | | | | | | | | "--gears-in-renderer"). Requires some changes to gears to work. Most things work if you disable the sandbox. One major hole is that update tasks don't report status to the appropriate renderer. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@954 0039d316-1c4b-4281-b951-d872f2087c98
* Make more cross-platformpinkerton@google.com2008-08-151-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@917 0039d316-1c4b-4281-b951-d872f2087c98
* Add webkit to the repository.initial.commit2008-07-271-0/+170
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-19 00:23:53 +0000