summaryrefslogtreecommitdiffstats
path: root/webkit/glue/webplugin.h
Commit message (Collapse)AuthorAgeFilesLines
* Re-enable the build of Pepper support by default (issue 464074, svn revision ↵sehr@google.com2009-12-101-2/+2
| | | | | | | | | | | | | | | | | 34161). There were problems building Skia and others for the 64-bit linux versions of the Pepper test plugin, so I have disabled building that plugin except on Windows for now and added a TODO. One significant addition to the previous comment lines. The flag enable_gpu=1 now causes the build definition ENABLE_GPU=1 to allow guarding of dependent code. BUG=none TEST=none Review URL: http://codereview.chromium.org/481001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34227 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 34161 - Enable Pepper support by default, including building the test ↵sehr@google.com2009-12-091-2/+2
| | | | | | | | | | | | | | | | | | | | plugin. This is needed because the NaCl plugin code that runs in the renderer needs to use Pepper APIs all the time, and NaCl support has been enabled by default for several months now. To cause an untrusted Pepper plugin to run in the renderer one needs to specify the internalpepper flag. I have also removed the enable_pepper flag from gyp. As the build of the GPU process was tied to this flag, I have renamed the flag to enable_gpu. TEST=none BUG=none Review URL: http://codereview.chromium.org/464074 TBR=sehr@google.com Review URL: http://codereview.chromium.org/475004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34162 0039d316-1c4b-4281-b951-d872f2087c98
* Enable Pepper support by default, including building the test plugin.sehr@google.com2009-12-091-2/+2
| | | | | | | | | | | | | | | This is needed because the NaCl plugin code that runs in the renderer needs to use Pepper APIs all the time, and NaCl support has been enabled by default for several months now. To cause an untrusted Pepper plugin to run in the renderer one needs to specify the --internal-pepper flag. I have also removed the enable_pepper flag from gyp. As the build of the GPU process was tied to this flag, I have renamed the flag to enable_gpu. TEST=none BUG=none Review URL: http://codereview.chromium.org/464074 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34161 0039d316-1c4b-4281-b951-d872f2087c98
* Send resource load notifications from plugins to devtools agent. This is a ↵yurys@chromium.org2009-12-031-2/+3
| | | | | | | | | | part of a fix which would allow to inspect plugin resources. BUG=2084 Review URL: http://codereview.chromium.org/435044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33672 0039d316-1c4b-4281-b951-d872f2087c98
* Rename policy_url to first_party_for_cookies in cookie-related code.wtc@chromium.org2009-11-181-2/+2
| | | | | | | | | R=abarth BUG=25133 TEST=none. A cosmetic change. Review URL: http://codereview.chromium.org/403011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32373 0039d316-1c4b-4281-b951-d872f2087c98
* Moved Pepper delegate definition to chrome\renderer to allow it to usesehr@google.com2009-10-171-0/+6
| | | | | | | | | | | code from chrome\common. Also added canvas support and hooked up NPAPI interface functions. No tests have been added yet, so this is probably not fully ready. Review URL: http://codereview.chromium.org/291001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29380 0039d316-1c4b-4281-b951-d872f2087c98
* Move native_widget_types and gtk_native_view_id_manager from base/gfx tobrettw@chromium.org2009-10-111-1/+1
| | | | | | | | | | | | app/gfx in preparation for removing the base_gfx project. This also moves base/window_impl.cc to app/win/window_impl because this file shouldn't be in base. TEST=none BUG=none Review URL: http://codereview.chromium.org/273017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28691 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate remaining WebCore dependencies from webplugin_impl.ccdarin@chromium.org2009-09-021-19/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduces WebPluginPageDelegate to hold the methods that only existed on WebViewDelegate to allow WebPluginImpl to talk to the RenderView. This enables us to eliminate those methods from WebViewDelegate, which eliminates the last dependency on gfx/ native_widget_types.h in our WebKit interface! WebViewDelegate grows a CreatePlugin method that returns a WebKit::WebPlugin. It loses its CreatePluginDelegate method, which now lives on WebPluginPageDelegate. This change makes RenderView use WeakPtr when it hands itself to each WebPluginDelegateProxy and WebPluginImpl instance. This makes the memory management simpler. This change also moves various WebPlugin* interfaces defined in webkit/glue into the webkit_glue namespace. This was to help reduce confusion with similarly named types in the WebKit namespace. WebKit::WebPluginParams is added to contain the set of parameters used to construct a plugin. WebPluginContainer gets a couple more methods to allow us to avoid WebCore dependencies in WebPluginImpl. R=jam BUG=10036 TEST=none Review URL: http://codereview.chromium.org/181014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25184 0039d316-1c4b-4281-b951-d872f2087c98
* linux: new socket/plug code for windowed pluginspiman@chromium.org2009-08-251-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | This CL reworks the GtkSocket/GtkPlug code for windowed plugins on linux. Instead of having the plugin ask the browser to create a socket to plug into, it simply creates a plug and sends it to the browser. The browser creates a socket and attaches the plug when the socket becomes realized This fixes 2 main issues: - we can create windowed plugins in background tabs (Issue 16125) - we can detach tabs with windowed plugins and reattach them (Issue 17110) I reworked the IPCs, so it removes some amount of linux-specific things. We also need less synchronous IPCs to create/destroy plugins, so that should be a bit faster. In particular, I removed the plugin pid map, and instead made sure the renderer always destroys the plugin containers if the plugin process crashes - they will be destroyed if the renderer process crashes. Let me know if you have an issue with that. Also, the intermediate plug/socket creation now happens in webplugin_delegate_impl_gtk. That means test_shell uses it as well. It made the code a lot simpler, and means we're testing it as well, albeit with a bit of extra overhead. Bonus: I found a big bad bug in the GtkPluginContainer that made its width/height alias with some internal gtk structures. That was certainly causing some amounts of bugs. Bonus 2: scrolling now looks more in sync with the rest of the page, though I'm not exactly sure which part caused that. BUG=16125,17110 TEST=a lot of manual testing involving YouTube videos Review URL: http://codereview.chromium.org/174295 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24309 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to WebFrame from the WebKit API.darin@chromium.org2009-08-101-1/+0
| | | | | | | | | | | | | | | I tried to avoid unnecessary changes in this CL to help make it easier to review. As part of this CL, glue/webtextinput* are folded into WebFrame / WebFrameImpl. R=dglazkov BUG=10034 TEST=none Review URL: http://codereview.chromium.org/164225 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22896 0039d316-1c4b-4281-b951-d872f2087c98
* Another attempt at landing this patch.ananta@chromium.org2009-08-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The reliability tests regressions caused by this patch have been addressed by the upstream bug fix https://bugs.webkit.org/show_bug.cgi?id=27769 The IPCs for carrying data requested by plugins have been changed from synchronous IPCs to asynchronous IPCs. This fixes bug http://code.google.com/p/chromium/issues/detail?id=14323, where the Flash plugin would not render content on the page if these IPCs were processed while the plugin waited for sync calls like NPN_Evaluate to return. This CL also fixes the following bugs, which were crashes in reliability test runs when this patch was landed last time. http://code.google.com/p/chromium/issues/detail?id=18058 http://code.google.com/p/chromium/issues/detail?id=18059 The crash happens because of NPP_Write calls issued to the plugin while it is waiting for an NPN_Invoke call to return in the context of NPP_NewStream. Inspecting the safari plugin implementation revealed that they defer the resource load before calling the plugin and restore it on return. We emulate this behavior via an IPC sent from the plugin which serves as an acknowledgement. Test=covered by UI tests. Bug=14323,18058,18059 Review URL: http://codereview.chromium.org/159746 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22369 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 22041 as it caused plugin crashes in reliability test runs.ananta@chromium.org2009-07-301-1/+2
| | | | | | | | | | Also reverting 22065/22046/22041 which are changes to knowncrashes.txt. TBR=huanr Review URL: http://codereview.chromium.org/160418 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22109 0039d316-1c4b-4281-b951-d872f2087c98
* Another attempt at landing this patch. ananta@chromium.org2009-07-301-2/+1
| | | | | | | | | | | | | | | | | | | | | | The reliability tests regressions caused by this patch have been addressed by the upstream bug fix https://bugs.webkit.org/show_bug.cgi?id=27769 The IPCs for carrying data requested by plugins have been changed from synchronous IPCs to asynchronous IPCs. This fixes bug http://code.google.com/p/chromium/issues/detail?id=14323, where the Flash plugin would not render content on the page if these IPCs were processed while the plugin waited for sync calls like NPN_Evaluate to return. Test=covered by UI tests. Bug=14323 Review URL: http://codereview.chromium.org/160338 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22041 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r21548 and r21559 due to crash spike.huanr@chromium.org2009-07-251-1/+2
| | | | | | Review URL: http://codereview.chromium.org/159383 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21614 0039d316-1c4b-4281-b951-d872f2087c98
* The IPCs for carrying data requested by plugins have been changed from ↵ananta@chromium.org2009-07-241-2/+1
| | | | | | | | | | | | | | | | synchronous IPCs to asynchronous IPCs. This fixes bug http://code.google.com/p/chromium/issues/detail?id=14323, where the Flash plugin would not render content on the page if these IPCs were processed while the plugin waited for sync calls like NPN_Evaluate to return. Test=covered by UI tests. Bug=14323 Review URL: http://codereview.chromium.org/159296 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21548 0039d316-1c4b-4281-b951-d872f2087c98
* linux: only create browser-side plugin container after plugin requests itevan@chromium.org2009-06-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | On Windows, windowed plugins are parented in a two-stage process: initially, the plugin is parented to the render view, then later it's reparented to a special per-plugin window. On Linux, plugin embedding always needs a special per-plugin window before it can be initialized. So there's no way to do the two-stage initialization process, and we only want to construct the browser-side plugin container for windowed plugins after the plugin requests it. Plumbing this through the WebPlugin interface will also allow us to side-route this request for window creation out to the browser process in the multi-process case. BUG=15421 TEST=plugins still work in test_shell Review URL: http://codereview.chromium.org/150034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19602 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 19560. This caused a bunch of plugin-related unittest failures on ↵glen@chromium.org2009-06-301-7/+0
| | | | | | | | Windows. Review URL: http://codereview.chromium.org/150088 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19573 0039d316-1c4b-4281-b951-d872f2087c98
* linux: only create browser-side plugin container after plugin requests itevan@chromium.org2009-06-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | On Windows, windowed plugins are parented in a two-stage process: initially, the plugin is parented to the render view, then later it's reparented to a special per-plugin window. On Linux, plugin embedding always needs a special per-plugin window before it can be initialized. So there's no way to do the two-stage initialization process, and we only want to construct the browser-side plugin container for windowed plugins after the plugin requests it. Plumbing this through the WebPlugin interface will also allow us to side-route this request for window creation out to the browser process in the multi-process case. BUG=15421 TEST=plugins still work in test_shell Review URL: http://codereview.chromium.org/150034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19560 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
* Don't call NPP_SetWindow before we have the plugin geometry.jam@chromium.org2009-06-091-0/+1
| | | | | | | | | Note: the full fix to the bug also needs Ananta's change at http://codereview.chromium.org/119200 Bug=12993 Review URL: http://codereview.chromium.org/118359 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17920 0039d316-1c4b-4281-b951-d872f2087c98
* Header cleanup in webkit/gluephajdan.jr@chromium.org2009-06-011-1/+0
| | | | | | | | | - reduce header dependencies - remove redundant forward declarations Review URL: http://codereview.chromium.org/115871 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17313 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure that seekable streams are removed from the list of resource ↵ananta@chromium.org2009-05-231-0/+4
| | | | | | | | | | | | | | | | | | | | 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
* Chrome side of using WebPluginListBuilder.darin@chromium.org2009-04-241-32/+0
| | | | | | | | | | | | | | I also broke glue/webplugininfo.h out of glue/webplugin.h as part of this change. Eventually, glue/webplugin.h will go away and be moved into the WebKit API, but the structures left in glue/webplugininfo.h need to remain since they are used extensively throughout Chrome. BUG=10922 R=dglazkov Review URL: http://codereview.chromium.org/93116 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14438 0039d316-1c4b-4281-b951-d872f2087c98
* Fix hang seen in plugin process because plugin creation ended up having to ↵jam@chromium.org2009-04-211-4/+5
| | | | | | | | | | 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
* Port plugin messages.jam@chromium.org2009-04-011-8/+10
| | | | | | Review URL: http://codereview.chromium.org/49050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12928 0039d316-1c4b-4281-b951-d872f2087c98
* Expose whether we're in private browsing mode to plugins.I chose to ↵jam@chromium.org2009-03-261-0/+3
| | | | | | | | | 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/+4
| | | | | | | | | | . 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
* Checkin files I missed.jam@chromium.org2009-03-131-3/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11602 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGEdeanm@chromium.org2009-03-111-1/+0
| | | | | | | | | Normalize end of file newlines in webkit/. All files end in a single newline. Review URL: http://codereview.chromium.org/42070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11443 0039d316-1c4b-4281-b951-d872f2087c98
* 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-02-10 06:31:58 +0000