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: rek...@freenode _______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
