summaryrefslogtreecommitdiffstats
path: root/webkit/glue/webframe_impl.h
Commit message (Collapse)AuthorAgeFilesLines
* Send port-closed notification when a frame with ports unloads.mpcomplete@google.com2009-06-181-0/+2
| | | | | | | | | | | | | Also add onLoad and onUnload chrome Event to our bindings, so we can add listeners to these events without needing a DOM. These don't hook into the window "unload" event, so we no longer prevent Chrome's sudden termination of tabs on shutdown. BUG=12686 TEST=no Review URL: http://codereview.chromium.org/125280 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18765 0039d316-1c4b-4281-b951-d872f2087c98
* Delete files from webkit/glue that have been made obsolete by correspondingdarin@chromium.org2009-06-181-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 form related classes from the guts of WebFrameImpl.darin@chromium.org2009-06-151-1/+1
| | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add functions to glue to get the full html of the page and also to check if ↵sverrir@google.com2009-06-021-0/+2
| | | | | | | | | | | the user has selected something. This is for enhanced printing support (in progress). Review URL: http://codereview.chromium.org/119043 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17427 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the HistoryState property of WebRequest.darin@chromium.org2009-05-221-0/+2
| | | | | | | | | | | | | | | | | In the new WebKit API, it seems best if WebRequest is just a wrapper for WebCore::ResourceRequest since in most contexts that's what we need it to be. The solution here is to introduce a LoadHistoryState method on WebFrame that can be used to navigate to a session history item. BUG=10038 TEST=covered by existing back/forward navigation tests. R=brettw Review URL: http://codereview.chromium.org/113758 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16747 0039d316-1c4b-4281-b951-d872f2087c98
* Remove a field that is now unused. This was made obsoletedarin@chromium.org2009-05-211-5/+0
| | | | | | | | | | by the change to eliminate WebRequest::Get/SetExtraData. R=brettw Review URL: http://codereview.chromium.org/113694 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16611 0039d316-1c4b-4281-b951-d872f2087c98
* Move ExtraData from WebRequest to WebDataSource.darin@chromium.org2009-05-211-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Re-do r15244 again.darin@chromium.org2009-05-131-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+7
| | | | | | | 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-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* There are cases where a Frame may outlive its associated Page. Get thedarin@chromium.org2009-05-061-6/+1
| | | | | | | | | | | | | | | | 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
* Revert r15278. More unexpected test failures :(darin@chromium.org2009-05-051-0/+7
| | | | | | | | 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-7/+0
| | | | | | | | | | | | | | | | | | 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
* Fix bug 9812: Remove current RSS code in favor of new more generalizedfinnur@chromium.org2009-05-041-1/+0
| | | | | | | | | | | | PageAction code that serves the same purpose (and more). BUG=9812 TEST=No test needed, this shouldn't result in any noticable difference since the RSS parsing was disabled. Review URL: http://codereview.chromium.org/100356 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15247 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r15244. Failed tests :(darin@chromium.org2009-05-041-0/+7
| | | | | | | | 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-7/+0
| | | | | | | | | | | | | | 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
* Rev 12100 changed the way that we spool and render printed output, most notablymaruel@chromium.org2009-04-271-0/+1
| | | | | | | | | | | | | | | | | | | | introducing use of the PrintContext class. The existing PrintContext::spoolPage() method applies a webkit scaling factor before rendering output to the graphics context. ChromePrintContext::spoolPage() (in webframe_impl.cc), which is used by chromium instead of PrintContext::spoolPage(), does not apply this scaling factor, but instead eventually returns the scaling factor via WebFrame::PrintPage(). This is a problem for the Chromium Embedded Framework (CEF) because, unlike chromium, the CEF renders directly to the printer device context. It is therefore important for CEF that we retrieve and apply the webkit scaling factor before calling PrintPage(). In order to support this capability the following adds a WebFrame::GetPrintPageShrink() method. Patch contributed by Marshall Greenblatt <magreenblatt@gmail.com> Review: http://codereview.chromium.org/99058 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14639 0039d316-1c4b-4281-b951-d872f2087c98
* Rename AllowCrossOriginAccessHack to GrantUniversalAccess, and move the HACKmpcomplete@google.com2009-04-171-1/+1
| | | | | | | warnings to the callsite. Review URL: http://codereview.chromium.org/79028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13953 0039d316-1c4b-4281-b951-d872f2087c98
* Add a hack to enable cross-origin XHR for all pages with a "chrome-extension"mpcomplete@google.com2009-04-151-0/+1
| | | | | | | | URL as the toplevel frame. This is a temporary workaround until we can do it the proper way, which requires a webkit refactoring in progress by Alexei. Review URL: http://codereview.chromium.org/67153 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13790 0039d316-1c4b-4281-b951-d872f2087c98
* Let WebKit draw the active highlight for FindInPage,finnur@chromium.org2009-04-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instead of using the SelectionController. This fixes a couple of bugs, such as: Active match highlighting disappears when mouse selection is made within the page and selection color is orange (6145). and Selection color becomes orange in some cases on tabs that don't have a Find box open. and Gmail jumping to the first match if on FindNext if Find box is closed and reopened (9795). NOTE: This patch depends on my patch to WebKit that just got accepted. See: https://bugs.webkit.org/show_bug.cgi?id=25102 BUG=6145, 9795 TEST=Find something on a page that results in multiple matches being found. Highlight another word that is not currently highlighted. You should see both active and inactive highlights (orange and yellow) and a blue colored selection highlight. Review URL: http://codereview.chromium.org/66016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13510 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-091-5/+5
| | | | | | | | | | | | | | | | | 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
* Reverting dfisher changes 133386 and 13381cpu@google.com2009-04-081-5/+5
| | | | | | | | | | TBR=darin Review URL: http://codereview.chromium.org/58018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13387 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using WebPoint, WebRect, and WebSize in more of the gluedarin@chromium.org2009-04-081-5/+5
| | | | | | | | | | | layer interface. This will help when we move those interfaces into the WebKit API. R=dglazkov Review URL: http://codereview.chromium.org/63126 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13381 0039d316-1c4b-4281-b951-d872f2087c98
* Adds new messages and widens some existing messages between the renderer and ↵michaeln@google.com2009-04-071-0/+9
| | | | | | | | browser processes to support an implementation of the HTML5AppCache spec with most of the logic running in the browser process. The gist of most of the changes are to indicate which frame each resource request is coming from, and to indicate which appcache each response was retrieved from (if any).See https://docs.google.com/a/google.com/Doc?docid=agv6ghfsqr_15f749cgt3&hl=en Review URL: http://codereview.chromium.org/9712 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13258 0039d316-1c4b-4281-b951-d872f2087c98
* Stop serializing WebString over IPC. The new rule is that only POD (plain olddarin@chromium.org2009-04-061-3/+9
| | | | | | | | | | | | | data) types from WebKit API are allowed to be used in the browser process. I added a big note about this to webkit_param_traits.h to explain the details of this decision. R=dglazkov Review URL: http://codereview.chromium.org/62032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13181 0039d316-1c4b-4281-b951-d872f2087c98
* Callbacks through ChromeClient->RenderView->RenderViewHost for ↵rafaelw@chromium.org2009-04-041-0/+1
| | | | | | | | ContentsDidChangeSize so that extensions can change their toolbar size when the contained contents changes size. Review URL: http://codereview.chromium.org/56122 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13130 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebConsoleMessage instead of ConsoleMessageLevel.darin@chromium.org2009-03-311-2/+1
| | | | | | | | R=dglazkov Review URL: http://codereview.chromium.org/57073 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12916 0039d316-1c4b-4281-b951-d872f2087c98
* Use WebScriptSource and WebFindInPageRequest from the WebKit API.darin@chromium.org2009-03-311-7/+8
| | | | | | | | | | | | | | | | | | This change introduces some helper functions in glue_util.cc for efficient conversion between WebString and WebCore::String when inside the implementation of webkit/glue. This is a temporary change since eventually all code in glue that uses WebCore will be moved into the WebKit API implementation. Instead of making the Chrome automation use WebFindInPageRequest, I decided to introduce AutomationMsg_Find_Params as a copy of the old FindInPageRequest structure. That preserves the IPC protocol and avoids making the automation library depend on WebKit. R=dglazkov Review URL: http://codereview.chromium.org/57060 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12881 0039d316-1c4b-4281-b951-d872f2087c98
* Convert FindInPage wstrings to string16.tc@google.com2009-03-191-1/+1
| | | | | | | Review URL: http://codereview.chromium.org/42408 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12158 0039d316-1c4b-4281-b951-d872f2087c98
* Remove code duplicated from webcore and use the common PrintContext facility.maruel@chromium.org2009-03-191-23/+11
| | | | | | Review URL: http://codereview.chromium.org/20470 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12100 0039d316-1c4b-4281-b951-d872f2087c98
* Review URL: http://codereview.chromium.org/42288georged@chromium.org2009-03-181-0/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12016 0039d316-1c4b-4281-b951-d872f2087c98
* SSLPolicy Fix: Step 1.abarth@chromium.org2009-03-171-0/+2
| | | | | | | | | | | | Expose some more accessors on WebFrame. R=wtc BUG=8706 Review URL: http://codereview.chromium.org/48034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11838 0039d316-1c4b-4281-b951-d872f2087c98
* Commit 40144. I had to move to to a separate CL to use gcl'saa@chromium.org2009-03-131-3/+3
| | | | | | | | "try multiple commits" feature. Review URL: http://codereview.chromium.org/46062 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11683 0039d316-1c4b-4281-b951-d872f2087c98
* RSS feed support (part 1), 2nd attempt.finnur@chromium.org2009-03-131-0/+1
| | | | | | | | | | | | | | | | | | | | | Part 1 is RSS feed auto-discovery. This will parse the web page header to find the feeds in the document and notify the browser to display the RSS icon in the toolbar. You can click on the icon, but it will just navigate to the first feed on the page, which (unless it has been designed to be browser friendly) will just dump XML as text on the user. For this reason I have disabled the code that makes the RSS icon appear and intend to enable it when we have a good landing page to display the XML. Review URL: http://codereview.chromium.org/46055 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11672 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 11640.finnur@chromium.org2009-03-131-1/+0
| | | | | | Reverting for now. Will try again later git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11645 0039d316-1c4b-4281-b951-d872f2087c98
* RSS feed support (part 1)finnur@chromium.org2009-03-131-0/+1
| | | | | | | | | | | | | | | | Part 1 is RSS feed auto-discovery. This will parse the web page header to find the feeds in the document and notify the browser to display the RSS icon in the toolbar. You can click on the icon, but it will just navigate to the first feed on the page, which (unless it has been designed to be browser friendly) will just dump XML as text on the user. For this reason I have disabled the code that makes the RSS icon appear and intend to enable it when we have a good landing page to display the XML. Review URL: http://codereview.chromium.org/43109 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11640 0039d316-1c4b-4281-b951-d872f2087c98
* Changing ForwardMessageToExternalHost to postMessage and passing a propertommi@chromium.org2009-03-091-0/+2
| | | | | | | | | | | | | | | MessageEvent object to the onmessage handler. Also adding support for origin and target parameters. The origin parameter is implicit but target can be specified when calling postMessage. If no target is specified we default to "*". At the moment I'm only allowing target == "*" messages to pass through since I haven't implemented support for matching more complicated patterns :) Review URL: http://codereview.chromium.org/40128 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11275 0039d316-1c4b-4281-b951-d872f2087c98
* Remove code that will not be necessary after ↵ojan@google.com2009-03-031-2/+0
| | | | | | | | https://bugs.webkit.org/show_bug.cgi?id=24307 is fixed. Review URL: http://codereview.chromium.org/27373 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10815 0039d316-1c4b-4281-b951-d872f2087c98
* Hook up inspector highlighting again. This time we useojan@google.com2009-02-261-7/+0
| | | | | | | | | upstream's drawNodeHighlight methods. BUG=5178 Review URL: http://codereview.chromium.org/31010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10497 0039d316-1c4b-4281-b951-d872f2087c98
* Reduce the amount of included header files. Vast change like in "Oh God! ↵maruel@chromium.org2009-02-181-11/+4
| | | | | | | | This revision changes half of the source files!". Review URL: http://codereview.chromium.org/20378 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9958 0039d316-1c4b-4281-b951-d872f2087c98
* The WebFrame interface currently supports reference counting, but no one uses.darin@chromium.org2009-02-131-1/+1
| | | | | | | | | | | | | | | | Internally, WebFrameImpl needs reference counting, so we still define it there. Same goes for WebView and WebWidget. While making this change, I noticed that WebInspectorClient was casting WebView pointers to WebViewImpl pointers too much. By just starting with WebViewImpl pointers, things could be cleaned up considerably. R=brettw Review URL: http://codereview.chromium.org/21342 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9745 0039d316-1c4b-4281-b951-d872f2087c98
* Remove unreferenced WebFrame::IsReloadAllowingStaleData method.darin@chromium.org2009-01-201-2/+0
| | | | | | | | | | (Sending this to you for review since you originally reviewed the CL that added it.) R=brettw Review URL: http://codereview.chromium.org/18412 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8309 0039d316-1c4b-4281-b951-d872f2087c98
* First pass as implementing the greasemonkey API. This patchaa@chromium.org2009-01-171-1/+2
| | | | | | | | | | | | | | | | | | | includes a javascript file with stubbed versions of all the greasemoney API methods as well as changes to the Greasemonkey slave to inject this javascript file along with other user scripts into the page.I also have a userscript I'm using for the unit testing of the API methods. I don't think there is a good place for it in the chrome tree (if there is I'd like to know), but you can view it here: http://skrul.com/greasemonkey/test.user.js Right now all the tests fail except for testLog and testUnsafeWindow. Review URL: http://codereview.chromium.org/18183 Patch from Steve Krulewitz <skrulx@gmail.com>. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8247 0039d316-1c4b-4281-b951-d872f2087c98
* Added the new isCommandEnabled() layout test function to the layout test ↵estade@chromium.org2008-12-181-0/+1
| | | | | | | | | | controller. Fixes one new layout test. Review URL: http://codereview.chromium.org/14871 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7277 0039d316-1c4b-4281-b951-d872f2087c98
* Move the "platform" wrappers in skia/ext to the skia namespace.brettw@google.com2008-12-171-3/+3
| | | | | | Review URL: http://codereview.chromium.org/14110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7182 0039d316-1c4b-4281-b951-d872f2087c98
* Add "Enable spell check for this field" menu option in sub context menu for ↵sidchat@google.com2008-12-151-0/+2
| | | | | | | | context menu over text box, and deploy its functionality accordingly across the code. This patch also allows manual switch-on of spell check in single line text box fields. Review URL: http://codereview.chromium.org/13731 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7000 0039d316-1c4b-4281-b951-d872f2087c98
* Move implementation of BackForwardListClient to a new class nameddarin@chromium.org2008-12-131-2/+4
| | | | | | | | | | BackForwardListClientImpl. R=dglazkov Review URL: http://codereview.chromium.org/14407 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6959 0039d316-1c4b-4281-b951-d872f2087c98
* Fix issue 5079: Incorrect "Active match ordinal" count during Find-in-pagefinnur@google.com2008-12-041-3/+3
| | | | | | | | | | | | | | | I introduced a regression in my reimplemenation of Find-in-page. The active match ordinal in Find-in-page (also known as "the 7" in "7 of 9") would be just a little off on pages with frames. Problem A: When you search for something in gmail, for example, the ordinal could start off slightly negative or be 0. I wasn't checking the last_match_count_ of a frame for negative numbers before adding it to the total (it starts off as -1 and remains that way if the frame is not deemed to be worthy of being scoped, i.e. if it is hidden). Problem B: On pages with multiple matches spread across multiple frames the ordinal would not be subtracted correctly after pressing F3 and Shift-F3 to go back to the frame you were on. We shouldn't be increasing/decreasing the active_match_index for a given frame when FindNext/FindPrevious causes us to jump between frames. We should instead reset it. I added two tests to catch this in the future. They test ordinal values as you use Find in page (including combinations of frames/no-frames & FindNext/FindPrevious). Oh, and I also removed some traces that were supposed to expose why a test was flaky, but it turns out to have been something unrelated to the test. Review URL: http://codereview.chromium.org/13130 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6369 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the URL and title from the state getting functions and IPC messages.brettw@google.com2008-12-021-5/+3
| | | | | | | If the title or URL changes, we'll be updated in other ways, so this extra processing is wasted. Review URL: http://codereview.chromium.org/12859 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6225 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-22 20:50:10 +0000