summaryrefslogtreecommitdiffstats
path: root/webkit/glue/webview_delegate.h
Commit message (Collapse)AuthorAgeFilesLines
* Move alternate 404 error page loading out of WebFrame and into RenderView.darin@chromium.org2009-08-041-25/+18
| | | | | | | | | | | | | | | | This involved adding a new method on WebViewDelegate to allow the embedder to intercept data being loaded for a document. I also had to plumb a few more FrameLoaderClient notifications through WebViewDelegate. See DidReceiveResponse and DidFinishLoading. R=tony BUG=15648 TEST=covered by errorpage_uitest.cc Review URL: http://codereview.chromium.org/160578 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22389 0039d316-1c4b-4281-b951-d872f2087c98
* This CL fixes issue 17468: Regression: Directionality marks should not be ↵xji@chromium.org2009-07-291-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | inserted for LTR systems To avoid empty square displayed around tooltip when system does not have RTL support, only add Unicode marks when element's directionality is not the same as UI's directionality. Note: 1. tooltip will be displayed using its element's directionality. 2. in system without RTL support, tooltip will only be displayed correctly (in its element's directionality and without empty square around) when both UI and element's directionality is LTR. BUG=http://crbug.com/17468 TEST= 1. Uninstall the right-to-left script and east Asian script through the Control Panel and restart system. 2. Run English Chrome. 3. given the following HTML, the displayed tooltip should not have empty square around. <html> <head> <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=utf-8"> </head> <body> <span style="background-color:Blue" title="Hi!">And now here!</span> </body></html> Review URL: http://codereview.chromium.org/160262 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21975 0039d316-1c4b-4281-b951-d872f2087c98
* Allow the browser to send actions back to the render for media element ↵ajwong@chromium.org2009-07-231-2/+4
| | | | | | | | | | | | | context menus. Also renamed ContextNodeType per fishd's suggestion. BUG=15686 TEST=none Review URL: http://codereview.chromium.org/155954 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21466 0039d316-1c4b-4281-b951-d872f2087c98
* Remove unintended addition of a forward delcaration for WebWidget.ajwong@chromium.org2009-07-171-1/+0
| | | | | | Review URL: http://codereview.chromium.org/149789 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20932 0039d316-1c4b-4281-b951-d872f2087c98
* Begin implementation of the context menu for Video and Audio tags.ajwong@chromium.org2009-07-171-1/+6
| | | | | | | | | | | This code should enable the creation of a basic context menu for the Video and Audio tags. The actions for fullscreen, save screenshot, loop, and set playback rate are not yet implemented. BUG=15686 TEST=None Review URL: http://codereview.chromium.org/149604 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20931 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 20855.darin@chromium.org2009-07-161-15/+25
| | | | | | 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-25/+15
| | | | | | 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-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Chrome-side of fixes for content-script messaging.mpcomplete@chromium.org2009-07-141-2/+6
| | | | | | | | | | | | | | | | | | This change adds registration of content scripts, parented to a frame's context. When a frame's context goes away, we unregister it and any content script contexts for it. There's a corresponding webkit change that lets us know when a content script context is created. Filed upstream as https://bugs.webkit.org/show_bug.cgi?id=27104. BUG=16228 TEST=install an extension with a content script that communicates with a parent process. Messages should be sendable both ways. Review URL: http://codereview.chromium.org/155309 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20677 0039d316-1c4b-4281-b951-d872f2087c98
* Replace ShowAsPopupWithItems to CreatePopupWidgetWithInfo. Also,darin@chromium.org2009-07-141-0/+9
| | | | | | | | | | | | | | | | | | make use of WebPopupMenuInfo from the WebKit API. WebMenuItem remains in webkit/glue for convenience with IPC marshalling and related usage in Chrome. This work is precursor to switching over to using WebWidget from the WebKit API. BUG=16234 TEST=html select drop downs should still work on the mac. try switching languages on news.google.com. R=paul Review URL: http://codereview.chromium.org/155378 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20624 0039d316-1c4b-4281-b951-d872f2087c98
* linux: only create browser-side plugin container after plugin requests itevan@chromium.org2009-06-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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-4/+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/+4
| | | | | | | | | | | | | | | | | | | | | | 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/+5
| | | | | | | | | | | | 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
* Fix for reverted cl http://codereview.chromium.org/147123davemoore@chromium.org2009-06-271-5/+0
| | | | | | | | | | | | | A recent change broke the load times. It also revealed some deficiencies. This adds a new time marker for when a load is committed, which is a more interesting value than the start of the load (which we still keep). Also, the first layout time wasn't an interesting time to keep, instead we keep the time of the first paint. The histograms were modified to use the new values when appropriate. Review URL: http://codereview.chromium.org/149099 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19465 0039d316-1c4b-4281-b951-d872f2087c98
* Add notifications for when V8Proxy creates or destroys a V8 Context.mpcomplete@chromium.org2009-06-261-0/+10
| | | | | | | | | | BUG=no TEST=no Review URL: http://codereview.chromium.org/147124 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19424 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 19361.davemoore@chromium.org2009-06-261-0/+5
| | | | | | | tbr=darin Review URL: http://codereview.chromium.org/149081 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19368 0039d316-1c4b-4281-b951-d872f2087c98
* A recent change broke the load times. It also revealed some deficiencies.davemoore@chromium.org2009-06-261-5/+0
| | | | | | | | | | | | This adds a new time marker for when a load is committed, which is a more interesting value than the start of the load (which we still keep). Also, the first layout time wasn't an interesting time to keep, instead we keep the time of the first paint. The histograms were modified to use the new values when appropriate. Review URL: http://codereview.chromium.org/147123 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19361 0039d316-1c4b-4281-b951-d872f2087c98
* DevTools: Nuke legacy debugger.pfeldman@chromium.org2009-06-241-2/+0
| | | | | | Review URL: http://codereview.chromium.org/146027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19108 0039d316-1c4b-4281-b951-d872f2087c98
* Delete files from webkit/glue that have been made obsolete by correspondingdarin@chromium.org2009-06-181-23/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Extract load times from WebDataSource. Move them to NavigationState.darin@chromium.org2009-06-161-0/+5
| | | | | | | | | | | | Move PasswordForm into the webkit_glue namespace. TEST=none BUG=10041 R=brettw Review URL: http://codereview.chromium.org/126190 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18515 0039d316-1c4b-4281-b951-d872f2087c98
* Extract form related classes from the guts of WebFrameImpl.darin@chromium.org2009-06-151-14/+7
| | | | | | | | | | | | | | | | | | | 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
* Use pointers instead of references in SpellCheck function.sidchat@google.com2009-06-121-3/+3
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/126054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18304 0039d316-1c4b-4281-b951-d872f2087c98
* Enable <video> in test_shellhclam@chromium.org2009-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | This is a work in progress draft. Summary of changes: 1. Moved code shared by chrome and test_shell to webkie/glue: WebMediaPlayerImpl SimpleDataSource VideoRendererImpl 2. Since WebMediaPlayerImpl is shared, chrome specific renderers are enabled by passing the FilterFactoryCollection into WebMediaPlayerImpl, this is done in RenderView. And WebMediaPlayerImpl provides some default renderer filters, which are used by the test shell and also chrome. Review URL: http://codereview.chromium.org/119229 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18182 0039d316-1c4b-4281-b951-d872f2087c98
* Do not allow URL drops on app windows to cause a navigation awaytc@google.com2009-06-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | from the currently loaded site. We are careful in this patch to continue to allow dropping URLs in text fields within the app window, and behavior for normal browser windows remains as before. There is a slight glitch when dragging a to an app window on the border of the window. Even though it is very brief, it is still disturbing. BUG=7171 TEST=Open Chrome (1), load google.com. Open Chrome (2), load yahoo.com. Drag a link from 1 to 2 and a link from 2 to 1 (both allowed). Create an app shortcut from 1, drag a link from 1 to 2 (allowed) and a link from 2 to 1 (denied). Verify that link scan be dragged to the omnibox and to text fields. Patch by Chase Phillips <chase@chromium.org> via http://codereview.chromium.org/119298 Review URL: http://codereview.chromium.org/121003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18100 0039d316-1c4b-4281-b951-d872f2087c98
* Stop auto-correcting abbreviations.BUG= www.crbug.com/12921TEST= For command ↵sidchat@google.com2009-06-101-2/+2
| | | | | | | | line --auto-spell-correct, "IMB" should not change to "IBM" Review URL: http://codereview.chromium.org/119210 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18099 0039d316-1c4b-4281-b951-d872f2087c98
* Implement InspectorClient's Settings API.pfeldman@chromium.org2009-06-031-0/+4
| | | | | | | | | | | | | | | This CL implements InspectorClient's API for reading / writing inspector settings. Here is how this is done: - inspector_client_impl.cc caches / serializes preferences into raw strings. It supports all kinds of settings except for string vector. I did not implement it since a) it requires more escaping b) I think we should get rid of it upstream. It then passes serialized settings string over IPC. - There is a dedicated IPC message called UpdateInspectorSettings that takes care of settings update. Two things I don't like: 1) reading settings and writing settings follow different paths: WebPreferences interface for read, delegate -> IPC for write. WebPreferences on read is used since these settings are needed very early in the page cycle. delegate -> IPC on write is the only option. 2) this looks like too much code on the Chrome side for functionality like this. Is there a more generic way of settings and persisting WebKit's preferences in Chrome? Should there be one? Review URL: http://codereview.chromium.org/119041 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17473 0039d316-1c4b-4281-b951-d872f2087c98
* Header cleanup in webkit/gluephajdan.jr@chromium.org2009-06-011-1/+0
| | | | | | | | | - reduce header dependencies - remove redundant forward declarations Review URL: http://codereview.chromium.org/115871 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17313 0039d316-1c4b-4281-b951-d872f2087c98
* Move ExtraData from WebRequest to WebDataSource.darin@chromium.org2009-05-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Adds propagation and handling of render-side focus events, for the benefit ↵klink@chromium.org2009-05-201-0/+11
| | | | | | | | of assistive technologies (accessibility). Also cleans up the handling of WM_GETOBJECT in RenderWidgetHostViewWin and WidgetWin, as well as in BrowserAccessibilityManager. Review URL: http://codereview.chromium.org/115374 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16449 0039d316-1c4b-4281-b951-d872f2087c98
* Re-do r15244 again.darin@chromium.org2009-05-131-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally reviewed at http://codereview.chromium.org/100353 Eliminate webkit/glue/webhistoryitem* in favor of adding a NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. In this version of the CL, TestWebViewDelegate performs the back/forward navigation directly in NavigateBackForwardSoon instead of using PostTask to delay it. I'm doing this to minimize regressions so that I can hopefully get the rest of this CL landed. I also already made the changes to WebKit to force history. {back,forward,go} to be processed asynchronously. Finally, it was necessary to move DumpBackForwardList out of webkit_glue.cc since it was using itemAtIndex to generate those results, and now that we return synthetic URLs for that function, the results were very wrong. The fix is to move DumpBackForwardList into TestShell so that it can more directly inspect the TestNavigationController. Now, it is necessary for webkit_glue.h to expose a function to dump a content state string (aka a WebCore::HistoryItem). BUG=11423 R=mpcomplete Review URL: http://codereview.chromium.org/113328 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15997 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r15940 again. Unexpected layout test failures :(darin@chromium.org2009-05-131-3/+5
| | | | | | | TBR=mpcomplete git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15942 0039d316-1c4b-4281-b951-d872f2087c98
* Re-do r15244 again.darin@chromium.org2009-05-131-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Originally reviewed at http://codereview.chromium.org/100353 Eliminate webkit/glue/webhistoryitem* in favor of adding a NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. In this version of the CL, TestWebViewDelegate performs the back/forward navigation directly in NavigateBackForwardSoon instead of using PostTask to delay it. I'm doing this to minimize regressions so that I can hopefully get the rest of this CL landed. I also already made the changes to WebKit to force history. {back,forward,go} to be processed asynchronously. BUG=11423 TBR=mpcomplete Review URL: http://codereview.chromium.org/115288 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15940 0039d316-1c4b-4281-b951-d872f2087c98
* Add Automatic spell correction support in Chrome.sidchat@google.com2009-05-121-0/+6
| | | | | | | Issue=7624 Review URL: http://codereview.chromium.org/42608 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15888 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor media player to move away from webkit_gluehclam@chromium.org2009-05-071-1/+4
| | | | | | | | | | | | Highlights: 1. WebCore::MediaPlayerPrivate now only has one static method that constructs WebMediaPlayerClient 2. Implementation of WebCore::MediaPlayerPrivateInterface now is WebMediaPlayerClient 3. WebMediaPlayerClient does the delgation to WebMediaPlayer 4. Implemtnation of real media player will go into chrome/renderer and implements WebMediaPlayer Review URL: http://codereview.chromium.org/105007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15492 0039d316-1c4b-4281-b951-d872f2087c98
* Plumb the creator URL for popups up to the browser. We don't yet use this ↵pkasting@chromium.org2009-05-051-2/+6
| | | | | | | | | for anything; it will be used for whitelisting popups by hostname. BUG=11440 Review URL: http://codereview.chromium.org/105004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15326 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r15278. More unexpected test failures :(darin@chromium.org2009-05-051-3/+5
| | | | | | | | TBR=mpcomplete Review URL: http://codereview.chromium.org/108005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15279 0039d316-1c4b-4281-b951-d872f2087c98
* Re-do r15244: Fix crash in ~TestWebViewDelegate caused bydarin@chromium.org2009-05-051-5/+3
| | | | | | | | | | | | | | | | | | shell_ being null. Moved the RevokeDragDrop call to the TestShell destructor instead. Eliminate webkit/glue/webhistoryitem* in favor of adding a NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. BUG=11423 R=mpcomplete Review URL: http://codereview.chromium.org/108004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15278 0039d316-1c4b-4281-b951-d872f2087c98
* Various trivial clean-up bits:pkasting@chromium.org2009-05-051-1/+1
| | | | | | | | | | * Fix an 80-column issue * Remove an unused param * Remove an unnecessary setter * Fix a variable capitalization style violation Review URL: http://codereview.chromium.org/100361 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15254 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r15244. Failed tests :(darin@chromium.org2009-05-041-3/+5
| | | | | | | | TBR=mpcomplete Review URL: http://codereview.chromium.org/99370 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15246 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate webkit/glue/webhistoryitem* in favor of adding adarin@chromium.org2009-05-041-5/+3
| | | | | | | | | | | | | | NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. BUG=11423 R=mpcomplete Review URL: http://codereview.chromium.org/100353 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15244 0039d316-1c4b-4281-b951-d872f2087c98
* revert r15223 to see if it fixes the security-context-with-base-tag.html crashdarin@chromium.org2009-05-041-4/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15230 0039d316-1c4b-4281-b951-d872f2087c98
* Adds a WillDestroyFrame(WebFrame*) notification method to WebViewDelegate thatdarin@chromium.org2009-05-041-0/+4
| | | | | | | | | | | | | | | | | | gets called from WebFrameLoaderClient::frameLoaderDestroyed(). The Chromium Embedded Framework needs this notification to properly clean up memory associated with specific WebFrame instances (for example, custom NPObject types bound to the WebFrame via BindToWindowObject()). This patch was contributed by Marshall Greenblatt. R=aa,darin Review: http://codereview.chromium.org/99283 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15223 0039d316-1c4b-4281-b951-d872f2087c98
* This CL makes Chrome on par with Firefox in terms of 'GetSuggestedFilename' ↵jungshik@google.com2009-05-011-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | for file download via context-menu. For a download initiated with a click on a link in a web page, a webkit-side change is necessary, which will be done later. Add a field (referrer_charset) to URLRequestContext and DownloadCreateInfo. It's set to the character encoding of a document where the download request originates from when it's known (download initiated via "save as" in the context menu). If it's not known (a download initiated by clicking on a download link or typing a url directly to the omnibox), it's initialized to the default character encoding in the user's preference. I guess this is marginally better than leaving it empty (in that case, step 2b below will be skipped and step 2c will be taken) because a user has a better control over how raw 8bit characters in C-D are interpreted (especially on Windows where a reboot is required to change the OS default codepage). This is later passed to GetSuggestedFilename and used as one of fallback encodings (1. UTF-8, 2. origin_charset, 3. default OS codepage). With this change, we support the following: 1. RFC 2047 2. Raw-8bit-characters : a. UTF-8, b. origin_charset, c. default os codepage. 3. %-escaped UTF-8. In this CL, for #3, I didn't add a fallback similar to one used for #2. If necessary, it can be added easily. New entries are added to 3 existing tests. What's previously not covered (raw 8bit Content-Disposition header) is now covered in all 3 tests. BUG=1148 TEST=net unit test: NetUtilTest.GetFileNameFromCD NetUtilTest.GetSuggestedFilename unittest : DownloadManagerTest.TestDownloadFilename Review URL: http://codereview.chromium.org/83002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15113 0039d316-1c4b-4281-b951-d872f2087c98
* Fix sudden termination after the latest WebKit merge.jam@chromium.org2009-04-251-6/+0
| | | | | | | | BUG=10927 Review URL: http://codereview.chromium.org/93104 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14517 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebWorker and WebWorkerClient from the WebKit API.darin@chromium.org2009-04-241-3/+3
| | | | | | | | | BUG=10995 R=jam Review URL: http://codereview.chromium.org/92144 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14461 0039d316-1c4b-4281-b951-d872f2087c98
* Remove unused bits and pieces of #ifdefed code that isn't used.tim@chromium.org2009-04-241-4/+0
| | | | | | Review URL: http://codereview.chromium.org/93042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14402 0039d316-1c4b-4281-b951-d872f2087c98
* Remove some unused code. Removes a couple of WebViewDelegate methodsdarin@chromium.org2009-04-181-17/+0
| | | | | | | | | | that should really just be public methods on TestWebViewDelegate. R=dglazkov Review URL: http://codereview.chromium.org/79080 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14008 0039d316-1c4b-4281-b951-d872f2087c98
* Refactoring; switch the |filter| parameter into something that is more ↵avi@chromium.org2009-04-121-3/+2
| | | | | | | | | | amenable to cross-platform implementation. BUG=9852 Review URL: http://codereview.chromium.org/63093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13573 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-091-6/+2
| | | | | | | | | | | | | | | | | layer interface. This will help when we move those interfaces into the WebKit API. This is a second attempt at r13381, which was already reviewed here: http://codereview.chromium.org/63126 The only change between that CL and this one is in render_view.h, where I needed to change a parameter type from gfx::Rect to WebRect. TBR=dglazkov Review URL: http://codereview.chromium.org/64005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13424 0039d316-1c4b-4281-b951-d872f2087c98