Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
5.15.18, 6.8.1
-
Ubuntu 22.04 in VMware Workstation Pro 16; Windows 10 22H2
-
56fbb0fa5 (dev), 95badf9e6 (6.9), 03cd9ecba (6.8)
Description
Steps to reproduce
- Use Qt Creator and Qt 6.8 to build the attached project (server + client) in debug mode
- Run the client
- Check the debug output to verify that the HTTP server is running (if the server fails to start, you might need to manually kill the server from the previous session, or switch to a different port)
- When the web page loads, click the link ("Click Here to Download") to start the download
- Wait for the HTTP server to be killed, which triggers QWebEngineDownloadRequest::DownloadInterrupted
- Click the "Retry" button and wait for the download to finish
- Close the client window
- Delete the downloaded file from your disk
Outcomes (Linux)
Here, "A"/"B"/"C" refer to unique QWebEngineDownloadRequest instances. Only 1 instance is expected, but 3 are actually created during the test.
Step | Expected Request States | Actual Request States |
---|---|---|
4 | A: DownloadRequested → DownloadInProgress | A: DownloadRequested → DownloadInProgress |
5 | A: DownloadInProgress → DownloadInterrupted | A: DownloadInProgress → DownloadInterrupted B: DownloadRequested → DownloadInProgress → DownloadInterrupted |
6 | A: DownloadInterrupted → DownloadInProgress → DownloadCompleted | B: DownloadInterrupted → DownloadInProgress C: DownloadRequested → DownloadInProgress → DownloadCompleted |
7 | (no changes) | A: DownloadInterrupted → DownloadCancelled B: DownloadInProgress → DownloadCancelled |
Notably, although we call QWebEngineDownloadRequest::resume() on instance A...
- Instance A remains in "DownloadInterrupted" state
- Instance B changes to "DownloadInProgress" state, but receives no further updates
- Instance C changes to "DownloadCompleted" and emits the finished() signal
Further Tests
The client app has a combobox that lets you choose a different course of action when the interruption occurs:
- It doesn't matter whether resume() is called on Instance A or Instance B - the outcomes are the same
- If Instance B is not accepted, then calling QWebEngineDownloadRequest::resume() does not resume the download
- If Instance B is accepted and resume() is called on it, deleting Instance A cancels the download
While the server can only be built with Qt 6.8, the client can be built with Qt 5.15 too. To run the test with Qt 5.15.18 (or using Release mode), point the MANUAL_SERVER_DIR variable to the server's Qt 6.8 build folder.
- On Windows, Release mode produces similar outcomes to Linux. However, Step #5 doesn't generate Instance B.
- On Windows, Debug mode crashes (
QTBUG-132479) - Qt 5.15 has the same results as Qt 6.8.
Other notes
The customer (using Qt 5.15.18 on Linux) reported that the download will only resume if resume() is called on Instance B, not Instance A. However, it worked for me both ways.
Attachments
Issue Links
- relates to
-
QTBUG-132479 [Windows] After download is interrupted, QWebEngineDownloadRequest::resume() crashes with "Observers can only be added once!"
-
- Closed
-
For Gerrit Dashboard: QTBUG-132473 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
624057,5 | Fix download behavior when network error occurs | dev | qt/qtwebengine | Status: MERGED | +2 | 0 |
625600,2 | Fix download behavior when network error occurs | 6.9 | qt/qtwebengine | Status: MERGED | +2 | 0 |
625855,3 | Fix download behavior when network error occurs | 6.8 | qt/qtwebengine | Status: MERGED | +2 | 0 |