The test was failing because of two reasons:
First, the old code had filename questions in DownloadManager.get and
DownloadManager.fetch which were almost identical, thus the part in
DownloadManager.get was removed in an earlier commit. All filename
asking is now done by DownloadManager.fetch. The good part is code
deduplication, the bad part is slightly modified behavior: The new code
doesn't wait for a filename to start the download, instead it tries to
fill the buffer immediately. This made the test fail because qute:// has
no registered handler, so in order for the test to pass now, the "no
crash" part is not enough, we also need to expect the "No handler"
error.
Secondly, and a rather rare (race) condition was the handling of errors
in the DownloadItem. If an error occured after the registration of
self.on_reply_error as error handler and before the check
reply.error() != QNetworkReply.NoError
at the end of the function, the error signal would be emitted twice:
Once by _die() (called by on_reply_error), and once by the init_reply
function directly (in the last if block). This lead to duplicated error
messages. This is also explained in a comment in the file (with small
"stack traces").
When a redirect occurs, the item is saved in history with a -r suffix
now. When opening qutebrowser that's picked up and the item is hidden
from completion.
This makes it possible to switch to an alternative implementation if
there are weird issues like #1568. Some users might also prefer the
slightly better performance over more accurate hints.
For some reason, sometimes on Travis the history file we read is empty.
I have no idea why though, as we successfully wait until ":save saved
history" is logged, and that is working fine.
Let's just mark the test as flaky for now so we can move on.
Clicking actually works fine without the strip() as _resolve_url is
never called in that case, so we need to do something which actually
needs the URL as well.