[rekonq] KDE/kdelibs/kdewebkit

[Andrea Diamantini]

On Wednesday 19 May 2010 17:37:19 Dawit A wrote:
> On Wednesday, May 19, 2010 05:13:37 Andrea Diamantini wrote:
> > On Wednesday 19 May 2010 02:08:45 Dawit Alemayehu wrote:
> > > SVN commit 1128338 by adawit:
> > > 
> > > - Added a slot that properly handles the downloading of replies that
> > > might contain "content-disposition" headers.
> > > 
> > >   Note this new API was added this late in anticipation of fixing a
> > > 
> > > critical issue that is awaiting a pending patch upstream in QtWebKit.
> > > See https://bugs.webkit.org/show_bug.cgi?id=37880
> > 
> > Many thanks for, Dawit.
> > If I understand things well, this new code works now as the previous one
> > 
> > and will start working "better" (read, consider "content-disposition"
> > headers) when your patch to QtWebKit will be applied (so, QtWebKit 2.1)
> > 
> > Is this correct?
> 
> Not entirely...
> 
> #1. Yes, this new function, downloadResponse, is better in the sense that
> it handles content-disposition whereas downloadRequest (I assume that is
> what you mean by the previous one) does not, but these two slots have
> different purposes. The former was added to allow you to connect
> QWebPage::downloadRequested signal where as the later is added to allow you
> to connect QWebPage::unsupportedContent signal.

Ok, this was clear :)

> #2. My content-disposition patch for upstream QtWebKit was already accepted
> and committed upstream a while back and it will be in QtWebKit 2.0. If you
> have forwarding of unsupported content enabled, then the unsupported
> content signal will be emitted when the user clicks on a link for which
> the server responds with a "Content-Disposition" in its header. And yes
> the new slot as stated above makes it a lot easier for you to support this
> by handling everything.
> 
> However, that was not what I meant by the pending critical issue awaiting
> the upstream fix. No that is a separate issue outlined in the bug report
> mentioned above. Actually it is an issue first raised to me by Ronny who
> works on reKonq as well. The issue is if you left click a link to download
> it or press a submit button that results in unsupportedContent signal, we
> have to abort the original request and redo it again if the content is to
> be saved to disk or even worse opened with another application.
> Unfortunately this is not always possible. For example, the
> unsupportedContent signal might be a result of content returned during a
> POST operation or the webserver explicitly forbids immediate
> re-downloading of the same file by the same client within certain
> duration.
> 
> That was the issue I was speaking of. Once the patch upstream is committed
> the new downloadResponse slot will also be modified to handle/deal with
> this issue.
> 
> Regards,
> Dawit A.

Yes, I'm aware of the reply bug. In fact I suggested Ronny to contact you 
about :)
What I didn't understand was that your first patch has just been merged. 
Anyway, thanks for explanation.

Have a nice day,
-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.sourceforge.net
IRC: rekonq at freenode