Review Request: Fix the inability to put an ioslave on hold when using the KIO-QNAM integration class...

[Dawit Alemayehu]

> On 2011-01-04 01:28:06, Andrea Diamantini wrote:
> > trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp, line 421
> > <http://svn.reviewboard.kde.org/r/6183/diff/3/?file=43369#file43369line421>
> >
> >     I'm studying and testing your patch. I  have just a stupid question actually: this "remove hold state" slot seems called just on cancel. Is this ok?

It is not only called when you press cancel, but also if the the application you chose to open the request with is non-KDE application. IOW, we kill the ioslave we put on hold whenever it is not going to be used...

For your tests, you can use the test links marked "Movie" and "PDF" at 

https://projects.kde.org/projects/extragear/base/kwebkitpart/repository/revisions/master/changes/tests/link_tests.html

Another good site for testing content-disposition is

http://greenbytes.de/tech/tc2231/

Please note that the html links at that site might expose known limitations with the current put slave on hold mechanism when multiple KDE browsers are involved. This limitation is marked as HACK in the kwebpage patches.


- Dawit


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6183/#review9502
-----------------------------------------------------------


On 2011-01-03 03:49:54, Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6183/
> -----------------------------------------------------------
> 
> (Updated 2011-01-03 03:49:54)
> 
> 
> Review request for kdelibs and Andrea Diamantini.
> 
> 
> Summary
> -------
> 
> The attached patch fixes a long standing issue in the KIO-QNAM class where actions that require putting an ioslave on hold currently do not work. In kdewebkit, which uses this integration class, such actions always occur when you click on a link that cannot be directly handled by the browsing engine. For example, clicking on a link that points to a PDF link. Even worse is when the link you click on results in an http POST which returns content. In such cases, apps that rely on kdewebkit and hence the KIO-QNAM bridge class have no way of putting an ioslave on hold as stated in KIO::get's documentation in order to properly deal with content types they do not support.
> 
> The attached patch along with another pending against kio_http, http://reviewboard.kde.org/r/6182/, remedies this issue by adding a means to put replies on hold and fixing the downloadResponse slot in KWebPage to do the right thing.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/kdewebkit/ISSUES 1211077 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.h 1211077 
>   trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.h 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanager.cpp 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h 1211077 
>   trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp 1211077 
> 
> Diff: http://svn.reviewboard.kde.org/r/6183/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110104/8b470612/attachment.htm>