> 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? > > Dawit Alemayehu wrote: > 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.
Ok, thanks :) - Andrea ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6183/#review9502 ----------------------------------------------------------- On 2011-01-04 03:26:26, Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6183/ > ----------------------------------------------------------- > > (Updated 2011-01-04 03:26:26) > > > 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 > >
