Konqueror's "Open With" dialog behaviour when opening a URL with an external application

[Dawit A]

On Tue, May 17, 2011 at 5:04 PM, David Faure <faure at kde.org> wrote:
> On Tuesday 17 May 2011, Dawit A wrote:
>> On Tue, May 17, 2011 at 9:38 AM, Raphael Kubo da Costa <kubito at gmail.com>
> wrote:
>> > Dawit A <adawit at kde.org> writes:
>> >> On Mon, May 16, 2011 at 11:40 AM, Raphael Kubo da Costa
>> >>
>> >> <kubito at gmail.com> wrote:
>> >>> Hey there,
>> >>>
>> >>> I'm looking at Ark bug 273239 [1]: when one clicks one of the mentioned
>> >>> links, the Open With dialog shows up, and if one chooses to open the
>> >>> linked zip file with Ark it fails.
>> >>>
>> >>> It turns out that the web server only allows that link to work if the
>> >>> Referrer is set correctly. However, when Ark is called it just issues
>> >>> an HTTP GET with no Referrer header, thus getting an HTML login page
>> >>> instead.
>> >>>
>> >>> Is there anything I could to on Konqueror/KRun's side, or should I just
>> >>> close that bug as something that cannot be fixed on KDE's side?
>> >>
>> >> It is a bug in KParts::BrowserRun. Without getting into the gory
>> >> details, the problem was caused by the fact that the original ioslave
>> >> used to obtain the mimetype was never being reused by Ark because the
>> >> job that was put on hold in KParts::BrowserRun::slotBrowserMimeType
>> >> never gets published. Fixing that should fix the problem.
>> >
>> > Thanks for the information.
>> >
>> > I see that you've committed dfa8f69efb330a9f9a714a94f123c5d384445be2 to
>> > kdelibs master. I've recompiled kdelibs here, but can still experience
>> > the problem.
>>
>> Hmm... indeed. I guess I must have tested with the wrong component by
>> accident (kwebkitpart instead of khtml). Anyhow, I see what is
>> happening and the cause for the issue remains the same. However, the
>> ioslave that was put on hold was being purposefully removed in one of
>> the functions KonqRun::foundMimeType calls,
>> KParts::BrowserRun::handleNonEmbeddable. I will have to speak with
>> David to find out why that is being done...
>
> Can't remember. Tried asking git blame? :-)

No I love git blame :) Anyhow, I did check it, but unfortunately it
was part of the original creation of the file (commit
5a774ee075d0de98102783c01d8973770fee8a2d)  so there was nothing
specifically mentioned about it there..

Anyhow, I have created a patch for BrowserRun that addresses the issue
and put it up for review. See
https://git.reviewboard.kde.org/r/101379/

Regards,
Dawit A.