GNOME Bugzilla – Bug 319500
Epiphany appears to stall when queueing multiple downloads
Last modified: 2013-12-16 16:16:16 UTC
When queueing multiple downloads with "Save As", sometimes nothing happens for a very long time, with no feedback to the user at all. After a long while, the save dialog appears. The use case that got me to report this: I wanted to download these songs found here: http://www.bradsucks.net/albums/i_dont_know/ and when I got to song 8 or 9, nothing happened, not even when other downloads finished, or when I tried re-queueing the files. After a seemingly random amount of time, three save dialogs popped up simultaneously. This is a confusing behaviour to the user, who often tries to queue the song again, resulting in multiple instances of the same file. Solution: always pop up the dialog and queue the files. If there is a max amount of simultaneous downloads that needs to be honored, this should be handled by the download manager instead. Other information:
I'm unable to reproduce this. Maybe this is problem when the response from the server is really slow?
If it is already supposed to work this way, then it might be possible. Other Browsers(TM) often have an artificial limit to the number of downloads, and I suspected this was the same case: When ququeing the 7 or 8 first ones the dialog came up instantly for each, while when reaching the supposed limit, nothing happened until a number of other downloads were out of the way. It didn't feel at all like it was a problem on the serverside, as the downloads also were as fast all the time. Unless of course, there's some clever rules on the serverside for simultaneous downloads. Of course, it also raises the question on how slow servers should be handled for downloads. When clicking normal links, the user gets visual feedback in different ways, here there's none at all if the dialog waits for a response. Guess I'll test some more, and I'd appreciate if someone who knows how the code is supposed to handle it chimes in, too. :)
After more testing on several sites (recommend http://www.machinaesupremacy.com/downloads.htm for the fine music =) I can indeed reproduce the symptoms, but I think Brent is correct that it is a server issue, so I reported the wrong problem. It was a bit of a special case when so many went well before the stall, I guess. Anyhow, while we are on the subject, I think that better feedback here would be very desireable; not even the throbber reacts when doing this. I was wondering if this is a feasible solution on "save as": * Always pop up dialog instantly. * Always add download to Download manager if user selects OK. * Let Download manager detect and report failed downloads. * Give the user the option to "Retry" failed downloads (same as resume, really?) This gives much better feedback to the use that the interface reacts to commands. It also works for both cases where the failure is instant or when it happens after a while. Instant failure gets treated slightly worse by having to go to DL Manager anyways, but I think the win in clarity for slower cases more than make up for it. Download manager could report failure by things like: * Setting background color of entry to red * Using a notify balloon * Using a warning or error icon instead of the file icon * Whatever grabs the users attention :) Comments please. :)
Looks like this is a duplicate of bug 170787?
Not really.... The problem here is that there's a maximum number of downloads per server (2 , afair). We should probably just queue the downloads in the dlmgr with status 'not started yet' instead of silently waiting until it's their time, though.
*** Bug 327121 has been marked as a duplicate of this bug. ***
*** Bug 444931 has been marked as a duplicate of this bug. ***
*** Bug 508981 has been marked as a duplicate of this bug. ***
OBSOLETE now that we don't have a mozilla backend anymore.
Nope, webkit backend is also affected. Just tested today with epiphany 2.30. Try downloading 5+ times openoffice (http://download.openoffice.org/contribute.html?download=mirrorbrain&files/localized/fr/3.2.0/OOo_3.2.0_LinuxIntel_install_wJRE_fr_deb.tar.gz) simultaneously, and you will see epiphany showing the 4th or 5th (and subsequent downloads) as "FAILED", and there is no way to make it recover afterwards (the pause/resume button is insensitive, you can only click Stop).
Created attachment 158143 [details] Working screenshot It works for me. Are you sure you're trying with the correct version of epiphany?
I just tried with Epiphany 3.8 on Fedora 19 and managed to launch 11 downloads of http://donate.libreoffice.org/home/dl/rpm-x86/4.1.3/fr/LibreOffice_4.1.3_Linux_x86_rpm.tar.gz at the same time without experiencing any problem. All downloads ran in parallel and completed successfully. I'm closing this as obsolete. Feel free to reopen if you can reproduce.