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