summaryrefslogtreecommitdiffstats
path: root/webkit/glue/plugins/plugin_instance.h
Commit message (Collapse)AuthorAgeFilesLines
* More removal of WebCore usage from webplugin_impl.ccdarin@chromium.org2009-08-211-6/+5
| | | | | | | | | | | | Adds a few helper methods on WebFrame. R=jam BUG=10036 TEST=none Review URL: http://codereview.chromium.org/173152 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23956 0039d316-1c4b-4281-b951-d872f2087c98
* linux plugins: eliminate GtkWidget* from plugin processevan@chromium.org2009-06-261-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [retry with mac hopefully fixed this time] GtkWidget* (and its wrapper, gfx::NativeView) only work within a single process. Plugins already work with a lower-level type that works across processes -- an X Window id. The parent of a plugin is an HWND on windows, but it's an X Window id on X. So we introduce a new typedef wrapping that and push it through all the places in the code that needs it. Since we no longer have a GtkSocket in the WebPluginDelegateImpl, we need to do a bit more work in the WebViewDelegate (aka the browser process in the multiproc world). We also need the plugin host (the browser) to track the GtkSockets that are hosting the plugin, as well as destroy them when necessary. To do this we require the plugin owner to grab the plug-removed signal rather than putting its handler in GtkPluginContainer; this is the way it worked before I'd refactored into GtkPluginContainer so it shouldn't be so bad. This change still only works in test_shell, but the refactoring should translate to the multiprocess case pretty easily. Review URL: http://codereview.chromium.org/146009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19387 0039d316-1c4b-4281-b951-d872f2087c98
* Revert all of my patches from today.evan@chromium.org2009-06-261-5/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19328 0039d316-1c4b-4281-b951-d872f2087c98
* linux plugins: eliminate GtkWidget* from plugin processevan@chromium.org2009-06-261-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | GtkWidget* (and its wrapper, gfx::NativeView) only work within a single process. Plugins already work with a lower-level type that works across processes -- an X Window id. The parent of a plugin is an HWND on windows, but it's an X Window id on X. So we introduce a new typedef wrapping that and push it through all the places in the code that needs it. Since we no longer have a GtkSocket in the WebPluginDelegateImpl, we need to do a bit more work in the WebViewDelegate (aka the browser process in the multiproc world). We also need the plugin host (the browser) to track the GtkSockets that are hosting the plugin, as well as destroy them when necessary. To do this we require the plugin owner to grab the plug-removed signal rather than putting its handler in GtkPluginContainer; this is the way it worked before I'd refactored into GtkPluginContainer so it shouldn't be so bad. This change still only works in test_shell, but the refactoring should translate to the multiprocess case pretty easily. Review URL: http://codereview.chromium.org/146009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19320 0039d316-1c4b-4281-b951-d872f2087c98
* Add events to windowless plugins on linux. This CL also refactors the eventevan@chromium.org2009-05-221-8/+5
| | | | | | | | | | | | | communication between WebPlugin and WebPluginDelegate, to use a cross-platform message based on WebInputEvent. BUG=8202 TEST=A lot of manual testing on Linux and Windows, with Flash plugins and a custom plugin that dumps events on Linux. Review URL: http://codereview.chromium.org/115330 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16692 0039d316-1c4b-4281-b951-d872f2087c98
* Port plugin messages.jam@chromium.org2009-04-011-3/+4
| | | | | | Review URL: http://codereview.chromium.org/49050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12928 0039d316-1c4b-4281-b951-d872f2087c98
* Basic windowless plugins, try 2.evan@chromium.org2009-03-131-0/+2
| | | | | | | | | | | In response to Dean's comment on http://codereview.chromium.org/39105, I redid that patch to put the X munging into the plugin implementation. This won't work for multiproc, but it's near the correct place and many things will need to be changed for multiproc. Review URL: http://codereview.chromium.org/42056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11674 0039d316-1c4b-4281-b951-d872f2087c98
* Update PluginInstance to use the newer TLS APIs. This also removes a static ↵deanm@chromium.org2009-01-131-6/+0
| | | | | | | | | initializer. Review URL: http://codereview.chromium.org/17625 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7922 0039d316-1c4b-4281-b951-d872f2087c98
* Allow PDF files to open in Acrobat Reader. ananta@chromium.org2008-12-021-0/+5
| | | | | | | | | | | | | | | | | | This fixes http://code.google.com/p/chromium/issues/detail?id=3977, which is an issue with Acrobat Reader internet preferences being set to always open PDF files in Reader. This operation when performed in chrome and Safari brings up an error message from the Acrobat Reader plugin that the file could not be found. The plugin in this case returns NP_ASFILE as the plugin mode from NPP_NewStream. The data is written accordingly to the temp file created. When we finish receiving the data we pass the file name in NPP_StreamAsFile to the plugin. The plugin does not open the file immediately as per our expectation. It opens the file after the stream has been destroyed which ends up deleting the temp file created above. Debugged Firefox and found that it never deletes these temp files and leaves them around in the cache. We can go one step forward and track all these files on a per instance basis. These are deleted when the plugin instance is destroyed. Bug=3977 R=jam Review URL: http://codereview.chromium.org/12875 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6245 0039d316-1c4b-4281-b951-d872f2087c98
* Committing on behalf of knorton@google.comjam@chromium.org2008-11-191-1/+1
| | | | | | | | | | | Fixes a threading issue in PluginInstance. PluginThreadAsyncCall is supposed to provide a thread safe way of enqueing a callback onto the plugin thread. Currently, it unsafely adds a reference to the PluginInstance when the callback is enqueued. This patch converts PluginInstance from RefCounted to RefCountedThreadSafe. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5706 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes http://code.google.com/p/chromium/issues/detail?id=3585, which is ↵ananta@chromium.org2008-10-231-4/+0
| | | | | | | | | | an issue with videos on sites like thedailyshow.com not showing up in Chrome. We recently made a change to send out the plugin SRC as the referrer in requests initiated by plugins.We also use the GetURLNotify codepath for requests which are initiated by us when the plugin is instantiated. It looks like the other browsers don't do the same, and only use the SRC as the referer for explicit plugin requests.Based on a reply on the PluginFutures list we emulate this behavior, which is to default to the containing frame URL as the referer for requests not initiated by plugins. R=jam Review URL: http://codereview.chromium.org/7871 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3862 0039d316-1c4b-4281-b951-d872f2087c98
* - Lots of removed whitespace at the end of the lineerg@google.com2008-10-221-25/+33
| | | | | | | | | | | - ifdef out windows specific calls - fix simple compiler warnings Review URL: http://codereview.chromium.org/7886 Patch from icefox. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3794 0039d316-1c4b-4281-b951-d872f2087c98
* Fix painting problem with transparent plugins because plugins were ignoring ↵jam@chromium.org2008-10-011-9/+0
| | | | | | | | | | | | | | | 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
* This CB fixes the following issue1. ↵iyengar@google.com2008-09-191-1/+4
| | | | | | | | 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-29/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* TrackedObjects assumes you can use a "TLS slot" of -1 to indicate ↵evanm@google.com2008-08-201-1/+2
| | | | | | uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1122 0039d316-1c4b-4281-b951-d872f2087c98
* Revert. Failing unit tests.evanm@google.com2008-08-201-2/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1118 0039d316-1c4b-4281-b951-d872f2087c98
* TrackedObjects assumes you can use a "TLS slot" of -1 to indicate ↵evanm@google.com2008-08-201-1/+2
| | | | | | uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1113 0039d316-1c4b-4281-b951-d872f2087c98
* Add webkit to the repository.initial.commit2008-07-271-0/+288
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18 0039d316-1c4b-4281-b951-d872f2087c98