| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
- Add new histograms for request -> first layout and start load -> first layout
- Remove per navigation type histograms. They weren't being used and the logic was
getting too complex.
Review URL: http://codereview.chromium.org/88015
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14100 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, I removed the GetWebFrame method on WebDataSource since it is not
actually needed.
Removed some dead-code from webframe_impl.cc.
Removed some bogus null-checking of WebCore::Frame::loader().
R=dglazkov
Review URL: http://codereview.chromium.org/67169
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13844 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For each document loaded we record the time the page was requested by the user
(or as close as we can get to that), the time the load process started, the time
the
document and it's dependent resources (scripts) have been loaded (before
onload())
and the time all the document's resources have been loaded.
We use this data for two things:
1) We histogram the deltas between the time marks
2) We expose the times to javascript running on the page which was loaded
Review URL: http://codereview.chromium.org/42527
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13116 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
really silly to have them be separate classes.
I chose to eliminate WebDocumentLoaderImpl in favor of WebDataSourceImpl since
the interface that the outside world sees is named WebDataSource.
R=dglazkov
Review URL: http://codereview.chromium.org/46028
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11637 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
R=dglazkov
Review URL: http://codereview.chromium.org/42156
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11591 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10982 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
up to webkit@36102.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2778 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18 0039d316-1c4b-4281-b951-d872f2087c98
|