summaryrefslogtreecommitdiffstats
path: root/webkit/api
Commit message (Collapse)AuthorAgeFilesLines
* Refactoring to introduce refcount to WebMediaPlayerImplhclam@chromium.org2009-07-071-5/+4
| | | | | | | | | | WebMediaPlayerImpl interacts with multiple threads that it becomes necessary to make it refcounted so we can post task on different threads' message loop. Review URL: http://codereview.chromium.org/147225 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20038 0039d316-1c4b-4281-b951-d872f2087c98
* Port WebImage to CG and rework the Skia version so that WebImage just has adarin@google.com2009-07-033-96/+155
| | | | | | | | | | | | | | | | SkBitmap member (avoiding a level of indirection). This CL makes it so that Mac Chrome will now write bitmap data to the clipboard when requested by WebKit. I also simplified the ImageDecoder class that lives in glue. BUG=15648 TEST=none R=dglazkov Review URL: http://codereview.chromium.org/155010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19898 0039d316-1c4b-4281-b951-d872f2087c98
* Add getFileSize support to chromiumvictorw@chromium.org2009-07-032-0/+11
| | | | | | | | | | | | | | | | | The current implementation only allows getting file size if the child process has been granted permission to upload file. May need to update the policy checking code if getFileSize is needed in other cases. Here is the webkit implementation to support this: https://bugs.webkit.org/show_bug.cgi?id=26521 TEST=none BUG=9102 Review URL: http://codereview.chromium.org/131082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19866 0039d316-1c4b-4281-b951-d872f2087c98
* Add Reload and LoadData methods to WebFrame. LoadData replacesdarin@chromium.org2009-07-014-25/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LoadAlternateHTMLString, changing types to WebKit API types and allowing for more flexibility (supports loading non-HTML data). LoadHTMLString is modified to support some optional parameters. Note: Since WebFrame is going to soon be part of the WebKit API, it is OK style-wise for it to use optional parameters. This patch also includes a change to remove the securityInfo property from WebURLRequest. I did this so that I could eliminate the need to pass a WebURLRequest to LoadData / LoadHTMLString. This also fixes a TODO of mine to eliminate this field on WebCore::ResourceRequest since securityInfo (SSL cert info) is really more of a response property. It was only part of the request as a hack to support certain error pages. I work around that by leveraging NavigationState in chrome/renderer. I added some templatized, implicit constructors to WebData for convenience. I plan to make similar changes to WebCString and WebString in a future CL. This CL is a incremental step toward moving ResourceFetcher out of WebFrame. BUG=15648 TEST=none R=dglazkov Review URL: http://codereview.chromium.org/150146 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19742 0039d316-1c4b-4281-b951-d872f2087c98
* A quick fix for Issue 15531 and 10953hbono@chromium.org2009-07-012-2/+3
| | | | | | | | | | | | | | This issue is caused by my another mistake that I forgot setting the modifier-key state in creating a Char event in RenderWidgetHostViewGtkWidget::ForwardCharEvent(). Since the GtkIMContext signal-handlers don't use GdkEventKey objects and cannot get the modififer-key state, this change save the state in RenderWidgetHostViewGtkWidget::KeyPressReleaseEvent() before dispatching a key event to the GtkIMContext object. Also, this change adds gtk_im_context_focus_in() and gtk_im_context_focus_out() calls to fix compatibility problems with ibus. BUG=10953 "IME support" BUG=15531 "regression: shift-space doesn't scroll the page backwards" TEST=Open a test page in <http://crbug.com/15531>, press shift+space keys, and observe ev.shiftKey is true. Review URL: http://codereview.chromium.org/151010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19707 0039d316-1c4b-4281-b951-d872f2087c98
* Modify printing methods on WebFrame to be more inline with the versiondarin@chromium.org2009-06-302-32/+20
| | | | | | | | | | | | | | specified in webkit/api/public/WebFrame.h. Removes an unused method on WebFrame related to printing. BUG=10034 TEST=none R=brettw Review URL: http://codereview.chromium.org/150027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19669 0039d316-1c4b-4281-b951-d872f2087c98
* Delete V8Proxy and V8Utilities and use upstreamed versions.japhet@chromium.org2009-06-291-2/+2
| | | | | | Review URL: http://codereview.chromium.org/150056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19539 0039d316-1c4b-4281-b951-d872f2087c98
* Remove --enable-web-workers command-line switch.dimich@google.com2009-06-292-10/+0
| | | | | | | | BUG=4361 TEST=many ui/layout tests. Review URL: http://codereview.chromium.org/149114 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19512 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 19489,19488.japhet@chromium.org2009-06-291-2/+2
| | | | | | Review URL: http://codereview.chromium.org/150024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19490 0039d316-1c4b-4281-b951-d872f2087c98
* Use upstream V8Proxy and V8Utilitiesjaphet@chromium.org2009-06-291-2/+2
| | | | | | | | | BUG=15459 TEST=none Review URL: http://codereview.chromium.org/149086 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19488 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: plumb fontconfig call out to the sandbox host.agl@chromium.org2009-06-254-1/+207
| | | | | | | | | | | | | | | | | | | | | | | This is hopefully the last step before our renderers can run cleanly in a chroot. WebKit needs to be able to ask for the correct font to use in the case that the current font doesn't include glyphs for certain code points. Currently we make a fontconfig call in our WebKit port to handle this. This patch changes this so that the call is sent our via ChromiumBridge. Since we are at ChromiumBridge, we could make a sync IPC to the browser. However, fontconfig is a single threaded library and we are already using it on the UI thread in the browser, so the sync IPC would have to terminate on the UI thread. Even if this doesn't deadlock, it causes huge spikes in latency. So, instead, we send the IPC to the sandbox host process which is already setup to handle fontconfig requests from Skia. See: http://code.google.com/p/chromium/wiki/LinuxSandboxIPC git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19287 0039d316-1c4b-4281-b951-d872f2087c98
* Fix GCC compile error. This is similar to the change I made in r19105.darin@chromium.org2009-06-251-1/+1
| | | | | | | | | | TEST=none BUG=none TBR=dglazkov Review URL: http://codereview.chromium.org/147161 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19276 0039d316-1c4b-4281-b951-d872f2087c98
* Hook up WebHistoryItem and push HistoryItem serialization out of WebFrame.darin@chromium.org2009-06-254-28/+338
| | | | | | | | | | | | | | | | WebHistoryItem is a copy-on-write wrapper for a WebCore::HistoryItem. Pushing history item serialization out of WebFrame allows us to avoid a dependency on base/pickle from WebFrame. This helps get us closer to being able to move WebFrame into the WebKit API. BUG=10043 TEST=none R=dglazkov,sky Review URL: http://codereview.chromium.org/146075 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19275 0039d316-1c4b-4281-b951-d872f2087c98
* Integrating GtkIMContext into the RenderWidgetHostViewGtk class (Take 2).hbono@chromium.org2009-06-252-2/+115
| | | | | | | | | | | | | | | | | | | | | | | | This change is an updated version of <http://codereview.chromium.org/126118> that I reverted because of issue 15024 <http://crbug.com/15024>. This issue 15024 is caused by my bonehead mistake that I forgot handling the case that gtk_im_context_filter_keypress() returns false. (The GtkIMContext usually returns false when we type control keys, such as return, page up, page down, etc.) To handle this case, this change added code that manually creates a Char event and send it to the renderer in RenderWidgetHostViewGtkWidget::KeyPressReleaseEvent(). Except this code, it is exactly the same as <http://codereview.chromium.org/126118>. Unfortunately, this change still uses std::wstring, I'm going to send another change which replace std::wstring with string16. (The following message is copied from <http://codereview.chromium.org/126118>.) This change implements signal handers of the GtkIMContext object to support IMEs anddead-keys. Also, to improve compatibility with Windows Chrome, this changeemulates IPC messages sent on Windows when we input characters and fixes Issue13604 as well as Issue 10953 and 11226. Even though I notice we need more workfor fixing edge cases (e.g. disabling IMEs on a password input) on Linux, Ithink this is the good starting point. (Supporting edge-cases requirescomplicated code and it makes hard to review.) BUG=10953 "IME support" BUG=11226 "Dead keys and accents input not working" BUG=13604 "Hotkeys not working in non-us keyboard layout" BUG=13711 "Alt-D does not work when in editbox" TEST=Open a web page which contains an <input> form, type a '[{' key and an 'A' key on a Canadian-French keyboard, and see a Latin character "U+00E2" is displayed in the <input> form. TEST=Open a web page which contains an <input> form, enable an Chinese Pinyin IME, type a 'W' key, type an 'O' key, and see a Chinese character is displayed in the <input> form. TEST=Change the keyboard layout to Hebrew (or Russian), open a web page which contains an <input> form, input some characters in the <input> form, type control+a, and see the text in the <input> form is selected. TEST=Open a web page which contains a <textarea> form, type a return key, and see a new line is inserted. Review URL: http://codereview.chromium.org/147011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19238 0039d316-1c4b-4281-b951-d872f2087c98
* implement WebSandboxSupport stub to prevent a null ptr derefdpranke@google.com2009-06-252-5/+9
| | | | | | | | | | | | | | | | | | If FontChromiumWin's Font::drawGlyphs() fails for some reason, we may attempt to reload the font using ChromiumBridge::ensureFontLoaded(). This requires a sandbox routine, SandboxSupport::ensureFontLoaded() to be implemented, and in test_shell, it wasn't, causing a null ptr deref and weird things to happen. Note that there is no easy way to provoke this codepath once the other bugs causing the crash in #10977 are fixed. R=darin BUG=http://crbug.org/10977 TEST=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19200 0039d316-1c4b-4281-b951-d872f2087c98
* Fix GCC bustage. Part 2.darin@chromium.org2009-06-241-1/+1
| | | | | | | | | | TEST=none BUG=none TBR=dglazkov Review URL: http://codereview.chromium.org/147073 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19105 0039d316-1c4b-4281-b951-d872f2087c98
* Fix GCC build bustage.darin@chromium.org2009-06-241-0/+1
| | | | | | | | | | TEST=none BUG=none TBR=dglazkov Review URL: http://codereview.chromium.org/147072 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19104 0039d316-1c4b-4281-b951-d872f2087c98
* Switch WebHTTPBody and WebDragData to implement copy-on-write behavior. Thisdarin@chromium.org2009-06-247-29/+62
| | | | | | | | | | | | | | | | | | | | | | allows me to return a copyable instance of these wrapper classes while preventing a consumer from modifying the WebCore objects being wrapped. A modification will just modify a copy. This is going to be especially helpful when it comes to wrapping HistoryItem. Note how this simplifies WebURLRequest a bit since it doesn't have to carry a WebHTTPBody member. The copy-on-write behavior is implemented in an ensureMutable method. This CL depends on https://bugs.webkit.org/show_bug.cgi?id=26622 BUG=none TEST=none R=dglazkov Review URL: http://codereview.chromium.org/141062 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19103 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 19009 because this prevents inserting return characters.hbono@chromium.org2009-06-232-115/+2
| | | | | | | | | | | TBR=evan BUG=10953 "IME support" BUG=11226 "Dead keys and accents input not working" BUG=13604 "Hotkeys not working in non-us keyboard layout" TEST=none Review URL: http://codereview.chromium.org/147010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19015 0039d316-1c4b-4281-b951-d872f2087c98
* Integrating GtkIMContext into the RenderWidgetHostViewGtk class.This change ↵hbono@chromium.org2009-06-232-5/+118
| | | | | | | | | | | | | | implements signal handers of the GtkIMContext object to support IMEs and dead-keys. Also, to improve compatibility with Windows Chrome, this change emulates IPC messages sent on Windows when we input characters and fixes Issue 13604 as well as Issue 10953 and 11226. Even though I notice we need more work for fixing edge cases (e.g. disabling IMEs on a password input) on Linux, I think this is the good starting point. (Supporting edge-cases requires complicated code and it makes hard to review.) BUG=10953 "IME support" BUG=11226 "Dead keys and accents input not working" BUG=13604 "Hotkeys not working in non-us keyboard layout" TEST=Open a web page which contains an <input> form (e.g. <http://www.google.com/>), type a '[{' key and an 'A' key on a Canadian-French keyboard, and see a Latin character "U+00E2" is displayed in the <input> form. TEST=Open a web page which contains an <input> form (e.g. <http://www.google.com/>), enable an Chinese Pinyin IME, type a 'W' key, type an 'O' key, and see a Chinese character is displayed in the <input> form. TEST=Change the keyboard layout to Hebrew (or Russian), open a web page which contains an <input> form, input some characters in the <input> form, type control+a, and see the text in the <input> form is selected. Review URL: http://codereview.chromium.org/126118 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19009 0039d316-1c4b-4281-b951-d872f2087c98
* Delete files from webkit/glue that have been made obsolete by correspondingdarin@chromium.org2009-06-188-37/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | files in webkit/api. Here's the mapping: webkit/glue/webdatasource.h -> webkit/api/public/WebDataSource.h webkit/glue/weberror.h -> webkit/api/public/WebURLError.h webkit/glue/weburlrequest.h -> webkit/api/public/WebURLRequest.h webkit/glue/webresponse.h -> webkit/api/public/WebURLResponse.h I kept the implementation of WebDataSource in webkit/glue for now because it helps to have it close to WebFrameImpl and WebFrameLoaderClient. To facilitate this change, I needed to make use of WrappedResourceRequest and WrappedResourceResponse from webkit/api/src within the implementation files of webkit/glue. This is only a temporary usage of webkit/api/src from the outside. It will go away when WebFrame, etc. get moved into webkit/api. I modified these wrapper classes to expose the 'bind' function so that I can re-bind a wrapper. This is used in WebDataSourceImpl::request() and related methods to allow the interface to return a const reference to a WebURLRequest and WebURLResponse. The changes here are fairly mechanical. I'm not too happy about the way WebDataSource::redirectChain now works. I would prefer a solution that didn't involve so much copying, but I'm not going to worry about optimizing that now. R=brettw BUG=10041 TEST=none Review URL: http://codereview.chromium.org/126286 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18747 0039d316-1c4b-4281-b951-d872f2087c98
* Hack to enable video on mac by creating a blank PlatformContextMac to draw on.ajwong@chromium.org2009-06-164-9/+33
| | | | | | | | This isn't a great solution, but it kinda works. Video renders, and the speed is acceptable even though we're doing an extra copy for each frame. The image shows up upside-down though. :( Review URL: http://codereview.chromium.org/126087 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18503 0039d316-1c4b-4281-b951-d872f2087c98
* Extract form related classes from the guts of WebFrameImpl.darin@chromium.org2009-06-153-5/+170
| | | | | | | | | | | | | | | | | | | Instead of having WebFrameImpl generate SearchableFormData, PasswordForm, and AutofillForm classes, allow the embedder (RenderView) to do so. This is done to help minimize the dependencies WebFrameImpl has on other code, which will make it easier to move WebFrame and WebDataSource into the WebKit API. Most significant change: Now, RenderView always sets a NavigationState on WebDataSource instances. We used to only do so for browser initiated navigations. This is done so that we can store things like SearchableFormData and friends on the NavigationState. To facilitate this change, it was necessary to add a way through the WebKit API to refer to a HTMLFormElement. This CL introduces WebForm, which is like a RefPtr<HTMLFormElement>, so you can just copy a WebForm around by value and the right thing happens. Some of the other changes are about moving more things into the webkit_glue namespace. On hindsight, I probably should have done that as a separate CL. BUG=10041 TEST=none R=brettw Review URL: http://codereview.chromium.org/126083 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18395 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor the PlatformContext layer to have only one class.brettw@chromium.org2009-06-141-16/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Previously we had three classes of PlatformCanvas*, one for each platform. Then we had a typedef of PlatformContext to PlatformCanvas[Mac|Win|Linux] for the specific platform. This means that it was almost impossible to forward-declare PlatformCanvas and there were a bunch of unnecessary includes of platform_canvas.h in header files. This change makes there be only one platform_canvas.h header with ifdefs, which removes a decent amount of duplicated code. There is a platform-independent file, and one platform-dependent file of platform_canvas for each platform. I also renamed PlatformDevice[Mac|Win|Linux] to PlatformDevice, althouth in this case I kept the separate headers since there was much less overlap. I also broke out CanvasPaint into separate headers so this template doesn't need to be included all over the project (only a couple of files actually need it). Review URL: http://codereview.chromium.org/125109 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18363 0039d316-1c4b-4281-b951-d872f2087c98
* Roll webkit DEPS and fix build.abarth@chromium.org2009-06-141-2/+2
| | | | | | | TBR=pkasting Review URL: http://codereview.chromium.org/125108 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18361 0039d316-1c4b-4281-b951-d872f2087c98
* Fix javascript-backslash.html layout test failure.darin@chromium.org2009-06-112-25/+1
| | | | | | | | | | | | | | | | The fix is to break WebURLLoaderImpl into two classes. It now has a reference counted inner class that is the ResourceLoaderBridge::Peer. This change allows the inner class to stick around after the loader has been destroyed. That is necessary since the Peer expects to still receive OnCompletedRequest after it calls Cancel on the bridge. R=dglazkov TEST=covered by layout test BUG=13786 Review URL: http://codereview.chromium.org/125002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18215 0039d316-1c4b-4281-b951-d872f2087c98
* Update WebKit to r44544.darin@chromium.org2009-06-092-13/+0
| | | | | | | | | | | | | | | | | | | | 1- WorkerThread::create() now takes a WorkerLoaderProxy parameter, which I implemented in a stub fashion on WebWorkerImpl. I'm sure the WebWorker guys will fix this up properly. 2- Removed expirationDate and setExpirationDate members of WebURLResponse consistent with their removal from WebCore::ResourceResponseBase. The corresponding logic for computing cache eviction time is now part of WebCore. 3- Added wtf/DateMath.{h,cpp} to the build. TEST=covered by existing tests, I hope! BUG=none R=eroman Review URL: http://codereview.chromium.org/119387 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17983 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebURLLoader, et. al. from the WebKit API.darin@chromium.org2009-06-0920-114/+1527
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert WebURLLoader landing. Too many layout test failures.darin@chromium.org2009-05-3020-1474/+86
| | | | | | | | 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
* Fix layout test failures.darin@chromium.org2009-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | 1- We need to be careful when converting from a null WebURL to a GURL since std::string(NULL, 0) crashes. 2- It turns out that in some layout tests, willSendRequest sets the request to null to indicate that we should not follow the redirect. In the few cases I debugged, this was happening because we were redirecting from "localhost" to "127.0.0.1". It seems like we probably need to change the hostname used to load HTTP based layout tests to match what the tests expect. For now, I just commented out the assertion since it was something that I had just newly added. BUG=none TEST=covered by layout tests TBR=dglazkov Review URL: http://codereview.chromium.org/115970 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17291 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebURLLoader, et. al. from the WebKit API.darin@chromium.org2009-05-3019-85/+1473
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Handle mimetype queries for media fileshclam@chromium.org2009-05-292-4/+7
| | | | | | | | | | Added code path from WebKit to net::mimt_util to query supported mime-types for media files. BUG=12777 Review URL: http://codereview.chromium.org/114060 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17225 0039d316-1c4b-4281-b951-d872f2087c98
* Let ChromiumBridge::paintTextField check if the Color object passed in is validbrettw@chromium.org2009-05-271-1/+4
| | | | | | | | | | | | | | | | | | | or not. If not valid, just pass white to ThemeEngine. This change was motivated by the issue http://code.google.com/p/chromium/issues/detail?id=2756, but it has been resolved by only the upstream change https://bugs.webkit.org/show_bug.cgi?id=25742. However, this verification code is still useful. BUG=2756 Checked in for tyoshino@google.com Original review: http://codereview.chromium.org/113165 Review URL: http://codereview.chromium.org/113907 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17001 0039d316-1c4b-4281-b951-d872f2087c98
* Roll DEPS and fix build bustage. Propagate rename of policyBaseURL -> ↵abarth@chromium.org2009-05-222-6/+8
| | | | | | | | | | | | firstPartyForCookies a bit further. TBR=darin TEST=It complies! BUG=None Review URL: http://codereview.chromium.org/112055 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16804 0039d316-1c4b-4281-b951-d872f2087c98
* Add events to windowless plugins on linux. This CL also refactors the eventevan@chromium.org2009-05-224-16/+88
| | | | | | | | | | | | | 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
* Meta key is not the same as Alt key on Windows.avi@chromium.org2009-05-211-3/+3
| | | | | | | | | | See http://trac.webkit.org/changeset/29375 http://crbug.com/2215 Review URL: http://codereview.chromium.org/113716 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16641 0039d316-1c4b-4281-b951-d872f2087c98
* Move ExtraData from WebRequest to WebDataSource.darin@chromium.org2009-05-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a DidCreateDataSource method to WebViewDelegate, which the embedder uses to know if their LoadRequest resulted in a navigation. The embedder then associates the ExtraData with the WebDataSource at that point. The WebDataSource then proceeds to be treated as the provisional data source, possibly failing or being committed. We then inspect WebFrame::GetDataSource in DidCommitLoadForFrame to recover the ExtraData. We have to take care to handle reference fragment navigations since those do not result in a new WebDataSource being created. So, in DidChangeLocationWithinPage, we update the ExtraData associated with the WebDataSource returned by WebFrame::GetDataSource. One thing that is important to note: In DidCommitLoadForFrame, we would previously always inspect the value of GetDataSource returned from the main frame instead of looking at the frame passed to DidCommitLoadForFrame. This explains why WebFrameImpl:: LoadRequest needed to cached ExtraData on the current WebDataSource, and I think doing so is awkward and wrong. My change is to always store the ExtraData on the first WebDataSource to be created as a result of LoadRequest. Then in DidCommitLoadForFrame, I always inspect the ExtraData from the given WebFrame. This means that for history navigations that only navigate a subframe, we'll end up with ExtraData associated with the WebDataSource of a subframe. I think this is OK even though the old code was trying to avoid this scenario. See the DCHECK removed in RenderView::UpdateURL. BUG=11423 R=brettw Review URL: http://codereview.chromium.org/115575 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16580 0039d316-1c4b-4281-b951-d872f2087c98
* Move createWorker from WebKitClient to WebWorkerClient per your suggestion, ↵jam@chromium.org2009-05-202-7/+6
| | | | | | | | to avoid using WebKitClient outside the main thread. Review URL: http://codereview.chromium.org/115103 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16454 0039d316-1c4b-4281-b951-d872f2087c98
* Move WebMediaPlayerClientImpl files to WebKit API src location.darin@chromium.org2009-05-186-6/+572
| | | | | | | | | | | This involves adding a temporary glue function, which will be removed once WebFrame / WebView are part of the WebKit API. R=hclam Review URL: http://codereview.chromium.org/115482 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16336 0039d316-1c4b-4281-b951-d872f2087c98
* Fix typo. The right button is pressed when MK_RBUTTON is set.darin@chromium.org2009-05-181-1/+1
| | | | | | | | R=jam Review URL: http://codereview.chromium.org/115479 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16331 0039d316-1c4b-4281-b951-d872f2087c98
* Implement the triple click for the Mac.avi@google.com2009-05-125-48/+92
| | | | | | Review URL: http://codereview.chromium.org/99104 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15877 0039d316-1c4b-4281-b951-d872f2087c98
* Move WebKit API to src/webkit/api.darin@chromium.org2009-05-1086-0/+9374
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