summaryrefslogtreecommitdiffstats
path: root/webkit/glue/webplugin_impl.cc
Commit message (Collapse)AuthorAgeFilesLines
* Reverting 20855.darin@chromium.org2009-07-161-2/+2
| | | | | | Review URL: http://codereview.chromium.org/149744 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20859 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 20854.darin@chromium.org2009-07-161-2/+2
| | | | | | Review URL: http://codereview.chromium.org/155621 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20855 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebWidget from the WebKit API. This change also makesdarin@chromium.org2009-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use of WebKitClient (replacing WebWidgetDelegate from glue). The ripple effects of this change are rather large, but most of the impact is mechanical. The more interesting changes include: 1- Removing the WebWidget parameter from WebWidgetClient methods. This didn't matter at all to RenderWidget or RenderView, but it did cause some changes to be made to TestWebViewDelegate. Now, it is not possible to share a delegate implementation for both the WebView and a popup menu, so I have a second instance of the delegate owned by TestShell for use with popup menus. 2- Plumbing WebNavigationPolicy in place of WindowOpenDisposition was getting to be a pretty large change, so I stopped short of deleting WindowOpenDisposition. That way the Chrome side can remain mostly unmodified. I then added a mapping function to convert from WebNavigationPolicy to WindowOpenDisposition. 3- The IME methods on WebWidget were renamed (reviewed separately by hbono), and there is now an enum to specify the composition command (WebCompositionCommand). 4- I added IPC serialization for WebCompositionCommand and WebTextDirection, which cleaned up some code that was just using ints in IPC messages. R=jam BUG=16234 TEST=none Review URL: http://codereview.chromium.org/149620 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20854 0039d316-1c4b-4281-b951-d872f2087c98
* 1) Roll WebKit DEPS to 45685michaeln@google.com2009-07-101-3/+3
| | | | | | | | | | | This roll picks up changes to WebCore::Widget which make that a RefCounted class. 2) Mods to plugin handling in our "glue" needed to recover from the above Review URL: http://codereview.chromium.org/149443 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20440 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebCursorInfo from the WebKit API. WebCursorInfo is adarin@google.com2009-07-081-7/+7
| | | | | | | | | | | | | | | | lightweight struct containing a description of a cursor that the embedder should render. WebCursor still exists. Instead of WebCursor initializing from a PlatformCursor, it now initializes from a WebCursorInfo. TEST=none BUG=10039 R=jam Review URL: http://codereview.chromium.org/155172 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20194 0039d316-1c4b-4281-b951-d872f2087c98
* linux: only create browser-side plugin container after plugin requests itevan@chromium.org2009-06-301-0/+11
| | | | | | | | | | | | | | | | | | | | | | 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-11/+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/+11
| | | | | | | | | | | | | | | | | | | | | | 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: cleanup browser-side GtkSockets when plugins are destroyedevan@chromium.org2009-06-281-0/+9
| | | | | | | | | | | | WillDestroyWindow is already plumbed over to the browser process in the multiproc case; we want to plumb it to our RenderView delegate so we can do similar cleanup in test_shell. BUG=15423 Review URL: http://codereview.chromium.org/147251 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19475 0039d316-1c4b-4281-b951-d872f2087c98
* linux plugins: eliminate GtkWidget* from plugin processevan@chromium.org2009-06-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [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-1/+1
| | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix for the Layout test failures occuring as a result of the change to ↵ananta@chromium.org2009-06-101-0/+1
| | | | | | | | | | | | | | | | download the plugin src URL in a background task. The tests fail because the plugin instance is torn down before the task executes. The fix is to revoke tasks executing on the current WebPluginImpl instance when it is torn down. TBR=jam Bug=12993 Review URL: http://codereview.chromium.org/119410 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18035 0039d316-1c4b-4281-b951-d872f2087c98
* For lack of a better approach we now initiate the plugin src url download in ↵ananta@chromium.org2009-06-101-4/+17
| | | | | | | | | | | | | a delayed task as the Flash plugin hangs if it starts receiving data before receiving valid plugin geometry. This fixes bug http://code.google.com/p/chromium/issues/detail?id=12993 Bug=12993 TEST=Navigate to google.com/finance and open the tickers in background tabs. They should not cause the browser to hang. Review URL: http://codereview.chromium.org/118452 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18033 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebURLLoader, et. al. from the WebKit API.darin@chromium.org2009-06-091-123/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | Moves our ResourceHandle to webkit/api/src/ResourceHandle.cpp from webkit/glue/resource_handle_impl.cc. A portion of resource_handle_impl.cc was moved into weburlloader_impl.{h,cc}, which now contains our implementation of WebURLLoader. The annoying parts of this CL involve WebPluginImpl. I had to convert it over to using WebURLLoader instead of ResourceHandle so that MultipartResourceDelegate can be shared. There is some complexity in WebURLRequest / WebURLResponse to make it cheap to wrap a ResourceRequest / ResourceResponse. I think this is worth it since there is a lot of conversion between the two types. Originally reviewed here: http://codereview.chromium.org/113928 BUG=10038 TEST=covered by existing tests R=dglazkov Review URL: http://codereview.chromium.org/118438 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17962 0039d316-1c4b-4281-b951-d872f2087c98
* Fix regression from my previous change. Looks like we need to call ↵jam@chromium.org2009-06-091-0/+11
| | | | | | | | | | | | SetWindowPos in setParent for the sake of layout tests. TBR=ananta Bug=12993 Review URL: http://codereview.chromium.org/119344 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17928 0039d316-1c4b-4281-b951-d872f2087c98
* Don't call NPP_SetWindow before we have the plugin geometry.jam@chromium.org2009-06-091-29/+28
| | | | | | | | | 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
* Fixes a flash plugin hang caused by opening google finance ticker symbols in ↵ananta@chromium.org2009-06-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a background tab. From what I can tell this bug always existed in Chrome. The flash plugin gets instantiated and gets initial geometry updates during initialization. We download the plugin url after the geometry update. After these geometry updates the webkit layout timer runs and the plugin gets additional geometry updates. However these don't get sent over to the flash plugin instance in the plugin process as the geometry updates for windowed plugins are only flushed during paint, which does not happen in this case. The flash plugin ends up receiving data before geometry update and ends up behaving in a wierd fashion, i.e. not peeking for messages, etc. The fact that this is a windowed plugin results in the browser ui thread also getting hung until the plugin gets out of this state. The fix for the geometry update issue is to remove the deferred geometry update stuff. This only exists for windowed plugins anyway. The geometry update IPC is a plain routed message and it should not be a big overhead to send these IPCs to the plugin process. I found that while this change fixes the basic issue, we still see some hangs in the flash plugin because of it receiving data before the valid geometry update kicks in. John is working on a fix where we never have to call setFrameRect ourselves and always honor the setFrameRect calls made by Webkit. This issue can be marked as fixed once both fixes get checked in. This fixes http://code.google.com/p/chromium/issues/detail?id=12993 Bug=12993 TEST=Open google finance and Ctrl Click on the tickers in the page like Basic Materials, etc. Review URL: http://codereview.chromium.org/119200 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17918 0039d316-1c4b-4281-b951-d872f2087c98
* Header cleanup in webkit/gluephajdan.jr@chromium.org2009-06-011-0/+1
| | | | | | | | | - 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
* Revert WebURLLoader landing. Too many layout test failures.darin@chromium.org2009-05-301-165/+123
| | | | | | | | TBR=dglazkov Review URL: http://codereview.chromium.org/115973 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17293 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebURLLoader, et. al. from the WebKit API.darin@chromium.org2009-05-301-123/+165
| | | | | | | | | | | | | | | | | | | | | | | | Moves our ResourceHandle to webkit/api/src/ResourceHandle.cpp from webkit/glue/resource_handle_impl.cc. A portion of resource_handle_impl.cc was moved into weburlloader_impl.{h,cc}, which now contains our implementation of WebURLLoader. The annoying parts of this CL involve WebPluginImpl. I had to convert it over to using WebURLLoader instead of ResourceHandle so that MultipartResourceDelegate can be shared. There is some complexity in WebURLRequest / WebURLResponse to make it cheap to wrap a ResourceRequest / ResourceResponse. I think this is worth it since there is a lot of conversion between the two types. BUG=10038 TEST=covered by existing tests R=dglazkov Review URL: http://codereview.chromium.org/113928 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17290 0039d316-1c4b-4281-b951-d872f2087c98
* Add events to windowless plugins on linux. This CL also refactors the eventevan@chromium.org2009-05-221-87/+17
| | | | | | | | | | | | | 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
* Move WebKit API to src/webkit/api.darin@chromium.org2009-05-101-4/+4
| | | | | | | | R=dglazkov Review URL: http://codereview.chromium.org/113186 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15739 0039d316-1c4b-4281-b951-d872f2087c98
* Fix plugin window sticking around when parent became invisible. Added test ↵jam@chromium.org2009-05-101-20/+14
| | | | | | | | | | | | for all different scenarios. Note I grabbed the plugin hwnd and manually checked it instead of looking for callbacks from the plugin's SetWindow since the latter isn't called if the visibility changes. BUG=1842096 TEST=regression test included, test http://chromedashboard per bug Review URL: http://codereview.chromium.org/115169 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15732 0039d316-1c4b-4281-b951-d872f2087c98
* There are cases where a Frame may outlive its associated Page. Get thedarin@chromium.org2009-05-061-2/+2
| | | | | | | | | | | | | | | | WebViewImpl by accessing it indirectly through the Frame's Page so that we don't have to worry about cleaning up the WebFrameImpl -> WebViewImpl pointer. WebCore already clears the Frame's Page pointer when the Page is destroyed by the WebViewImpl. Patch by Marshall Greenblatt R=darin Review: http://codereview.chromium.org/99283 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15458 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Flash window in Analytics being incorrectly visible.jam@chromium.org2009-05-051-4/+10
| | | | | | | | | | The bug was that we accidentally marked a plugin widget as visible if it's parent was visible, even if it was explicitly set as hidden. BUG=8927 TEST=regression test included, also can verify that analytics doesn't display the gray rectangle per the bug Review URL: http://codereview.chromium.org/106008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15285 0039d316-1c4b-4281-b951-d872f2087c98
* plugins: Some obvious ifdef removals (code that previously wouldn't link).evan@chromium.org2009-04-281-6/+0
| | | | | | Review URL: http://codereview.chromium.org/100118 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14773 0039d316-1c4b-4281-b951-d872f2087c98
* More linux ifdef tweaks. This reverts my earlier change (13503).sky@chromium.org2009-04-271-5/+2
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/100046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14628 0039d316-1c4b-4281-b951-d872f2087c98
* linux (and some posix): multiprocess plugins compiling.evan@chromium.org2009-04-231-0/+2
| | | | | | | | | | | | | | | | | | | 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
* Use the boundary_pos parameter passed to the ↵ananta@chromium.org2009-04-221-4/+3
| | | | | | | | | | | | MultiPartResponseClient::didReceiveData function as the length of the data. At times HTTP byte range requests return responses which specify invalid content ranges as per the spec, i.e. the last byte position is smaller than the first byte position, etc. I looked into Firefox's byte range parsing code and it always calculates the length based on the boundary position. This fixes bug http://code.google.com/p/chromium/issues/detail?id=8802 Bug=8802 Review URL: http://codereview.chromium.org/87063 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14266 0039d316-1c4b-4281-b951-d872f2087c98
* Fix hang seen in plugin process because plugin creation ended up having to ↵jam@chromium.org2009-04-211-3/+1
| | | | | | | | | | 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
* Ensure we check the page pointer before using it after we come out of ↵jam@chromium.org2009-04-161-2/+5
| | | | | | | | | | NPP_HandleEvent, as it might have gone away depending on JavaScript that was executed by the plugin. BUG=9955 Review URL: http://codereview.chromium.org/75026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13858 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a painting problem observed with windowless flash plugins, when they are ↵ananta@chromium.org2009-04-161-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | initially created with a zero clip rect, which eventually changes to a non zero clip rect. We don't send over geometry updates to the plugin if the window dimensions don't change, which is true in this case. This causes the plugin process to not send over paints to the renderer process as the plugin clip rect remains zero. The fix based on a discussion with John is to remove the check for whether the plugin dimensions changed and always send over the update geometry IPC to the plugin, where we do check whether these rects changed before calling the underlying plugin. This fixes bug http://code.google.com/p/chromium/issues/detail?id=10536 I am trying to come up with a unit test for this case. Will add it to this CB or submit those as a separate CB. Bug=10536 Review URL: http://codereview.chromium.org/73071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13822 0039d316-1c4b-4281-b951-d872f2087c98
* linux: make windowless plugins work again after r12179 regressed it.evan@chromium.org2009-04-151-2/+4
| | | | | | | | | | | | | | | | | r12179 makes painting always call DidMove(), even when the plugin hasn't moved, in case the cutout rects need to change. DidMove() on Linux test_shell causes the window to invalidate, causing an endless cycle of repaints. r12179: http://src.chromium.org/viewvc/chrome?view=rev&revision=12179 This code will be very different in the real multiproc case, so this is just the minimal change to make test_shell work again. BUG=10059 Review URL: http://codereview.chromium.org/67147 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13804 0039d316-1c4b-4281-b951-d872f2087c98
* Adds some ifdefs so that test_shell can be compiled on linuxsky@chromium.org2009-04-101-2/+5
| | | | | | | | | | | | | without GTK. I had to recreate this patch as my workspace for various resonds. UGH! BUG=none TEST=none Review URL: http://codereview.chromium.org/67024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13503 0039d316-1c4b-4281-b951-d872f2087c98
* WebKit merge 42132:42199 (Chrome side)darin@chromium.org2009-04-031-3/+4
| | | | | | | | | | Account for a FrameLoader method that was renamed. R=amanda Review URL: http://codereview.chromium.org/62011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13095 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-11/+9
| | | | | | Review URL: http://codereview.chromium.org/49050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12928 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
* The street view in Google maps, which is implemented with a windowed flash ↵ananta@chromium.org2009-03-201-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | plugin would draw over the iframe DOM element, effectively hiding it. This is handled by our IFrame shim geometry calculation, where we subtract the rect of any IFrame above the plugin in the ZOrder from the plugin rect. Webkit calls Widget::setFrameRect at various times, during layout/size changes/paints, etc. The reason this bug showed up, was due to an optimization in our setFrameRect implementation, where we would bail out if the rect passed in was the same size as the current plugin rect. Basically the IFrame appears above the plugin in the ZOrder much later, which causes us to return without sending over the cutout rects to the browser when it moves the plugin windows. Fix is to move the rects equality check to WebPluginImpl::setFrameRect, where we don't send over the UpdateGeometry IPC to the plugin process if the rects are the same. WebPluginImpl used to implement the webkit Widget interface a long time ago. This is no longer the case. So some of the functions don't need to be virtual anymore. I also made this change. This fixes bug http://b/issue?id=1722236 and http://code.google.com/p/chromium/issues/detail?id=8858 Bug=1722236,8858 Review URL: http://codereview.chromium.org/42413 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12179 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome-side of moving webkit/glue/cache_manager.{h,cc} to the WebKit API layer.darin@chromium.org2009-03-191-12/+5
| | | | | | | | | | | | | | This also includes a change to not have third_party/WebKit/WebKit/chromium/public in the global include path. Most of the code changes pertain to this. I also took this opportunity to do some renaming: browser/cache_manager_host -> browser/renderer_host/web_cache_manager R=brettw Review URL: http://codereview.chromium.org/42194 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12085 0039d316-1c4b-4281-b951-d872f2087c98
* Get rid of stashing a frame pointer with ResourceRequest and just store the ↵jam@chromium.org2009-03-161-4/+8
| | | | | | | | routing id directly. This simplifies the renderer code and also allow this code to be used in worker processes, where we don't have a frame. Review URL: http://codereview.chromium.org/46026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11763 0039d316-1c4b-4281-b951-d872f2087c98
* Basic windowless plugins, try 2.evan@chromium.org2009-03-131-6/+3
| | | | | | | | | | | 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
* Bring back overriding setParentVisible, since it's needed when a page ↵jam@chromium.org2009-03-121-0/+13
| | | | | | | | | scripts the parent element to make it invisible/visible. BUG=8657 Review URL: http://codereview.chromium.org/45005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11508 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome side to pick up new WebKit API changes.darin@chromium.org2009-02-281-2/+8
| | | | | | | | | | | | | | | | | | | | | WebKit API now provides: - layoutTestMode - support for registering extra local URL schemes - access to the current WebKitClient WebKitClient was extended to include: - access to the default locale - access to the current time - methods to start/stop the shared timer - method to get work scheduled on the main thread - methods to access cookies - method to prefetch hostnames R=dglazkov Review URL: http://codereview.chromium.org/27276 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10665 0039d316-1c4b-4281-b951-d872f2087c98
* Fix incorrect map usage in the WebPluginImpl::didReceiveData function, which ↵ananta@chromium.org2009-02-261-3/+5
| | | | | | | | | | | | | | | | | | caused a response to be incorrectly treated as a multipart response. This would eventually end up sending the ViewHostMsg_DidStopLoading IPC to the browser, which would treat the page as loaded, when it has not. This fixes http://code.google.com/p/chromium/issues/detail?id=7916, which would cause the favicon to not show up on trunk. Bug=7916 Review URL: http://codereview.chromium.org/28199 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10499 0039d316-1c4b-4281-b951-d872f2087c98
* Match the Windows plugin moving/sizing behavior on Linux.deanm@chromium.org2009-02-151-2/+0
| | | | | | | | | | | | | This keep the sizing operations in WebPluginDelegateImpl, and does the moving in DidMove. This more or less matches what currently happens on Windows. Add a comment explaining this situation better. Add some random comments and small code cleanup. Remove the flash useragent spoofing hack on non-Windows, we don't need to worry about this for now. Review URL: http://codereview.chromium.org/20304 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9843 0039d316-1c4b-4281-b951-d872f2087c98
* Call the DidStartLoading/DidStopLoading methods on the WebViewDelegate ↵ananta@chromium.org2009-02-131-0/+6
| | | | | | | | | | | | | | | | interface whenever we receive the initial response for a byte range request and when the request eventually completes. This ensures that the throbber continues to spin when these requests take a while. It stops spinning during load when the document load is cancelled by the plugin process. This occurs when the plugin invokes NPN_RequestRead the first time on the stream. This fixes http://code.google.com/p/chromium/issues/detail?id=7375 Bug=7375 Review URL: http://codereview.chromium.org/20333 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9732 0039d316-1c4b-4281-b951-d872f2087c98
* Checkpoint of plugin support code for Mac. Does not work yet; being checkedamanda@chromium.org2009-02-111-6/+10
| | | | | | | | in to help stay in sync with linux plugin mods and ensure that it doesn't break Windows plugins. Review URL: http://codereview.chromium.org/21095 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9558 0039d316-1c4b-4281-b951-d872f2087c98
* Check for a NULL WebPluginDelegate pointer in ↵ananta@chromium.org2009-02-051-4/+6
| | | | | | | | | | | | WebPluginImpl::TearDownPluginInstance. This function gets called during plugin destruction and during plugin reinitialization. It looks like this crash occurs when the reinitialization fails and the plugin widget is being destroyed. This fixes http://code.google.com/p/chromium/issues/detail?id=7405 Review URL: http://codereview.chromium.org/21069 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9206 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-01 10:45:15 +0000