summaryrefslogtreecommitdiffstats
path: root/webkit/glue/webplugin_impl.cc
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Get windowed plugins (Flash) limping along on Linux.evan@chromium.org2009-02-041-5/+6
| | | | | | | | | | | We still crash when you navigate away from the page. (PS: the plan is to unfork the _gtk.cc file once it gets closer to what we want, so you don't need to look at that too closely. I just wanted to check in what I have since it's getting big.) Review URL: http://codereview.chromium.org/19413 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9170 0039d316-1c4b-4281-b951-d872f2087c98
* WebKit merge 40474:40500 [chromium-side].ericroman@google.com2009-02-041-9/+4
| | | | | | Review URL: http://codereview.chromium.org/21029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9121 0039d316-1c4b-4281-b951-d872f2087c98
* WebKitMerge 40409:40464 (chromium-side).ericroman@google.com2009-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * The death of FrameLoaderClient.cpp correspond with <http://trac.webkit.org/changeset/40435> * The custom V8 binding for V8HTMLFormElement::submit() corresponds with <http://trac.webkit.org/changeset/40424> * Changes to FrameLoader::loadFrameRequestWithFormAndValues() and FrameLoadTypeRedirectWithLockedHistory correspond with <http://trac.webkit.org/changeset/40432> * No action was taken for the disable-web-security change <http://trac.webkit.org/changeset/40449>, defaults to enabled. * Frame::isFrameSet() moving to Document::isFrameSet corresponds with <http://trac.webkit.org/changeset/40443> * Frame::sendResizeEvent() moved to EventHandler::sendResizeEvent() <http://trac.webkit.org/changeset/40444> * Not sure which webkit change added RenderObjectChildList.cpp. ======================= Rebaselined the following layout tests to reflect upstream changes: ======================= * LayoutTests/fast/table/form-with-table-style.html http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/table/form-with-table-style-expected.png?rev=40457 * LayoutTests/fast/table/insert-row-before-form.html http://trac.webkit.org/changeset/40456/trunk/LayoutTests/platform/mac/fast/table/insert-row-before-form-expected.txt?old=30635&old_path=trunk/LayoutTests/platform/mac/fast/table/insert-row-before-form-expected.txt * LayoutTests/tables/mozilla/bugs/bug4527.html http://trac.webkit.org/changeset/40458/trunk/LayoutTests/platform/mac/tables/mozilla/bugs/bug4527-expected.txt?old=30635&old_path=trunk/LayoutTests/platform/mac/tables/mozilla/bugs/bug4527-expected.txt * LayoutTests/tables/mozilla/bugs/bug96343.html http://trac.webkit.org/changeset/40458/trunk/LayoutTests/platform/mac/tables/mozilla/bugs/bug96343-expected.txt?old=30635&old_path=trunk/LayoutTests/platform/mac/tables/mozilla/bugs/bug96343-expected.txt * LayoutTests/tables/mozilla_expected_failures/bugs/bug1725.html http://trac.webkit.org/changeset/40459/trunk/LayoutTests/platform/mac/tables/mozilla_expected_failures/bugs/bug1725-expected.txt?old=30635&old_path=trunk/LayoutTests/platform/mac/tables/mozilla_expected_failures/bugs/bug1725-expected.txt * LayoutTests/tables/mozilla_expected_failures/other/test4.html http://trac.webkit.org/changeset/40460/trunk/LayoutTests/platform/mac/tables/mozilla_expected_failures/other/test4-expected.txt?old=34683&old_path=trunk/LayoutTests/platform/mac/tables/mozilla_expected_failures/other/test4-expected.txt * LayoutTests/editing/deleting/deletionUI-single-instance-actual.png http://trac.webkit.org/changeset/40454/trunk/LayoutTests/platform/mac/editing/deleting/deletionUI-single-instance-expected.txt?old=32226&old_path=trunk/LayoutTests/platform/mac/editing/deleting/deletionUI-single-instance-expected.txt Review URL: http://codereview.chromium.org/21007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9077 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome side of WebKit Merge 40165:40297playmobil@google.com2009-01-281-1/+1
| | | | | | Review URL: http://codereview.chromium.org/19603 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8776 0039d316-1c4b-4281-b951-d872f2087c98
* Adobe Reader 7 expects the load_manually flag to be set when being ↵ananta@chromium.org2009-01-271-4/+5
| | | | | | | | | | | | | | | | | | | | | instantiated. This only causes an issue when we reinitialize the plugin when we receive a HTTP 200 response for a byte range request. We were setting the load_manually flag to false as we would be handing off the data to the plugin. However Reader 7 puts up a message box in its NPP_New call indicating that the operation failed. It then returns an error which causes the renderer to crash as we dereference a NULL plugin delegate pointer. We also force an invalidate when the plugin is reinitialized as the page does not paint at times. The other fix is to pass down the plugin mime type correctly to WebPluginImpl. This fixes http://code.google.com/p/chromium/issues/detail?id=6318 Bug=6318 Review URL: http://codereview.chromium.org/18831 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8765 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
* No functional change. Delete trailing whitespace and word-wrap to 80 columns.evan@chromium.org2009-01-241-9/+10
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8609 0039d316-1c4b-4281-b951-d872f2087c98
* Relands 8521, it isn't the culprit. Sorry John.sky@google.com2009-01-231-13/+0
| | | | | | | | | BUG=none TEST=none TBR=jam Review URL: http://codereview.chromium.org/18706 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8547 0039d316-1c4b-4281-b951-d872f2087c98
* Backs out r8521 in hopes of greener trees.sky@google.com2009-01-231-0/+13
| | | | | | | | | BUG=none TEST=none TBR=jam Review URL: http://codereview.chromium.org/18545 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8546 0039d316-1c4b-4281-b951-d872f2087c98
* Fix reloading a page with a pdf not working. The problem was that we were ↵jam@chromium.org2009-01-221-13/+0
| | | | | | | | sending an invalid window to DeferWindowPos (the previous window as it's going away). But we didn't really need to override setParentVisible since overriding setParent is enough. Review URL: http://codereview.chromium.org/18519 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8521 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome side of webkit merge to 40124.tc@google.com2009-01-221-1/+3
| | | | | | | | | | | | Not much here other than CanvasPixelArray being re-added in webkit@r40089. Changes: http://trac.webkit.org/changeset?new=40124@trunk&old=40086@trunk Review URL: http://codereview.chromium.org/16617 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8520 0039d316-1c4b-4281-b951-d872f2087c98
* Improve scrolling performance when there are many windowed plugins in a page.jam@chromium.org2009-01-161-59/+28
| | | | | | | | 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
* Add support for custom cursors set by windowless plugins. Windowless plugins ↵ananta@chromium.org2009-01-091-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | typically set the cursor in NPP_HandleEvent for WM_MOUSEMOVE.The current implementation looks for the cursor type and if the typedoes not match predefinedcursor types defaults to the pointer cursor. The fixes are as below:- 1. Marshal the HCURSOR after copying it to ensure that it remains valid. This works as a HCURSOR is a user object and can be used across processes. Ideally we would like to convert it to a skia bitmap but there are issues with converting monochrome cursors. 2. Added support for marshaling platform specific data in the webcursor Serialize/Deserialize functions. This is in the form of functions like InitPlatformData, SerializePlatformData, DeserializePlatformData, etc. which are stubbed out for the other platforms. 3. Mimic webkit windowless plugin behavior where it sets a flag to ignore the next setCursor after HandleEvent of WM_MOUSEMOVE. If we don't do this the cursor keeps changing between a pointerCursor and the cursor set by the plugin which also causes flicker. 4. Fixed the WebCursor::IsEqual function to ensure that it checks all fields for equality. 5. The browser(RenderWidgetHostViewWin) now maintains a WebCursor instance representing the current cursor. Any cursor updates received from the renderer update the current cursor member maintained by the browser. 6. We intercept the SetCursor API for windowless plugins like Flash and Silverlight and remember the cursor being set. We don't invoke the original API as the browser UI thread would do it anyways. This fixes the annoying cursor flicker caused by the windowless flash plugin instance constantly setting the cursor even when the tab is not visible. This fixes bug http://code.google.com/p/chromium/issues/detail?id=3800. Review URL: http://codereview.chromium.org/15088 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7798 0039d316-1c4b-4281-b951-d872f2087c98
* Handle HTTP 200 responses received in response to byte range requests issued ↵ananta@chromium.org2008-12-171-37/+164
| | | | | | | | 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
* WebKit Merge 39143:39309, Part 8 (port side)dglazkov@google.com2008-12-161-1/+1
| | | | | | Review URL: http://codereview.chromium.org/14140 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7040 0039d316-1c4b-4281-b951-d872f2087c98
* Improve PDF FastWebView performance. This occurs because the manual data ↵ananta@chromium.org2008-12-061-3/+13
| | | | | | | | | | | | | | | | stream load does not get cancelled correctly. This causes the IPC messages for the manual data stream to continue going back and forth. They are ignored by the plugin anyways. This fixes http://code.google.com/p/chromium/issues/detail?id=5196. Fix is to cancel the manual document load correctly. Bug=5196 Review URL: http://codereview.chromium.org/13198 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6486 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting r6396 the PDF fix to not cancel the manual data streamananta@chromium.org2008-12-051-0/+4
| | | | | | | | | | | | 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-4/+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
* src/webkit side of webKit merge 38600:38625.ojan@google.com2008-11-261-7/+10
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6023 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding this fix. The earlier attempt broke test_shell_tests. The fixananta@chromium.org2008-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | has been added to this CB. Fix Silverlight windowless plugin painting issues. This fixes the following issues:- 1. http://code.google.com/p/chromium/issues/detail?id=4272 2. http://code.google.com/p/chromium/issues/detail?id=301 (Partially) The fixes are as below:- 1. Silverlight in the NPP_HandleEvent call for WM_PAINT, calls NPN_GetProperty for a bunch of properties like pageXOffset, pageYOffset, etc. It expects these properties to have integer types on return. We always return double. Firefox returns integer for these properties. Added a check in the conversion to NPVariant function in v8 to check for whether the value is an integer and return the intger type. 2. When the windowless plugin calls NPN_InvalidateRect we ask the plugin to paint in the same call, which the Silverlight plugin does not like. It relies on the fact that browsers would initiate invalidation asynchronously and eventually paint. This is a perfectly legal assumption. The Flash plugin does work if we synchronously ask it to paint. However other plugins could have similar issues. I verified with worldofwarcraft.com to see if the async paint has any sideeffects and there were none. 3.If the Silverlight plugin is not visible initially as on msdn.microsoft.com, it does not paint. This occurs because the plugin expects proper paints to come from the browser. It does not invalidate itself in UpdateGeometry as Flash. The plugin widget on msdn is not dynamic. It does call NPN_InvalidateRect initially when it is not visible. We don't send the call to the renderer as the plugin is not visible. To workaround this we now track the damaged rect even if the rect does not intersect the clipping rect of the plugin. In a geometry update if the plugin is visible, we send over the accumulated damaged rect to the renderer. The Silverlight plugin instance on msdn.microsoft.com does not work correctly even with these fixes. However it paints correctly. R=jam Bug=4272,301 Review URL: http://codereview.chromium.org/11569 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5829 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r5816 due to InvokeMethods failures in test_shell_tests.sgk@google.com2008-11-211-1/+1
| | | | | | Review URL: http://codereview.chromium.org/11342 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5818 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Silverlight windowless plugin painting issues. This fixes theananta@chromium.org2008-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | following issues:- 1. http://code.google.com/p/chromium/issues/detail?id=4272 2. http://code.google.com/p/chromium/issues/detail?id=301 (Partially) The fixes are as below:- 1. Silverlight in the NPP_HandleEvent call for WM_PAINT, calls NPN_GetProperty for a bunch of properties like pageXOffset, pageYOffset, etc. It expects these properties to have integer types on return. We always return double. Firefox returns integer for these properties. Added a check in the conversion to NPVariant function in v8 to check for whether the value is an integer and return the intger type. 2. When the windowless plugin calls NPN_InvalidateRect we ask the plugin to paint in the same call, which the Silverlight plugin does not like. It relies on the fact that browsers would initiate invalidation asynchronously and eventually paint. This is a perfectly legal assumption. The Flash plugin does work if we synchronously ask it to paint. However other plugins could have similar issues. I verified with worldofwarcraft.com to see if the async paint has any sideeffects and there were none. 3.If the Silverlight plugin is not visible initially as on msdn.microsoft.com, it does not paint. This occurs because the plugin expects proper paints to come from the browser. It does not invalidate itself in UpdateGeometry as Flash. The plugin widget on msdn is not dynamic. It does call NPN_InvalidateRect initially when it is not visible. We don't send the call to the renderer as the plugin is not visible. To workaround this we now track the damaged rect even if the rect does not intersect the clipping rect of the plugin. In a geometry update if the plugin is visible, we send over the accumulated damaged rect to the renderer. The Silverlight plugin instance on msdn.microsoft.com does not work correctly even with these fixes. However it paints correctly. R=jam Bug=4272,301 Review URL: http://codereview.chromium.org/11492 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5816 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-20 08:31:49 +0000