| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/99104
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15877 0039d316-1c4b-4281-b951-d872f2087c98
|
|
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
|