summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/webplugin_delegate_proxy.cc
Commit message (Collapse)AuthorAgeFilesLines
* Finish taking out render_messages.h includes from headers.jam@chromium.org2009-02-051-0/+1
| | | | | | Review URL: http://codereview.chromium.org/20072 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9209 0039d316-1c4b-4281-b951-d872f2087c98
* Commiting the changes from my previous cl that are specific to not including ↵jam@chromium.org2009-02-041-0/+1
| | | | | | | | | | render_messages.h/plugin_message.h unless necessary. TBR=mpcomplete Review URL: http://codereview.chromium.org/20059 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9189 0039d316-1c4b-4281-b951-d872f2087c98
* Revert my change to get the tree green. Not sure why the tests became ↵jam@chromium.org2009-02-041-1/+0
| | | | | | | | | | flaky. I'll try to check them in again but in smaller chunks tomorrow. TBR=mpcomplete Review URL: http://codereview.chromium.org/21039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9132 0039d316-1c4b-4281-b951-d872f2087c98
* Make it easier/less work/less error-prone to create new IPC channel types ↵jam@chromium.org2009-02-041-0/+1
| | | | | | | | (i.e. renderer/plugin).Instead of having each message file include the internal one several times with different ifdefs, move that logic to ipc_message_macros.h. Also make the message class starting IDs come from an enum to ensure we don't use a value twice. I simplified the logging code a bit so we don't need X_messages.cc files.Clean up places that we were doing manual packing/unpacking. Most of this was in the automation code. I added a few new template functions to make it convenient to read the parameters from a message, and updated the code to use them.I also removed unnecessary includes of render/plugin_messages.h from headers to speed up compiling.I moved the traits of IPC structs beside the struct definition to make it more apparent what's going on, so we avoid people modifying the struct and forgetting to update the traits.Amit: please look at chrome/test/automation/tab_proxy.ccMarc-Antoine: chrome/browser/printing/*Matt: the rest Review URL: http://codereview.chromium.org/20015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9123 0039d316-1c4b-4281-b951-d872f2087c98
* Maintain a local/global stack for the global WebPluginDelegateImpl instance ↵ananta@chromium.org2009-01-291-1/+7
| | | | | | | | | | | | | | | | | | | pointer. Based on the crash dump, the crash occurs in the windows message filter hook, used for tracking whether the plugin enters a modal loop. The global plugin instance pointer gets reset to NULL in the windowed plugin wndproc and HandleEvent. If these events occur in nested order, then it is quite possible for the plugin instance pointer to get set to NULL incorrectly. Added a check for whether this pointer is NULL in the message filter hook along with a NOTREACHED statement. We maintain a local global stack to ensure that the plugin instance pointer gets set/reset correctly. The bug is http://code.google.com/p/chromium/issues/detail?id=6703 The other issue being fixed is to set the modal_loop_pump_messages_event coming in from the plugin in WebPluginDelegateProxy correctly. This caused the plugin to not receive events when it enters a modal loop like a context menu. Bug=6703 Review URL: http://codereview.chromium.org/19444 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8914 0039d316-1c4b-4281-b951-d872f2087c98
* POSIX: gfx::NativeViewId and CrossProcessEventagl@chromium.org2009-01-271-1/+2
| | | | | | | | | | | | | | | | | | | 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
* Improve scrolling performance when there are many windowed plugins in a page.jam@chromium.org2009-01-161-9/+2
| | | | | | | | 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
* WaitableEvent is the replacement for Windows events. Previously in the code, ↵agl@chromium.org2009-01-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor resource_bundle into a _win file.evan@chromium.org2009-01-131-2/+2
| | | | | | | | | Linux changes forthcoming. Review URL: http://codereview.chromium.org/17472 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7914 0039d316-1c4b-4281-b951-d872f2087c98
* Move plugins to FilePaths, some cleanupavi@google.com2009-01-061-2/+3
| | | | | | Review URL: http://codereview.chromium.org/16456 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7588 0039d316-1c4b-4281-b951-d872f2087c98
* Make the global render thread object a regular global object rather than abrettw@google.com2008-12-181-4/+4
| | | | | | | | | | | special TLS value. This is slightly faster for this commonly-used function, and we don't ever have more than one (it's like this because we were originally planning on having more than one RenderThread). BUG=5635 Review URL: http://codereview.chromium.org/15052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7272 0039d316-1c4b-4281-b951-d872f2087c98
* Move the "platform" wrappers in skia/ext to the skia namespace.brettw@google.com2008-12-171-2/+2
| | | | | | Review URL: http://codereview.chromium.org/14110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7182 0039d316-1c4b-4281-b951-d872f2087c98
* Handle HTTP 200 responses received in response to byte range requests issued ↵ananta@chromium.org2008-12-171-1/+13
| | | | | | | | 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
* Cleanup, part 1.pkasting@chromium.org2008-12-081-1/+1
| | | | | | | | | | | | | | * Consistently use underscores between words in identifiers (IDC_NEWTAB -> IDC_NEW_TAB) * Make some identifiers clearer or more up-to-date (IDC_DUPLICATE -> IDC_DUPLICATE_TAB, IDC_GOOFFTHERECORD -> IDC_NEW_INCOGNITO_WINDOW, IDC_NEWPROFILEWINDOW -> IDC_PROFILE_MENU) * Try and make string identifiers (IDS_xxx) match their corresponding IDC_xxx commands. Tony tells me this will not cause any need for retranslation. * As much as possible (without modifying automated UI test XML files), use "Bookmark Bar", not "Bookmarks Bar" (this seemed to be prevailing usage in the code) * Fix 80-column issues This patch touches move files than any subsequent patches, but should be the most rubber-stampable. Review URL: http://codereview.chromium.org/13633 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6535 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing build bustage. Adding files which were part of the original changeananta@chromium.org2008-12-051-0/+5
| | | | | | | | | | 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-5/+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
* Fix the painting problem with Stree View and Flash 10. After the size of ↵jam@chromium.org2008-12-011-13/+7
| | | | | | | | | | | the plugin changes, we generate a new backing store. Flash 9 invalidates the rectangle, but Flash 10 doesn't. As a result we paint from a blank backing store. The fix is to keep track of which part of the backing store has been painted into by the plugin, and if the renderer tries to paint an area that falls outside of it, do a synchronous paint. Also get rid of first_paint_, as it was introduced during a failed attempt to make plugin loading asynchronous. Review URL: http://codereview.chromium.org/10792 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6128 0039d316-1c4b-4281-b951-d872f2087c98
* Add Terminate() to the Process object, have RenderProcessHost use this to ↵brettw@google.com2008-11-141-3/+3
| | | | | | | | | | 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
* Prevent crash due to DIB allocation failure joshia@google.com2008-11-121-4/+10
| | | | | | | | | | | | | Change the way we capture tab thumbnail images so that the capturing code can deal with failure. BUG=3795 Review URL: http://codereview.chromium.org/9717 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5244 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for crash in NPN_Invoke. This happened because the window script ↵jam@chromium.org2008-11-041-13/+15
| | | | | | | | | | NPObject was deallocated by the script controller but WebPluginDelegateProxy wasn't telling NPObjectStub that it's contained object was garbage soon enough. BUG=1036087 Review URL: http://codereview.chromium.org/9066 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4526 0039d316-1c4b-4281-b951-d872f2087c98
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-091-5/+9
| | | | | | | | | | | | | | | 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 painting problem with transparent plugins because plugins were ignoring ↵jam@chromium.org2008-10-011-66/+145
| | | | | | | | | | | | | | | 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
* Fix for windowed painting regression.jam@chromium.org2008-09-231-3/+3
| | | | | | Review URL: http://codereview.chromium.org/4221 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2499 0039d316-1c4b-4281-b951-d872f2087c98
* Desynchronize windowless plugin painting. This greatly improves the paintingjam@chromium.org2008-09-221-101/+78
| | | | | | | | 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-6/+21
| | | | | | | | 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
* This fixes http://b/issue?id=1303133, which was a crashiyengar@google.com2008-08-021-2/+1
| | | | | | | | | | | | in the renderer due to the plugin instance getting destroyed in the context of the ShowModalHTMLDialog request. The fix is to convert the WebPluginDelegateProxy object in a DeleteLater and to set its channel to NULL in the destructor. This ensures that the reply to the message can be sent out successfully. Bug=1303133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@286 0039d316-1c4b-4281-b951-d872f2087c98
* Add chrome to the repository.initial.commit2008-07-261-0/+696
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-20 12:01:21 +0000