On mercredi 7 août 2024 11:54:20 heure d’été d’Europe centrale David Faure wrote: > On mercredi 7 août 2024 08:30:43 heure d’été d’Europe centrale Stefano > Crocco > wrote: > > Hello to everyone, > > while investigating a bug in Konqueror, I just found what in my opinion is > > an unexpected behavior of KIO::MimeTypeFinderJob. If I'm reading the code > > correctly, when it uses KIO::get() to determine the mimetype [1], it lets > > the TransferJob go on even after it detected the mimetype. > > > > The documentation for KIO::get() states: > > "Special case: if you want to determine the MIME type of the file first, > > and then read it with the appropriate component, you can still use a > > KIO::get() directly. When that job emits the mimeType signal, (which is > > guaranteed to happen before it emits any data), put the job on hold". > > Since the task of MimeTypeFinderJob is finding the mimetype of the URL, I > > expected it would put the job on hold as soon as it has determined the > > mimetype, coherently with the KIO::get() documentation. > > Right, that's what KRun::foundMimeType was doing, and I did that in > MimeTypeFinderJob initially. > > But see commit 621585f0e818cd9f75cdd3bcc8665da7ac708283 > and bug 452729. Seems weird. Talk to Harald ;)
Of course in KF5 it was a bit different because another process could resume the slave on hold, made available by klauncher. AFAIK nowadays that's gone so resuming the slave on hold only works if the *same* process is going to fetch that URL. I guess that's the issue. If another process gets started instead (to open that URL in e.g. an image viewer), that slave on hold stays there forever. We need a way to discard it then, somehow. -- David Faure, fa...@kde.org, http://www.davidfaure.fr
signature.asc
Description: This is a digitally signed message part.
