Issues #1269, #866
qutebrowser would crash when XDG_DOWNLOAD_DIR was set to some
non-absolute value (which should not happen, but it can) and
"storage -> download-dir" was empty, since when the user didn't give an
absolute filename, even the joined path of download_dir() (i.e.
XDG_DOWNLOAD_DIR in this case) and the filename was not absolute either.
Since the path was not absolute, create_full_filename returned None,
which meant that os.path.basename(self._filename) raised an exception.
Now we display an error message and fall back to $HOME.
Issue #1214
Now uses a sensible filename for data: links instead of the whole base64
content. For PDF.js, it even uses the correct pdf filename.
TODO: Produces "QPainter:🔚 Painter ended with 2 saved states" while
running the tests here (Arch Linux):
CPython: 3.5.1
Qt: 5.5.1, runtime: 5.5.1
PyQt: 5.5.1
Fixes a bug where the user would be asked twice for a filename when
using :download without a dest-argument.
The problem was that we unconditionally overwrote filename, even if one
was given, thus discarding any "filename-finding-process" that we had
and asking the user again.
With ui -> remove-finished-downloads set to -1, when a download was started
with auto_remove=True (like with :adblock-update), there was a QTimer set up
with timeout -1, which causes this instead of doing something sane:
WARNING: QTimer::singleShot: Timers cannot have negative timeouts
Instead of being a boolean value indicating whether or not to instantly remove
downloads when they finish, it's now an integer value representing the
number of milliseconds to wait before removing downloads when they
finish. The default value, -1, means that the downloads will not be
removed when they finished. This is the same behavior as the previous
default value of false.
When giving the path to a FIFO or other special file qutebrowser would
completely hang, and has to be killed.
Tested:
- Asks for overwrite: file, symlink to file
- Saves in dir: dir, symlink to dir
- Aborts: block dev, char dev, fifo, socket, and a symlink to all of these
When downloading a bunch (7 or 8) of files I noticed qutebrowser was using a lot
of CPU (>60%).
I did some looking, and in the `downloadProgress` callback qutebrower emits the
updated signal which causes everything to be updated. We don't really need this,
since _update_speed() calls it every 500ms anyway.
I tested by downloading 3 copies of the 1GB file [on this
page]( http://www.thinkbroadband.com/download.html ) qutebrowser consistently
pulls about 25% CPU on my system.
When removing this call, the system pulls about 17% CPU. Not a great amount, but
still significant enough to warrant a pull request ;-)
Some other notes:
- wget uses about 1.5%-2% for each process when downloading.
- When not doing any UI updates & speed calculations qutebrowser uses about 15%.
- Doing some quick profiling and strategic commenting seems to indicate there
isn't any other low hanging fruit to be improved on here.
