When `@require`ing local files (with the `file://` scheme) the
greasemonkey manager was not catching the DownloadItem.finished signal
because it was being emitted before it had managed to connect.
I didn't see this happening while testing with files that should have
been in cache but I wouldn't be surprised.
I had to change the download mock to be able to give it the appearance
of asynchronicity. Now when using it one must set download.successful
appropriately before firing download.finished. I also added a list of
downloads to the stub so a test could enumerate them in case the
unit-under-test didn't have a reference to them.
This refactors the whole web(kit|engine|) settings mess a bit so there's a
Web(Kit|Engine)Settings object for (non-static) settings set on a
QWeb(Engine)Settings object in Qt. Everything else is set on module-level a bit
less declaratively.
The whole inheritance mess is gone, and we can now also construct a
Web(Kit|Engine)Settings object for a given tab.
Fixes#2701
We originally made it per-window in b502280c06 for
issue #228, but that was back when we still needed window IDs for stuff like
message.info.
Nowadays, there's no reason for it to be per-window anymore. The rest of the
download code can deal with one global download manager (because QtWebEngine has
one), and apart from QNAM code which wasn't used here anyways (as tab_id=None)
there was nothing using the window ID anymore.
Also see #3456 which was the original motivation for this change.
This also renames 'strict' to 'compiled' to be more descriptive.
It also fixes a crash when starting qutebrowser with an older compiled Qt
version which was introduced recently (calling setSpellCheckEnabled).
Previously, a successful import of the text history into sqlite would
move 'history' to 'history.bak'. If history.bak already existed, this
would overwrite it on unix and fail on windows.
With this patch, the most recently imported history is appended to
history.bak to avoid data loss.
Resolves#3005.
A few other options I considered:
1. os.replace:
- fast, simple, no error on Windows
- potential data loss
2. numbered backups (.bak.1, .bak.2, ...):
- fast, no data loss, but more complex
3. append each line to the backup as it is read:
- more efficient than current patch (no need to read history twice)
- potentially duplicate data if backup fails
