--===============7417498376090503781== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6183/ ----------------------------------------------------------- (Updated 2011-01-03 03:49:54.352914) Review request for kdelibs and Andrea Diamantini. Changes ------- Updated the previous version of the patch as follows: - Handle the case where downloadResponse is called because of a content-dis= position header for a text/html content. Note the fix for this case is real= ly a hack based on what Konqueror does in its KonqMainWindow class. I just = do not see any better way to handle this better at this point unless, I imp= lement my own dialog to prompt the user for the desired action take on unsu= pported content. - Remove the ioslave on hold if the application selected to open the conten= t in downloadResponse is a non-KDE application. - Avoid unnecessary copying when setting the kio meta-data in KIO::AccessMa= nager. 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 k= dewebkit, 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. I= n such cases, apps that rely on kdewebkit and hence the KIO-QNAM bridge cla= ss have no way of putting an ioslave on hold as stated in KIO::get's docume= ntation in order to properly deal with content types they do not support. The attached patch along with another pending against kio_http, http://revi= ewboard.kde.org/r/6182/, remedies this issue by adding a means to put repli= es on hold and fixing the downloadResponse slot in KWebPage to do the right= thing. Diffs (updated) ----- 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 --===============7417498376090503781== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
This is an automatically generated e-mail. To reply, visit: http://svn.reviewb= oard.kde.org/r/6183/

Review request for kdelibs and Andrea Diamantini.
By Dawit Alemayehu.

Updated 2011-01-03 03:49:54.352914

Changes 
Updated the previous version of the patch as follows:

- Handle the case where downloadResponse is called because of a content-dis=
position header for a text/html content. Note the fix for this case is real=
ly a hack based on what Konqueror does in its KonqMainWindow class. I just =
do not see any better way to handle this better at this point unless, I imp=
lement my own dialog to prompt the user for the desired action take on unsu=
pported content.

- Remove the ioslave on hold if the application selected to open the conten=
t in downloadResponse is a non-KDE application.

- Avoid unnecessary copying when setting the kio meta-data in KIO::AccessMa=
nager.

Descripti= on 

The attached patch fixes a long standing issue in the KIO-QN=
AM class where actions that require putting an ioslave on hold currently do=
 not work. In kdewebkit, which uses this integration class, such actions al=
ways 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 ret=
urns 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 KI=
O::get's documentation in order to properly deal with content types the=
y do not support.

The attached patch along with another pending against kio_http, http://revi=
ewboard.kde.org/r/6182/, remedies this issue by adding a means to put repli=
es on hold and fixing the downloadResponse slot in KWebPage to do the right=
 thing.

Diffs= (updated)

  • trunk/KDE/kdelibs/kdewebkit/ISSUES (121107= 7)
  • trunk/KDE/kdelibs/kdewebkit/kwebpage.h (12= 11077)
  • 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.cpp (1211077)

View Diff
--===============7417498376090503781==--