These changes make the webengine part emit the openUrlRequest signal in response to the QWebProfile::downloadRequested. This way konqueror reacts to the download request in the same way it does for khtml or kwebengine parts.

To achieve this, a new class, WebEnginePartDownloadManager, is introduced. This class connects to QWebProfile::downloadRequested signal and to a new signal, navigationRequested, from each existing WebEnginePage. The navigationRequested signal (emitted by a web page's acceptNavigationRequest method) allows the download manager to associate each download request with a navigation request, and, consequently, with the WebEnginePage which requested the download (this is necessary because, as far as I know, there's no way to associate the download request with a QWebEnginePage automatically). At this point, the openUrlRequest is emitted from the part corresponding to the page. Note that the download is not performed using QWebEngineDownloadItem (that is, QWebEngineDownloadItem::accept is not called).

Sometimes, a download is requested without a corresponding call to acceptNavigationRequest: in this case, the signal is emitted from an arbitrary part, specifying to open the file in a new window.

There are still some issues:

• sometimes, expecially for some downloads started from javascript, the above algorithm fails: the file isn't downloaded at all or it's displayed in the current tab instead of a new one or, in rare cases, produces an endless loop (which, however, doesn't freeze the UI)
• if acceptNavigationRequest isn't called, the file isn't opened in a new window but in the same window and tab. This, however, also happens when using KHTML, so I think the issue is somewhere else.

Go to a web page providing a link to download a file, then click on the link. The file should be embedded, saved or openend in a new window according to the settings.