[webkit-help] Download manager using IWebDownloadDelegate (cairo port)
chatko at gmail.com
Tue Sep 21 17:20:06 PDT 2010
This is very helpful while I'm in the process of writing my version.
However, I am having one other issue in triggering the download. I
find that some sites rely on Content-Disposition being set to
"attachment" in the header. For example: http://typewith.me/
(export/import, saving as html or plain text), where download decision
can't be made on mime type alone.
I've been trying to do this in the policy delegate , however I only
have access to the request not the response that i really need. In
other places, such as resource load delegate I have the response
however it seems too late to make a use/download decision.
Have you encountered this or perhaps have a suggestion?
On Tue, Sep 21, 2010 at 6:11 AM, Alexander Shulgin
<alexander.shulgin at yessoftware.com> wrote:
> On 21.09.2010 5:29, Chris Hatko wrote:
>> Hi I'm trying to put together a download manager under webkit cairo.
>> I've implemented a download handler via "IWebDownloadDelegate". I
>> register this download delegate by calling " setDownloadDelegate " in
>> my webview. When I try to download a file I can see that
>> "WebFrame::download(ResourceHandle* handle, const ResourceRequest&
>> request, const ResourceRequest&, const ResourceResponse& response) "
>> gets called and it seems to correctly find a pointer to my delegate.
>> However none of my delegates functions are ever called and hence I
>> can't download the file.
>> Any ideas as to what i'm missing in this procedure?
> I think it's because WebDownloadCurl is not implemented as of current
> Now I have this possibly incomplete patch (attached) to implement that. It
> works for me, but I never took the time get it reviewed/accepted, sorry.
> One thing I was forced to do is adding reference counting to
> ResourceHandleClient in order to support wasCancelled() callback. This
> resulted in rather large amount of small changes to files where the client
> is used, so I never really liked this part of the patch.
> Comments are welcome. :)
> PS: the patch is not against current trunk, but r57813, so it might not
> apply cleanly. :-/ You were warned.
More information about the webkit-help