Skip to content

Fix a bug causing an endless loop with WebEnginePart

To avoid to pass the URL back to WebEnginePart, don't rely on the fact that WebEnginePart is the first part in the list.

It can happen that WebEnginePart thinks it can't handle an URL even if, basing on its mimetype, it should. In this case, in UrlLoader::decideEmbedOrSave, m_view->supportsMimeType will return true, so m_service will be a WebEnginePart, even if it's not the first in the list of preferred parts for that mimetype. However, the code which explicitly avoids using WebEnginePart when asked not to assumed that WebEnginePart was the preferred mimetype, using services[1] to find the service to use.

This can have two outcomes: if WebEnginePart is neither the first nor the second preferred service, the effect would be to use a less preferred service instead of the preferred one. However, if the WebEnginePart was the second preferred service, this bug leads to an endless loop because, m_service is set to services[1] which is WebEnginePart: exactly what was to be avoided.

This can be seen, for example, by attempting to download this image from Wikipedia: https://en.wikipedia.org/wiki/Black_body#/media/File:Black_body_realization.svg If the preferred part for image/svg+xml is SvgPart and the second is WebEnginePart, pressing the "Download this file" button, then "Download original file" leads to an endless loop.

Note that I don't know why WebEnginePart can't open that svg file.

Merge request reports