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

[Dawit A]

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...