Skip to content

Rely on QtWebEngine to determine the mimetype of http(s) URLs

When KonqRun::scanFile is called from a view using a WebEnginePart and for a http or https URL with an unknown mimetype, don't use BrowserRun::scanFile but always return "text/html". This is because BrowserRun::scanFile issues a GET request to determine the mimetype, but QtWebEngine will then issue the same request, causing a double GET request. This way, instead, there will be only one GET request (from QtWebEngine). If QtWebEngine determines that the mimetype is one it can't open itself, the corresponding WebEnginePage will emit a openUrlRequest signal, with the real mimetype. Since the mimetype is now known, there isn't the risk of entering an endless loop.

There are two problems:

  • the double GET request issue remains when the URL can't be displayed by QtWebEngine. QtWebEngine emits the downloadRequested signal after doing a GET request to determine the mimetype of the URL. Using KIO/KParts to download the file causes a second GET request.
  • using QtWebEngine to determine the mimetype forces the user to use WebEnginePart to open URLs with mimetypes it can hanlde, even if the user has chosen another part for them. For example, clicking an a link to an image in a remote web page will cause the image to be opened in WebEnginePart even if the user chose to use GwenViewPart for images. This happens because, since QtWebEngine can handle images, it doesn't emit the downloadRequested signal.

Merge request reports