> On 2011-01-05 11:11:06, Andrea Diamantini wrote: > > trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp, line 98 > > <http://svn.reviewboard.kde.org/r/6183/diff/4/?file=43503#file43503line98> > > > > I studied a bit the testing sites you gave me. I noticed that the > > download diff link in reviewboard does not work well with rekonq and > > konqueror (filename info NOT used). If I understood things well, the > > content-disposition header should be checked for filenames also having the > > "inline" value. > > So, something like: > > if(value.startsWith(QL1S("attachment"),...) || > > value.startsWith(QL1S("inline")...) > > > > I tested on rekonq code and it seems working. > > Dawit Alemayehu wrote: > Nope. kio_http will always ignore the file name parameter if > content-disposition header contains the "inline" parameter. Even if the > content sent is not something that user-agent can render, the file name > should be ignored regardless. For example, for the inlwithasciifilename test > at http://greenbytes.de/tech/tc2231/ you should not see the file name if you > choose to click "save" when prompted. In fact, the correct implementation for > inline content would be to display it embeded in the application whenever > possible, but that is not something that can be done generically in kwebpage > since not all application are KParts based. Note, some browsers incorrectly > use the "filename" parameter for > > BTW, I have now removed the code you quoted above, the one that does its > own content-disposition parsing in kwebpage. It was a left over and > unnecessary hack to workaround bugs in the kio_http's content-disposition > parser. However, it is much better to fix the issues at kio_http level than > to do this hack for sake of consistency in all KDE web rendering modules, not > just those based on QtWebKit.
On second thought since khtml seems to also use the filename even for "inline" content-disposition types, I have fixed the static extractSuggestedFileName function to return the value of the "filename" regardless of the content-disposition type. - Dawit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6183/#review9527 ----------------------------------------------------------- On 2011-01-05 06:21:31, Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6183/ > ----------------------------------------------------------- > > (Updated 2011-01-05 06:21:31) > > > 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 1211858 > trunk/KDE/kdelibs/kdewebkit/ISSUES 1211858 > trunk/KDE/kdelibs/kdewebkit/kwebpage.h 1211858 > trunk/KDE/kdelibs/kdewebkit/kwebpage.cpp 1211858 > trunk/KDE/kdelibs/kio/kio/accessmanager.h 1211858 > trunk/KDE/kdelibs/kio/kio/accessmanager.cpp 1211858 > trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.h 1211858 > trunk/KDE/kdelibs/kio/kio/accessmanagerreply_p.cpp 1211858 > > Diff: http://svn.reviewboard.kde.org/r/6183/diff > > > Testing > ------- > > > Thanks, > > Dawit > >
