We accidentally did show the command as a list in to_str(). However, after
correcting that to use shlex.escape, we got ugly qutebrowser command lines
when tabbing to the default value, because of how shlex handles double-escaping:
>>> print(shlex.quote("gvim -f '{}'"))
'gvim -f '"'"'{}'"'"''
While in this case, outputting "gvim -f '{}'" would be much more appropriate, it
doesn't look like we can teach shlex.quote to do that.
Instead, we now only accept a list as input for ShellCommand, at the price that
the user needs to do
:set editor.command '["gvim", "-f", "{}"]'
instead of
:set editor.command 'gvim -f {}'
Fixes#2962.
There were two issues here:
- The comparison was backwards, causing scroller.at_bottom() to always return
true.
- When zoomed in, jsret['px']['y'] can be a float, which means we can be
slightly off when checking the difference - math.ceil() fixes that.
Trying to read from the sql database from another process was flaky.
This adds a debug-dump-history command which is used by the history BDD
tests to validate the history contents.
It outputs history in the old pre-SQL text format, so it might be
useful for those who want to manipulate their history as text.
Returning "next" was no longer possible as the SQL query does not fetch
more items than necessary. This is solved by using a start time, a
limit, and an offset. The offset is needed to prevent fetching duplicate
items if multiple entries have the same timestamp.
Two of the history tests that relied on qute://history were changed to
rely on qute://history/data instead to make them less failure-prone.
Calling sql.init() in version.version() would replace the existing sql
connection and cause a crash when accessed by opening qute://version.
Now version relies on sql already being initted, and app.py inits sql early if
the --version arg is given.
Two history end2end tests are failing because sqlite is not flushing to disk in
time to be read by the test process. My understanding is that sqlite should
take an exclusive lock while writing, so it is difficult to understand why this
is happening. This can be fixed by adding a delay, but that seems flaky.
I'm fixing it by checking qute://history instead of reading the database file.
See:
https://github.com/qutebrowser/qutebrowser/pull/2295#issuecomment-292786138
and the following discussion.
Now that sql is only used for history (not quickmarks/bookmarks) a number of
functions are no longer needed. In addition, primary key support was removed as
we actually need to support multiple entries for the same url with different
access times. The completion model will have to handle this by selecting
something like (url, title, max(atime)).
This also fixes up a number of tests that were broken with the last few
sql-related commits.
Change the logging to report the completion function name and have the end2end
tests check for this.
Remove the tests for realtime completion, as it was decided this is not an
important feature and the code is much simpler without it.
When we open a background tab, it gets a hardcoded size (800x600 or so) because
it doesn't get resized by the layout yet.
By resizing it to the size it'll actually have later, we make sure scrolling to
an anchor in an background tab works, and JS also gets the correct size for
background tabs.
Fixes#1190Fixes#2495
See #1417
In a48ea597d0 we fixed settings in private
QtWebEngine windows.
However, this means we also enable local storage for private windows, which was
disabled in QtWebEngine by default:
4ef5831a39 (diff-44ac7d27348388501944f6a8e2e67d8dR207)
It should be safe to enable it, as we get the same behavior as in Chromium, i.e.
a working local storage which entirely lives in RAM.
This also makes those tests work on QtWebKit-NG, presumably because private
browsing for cookies is implemented there.
It also adds a test to at least check whether local storage is isolated from
non-private tabs. I tried writing a test which ensures nothing lands on the hard
disk, but due to QTBUG-52121 this might not happen at all:
https://bugreports.qt.io/browse/QTBUG-52121
Turns out QWebEngineSettings.globalSettings() only sets things on the default
profile. We now get everything from the default profile settings, but set it on
both the default and the private profile.
Fixes#2638
(cherry picked from commit b11a4388cd10b6ff2fd917fca689ebdc50d581ae)
If we don't wait here, we might end up running the subsequent commands (like
:command-history-prev) on the old window while it's still closing, causing an
exception at least on AppVeyor:
Traceback (most recent call last):
File "C:\projects\qutebrowser\qutebrowser\app.py", line 110, in <lambda>
target_arg=target_arg))
File "C:\projects\qutebrowser\qutebrowser\app.py", line 265, in process_pos_args
win_id = mainwindow.get_window(via_ipc, force_tab=True)
File "C:\projects\qutebrowser\qutebrowser\mainwindow\mainwindow.py", line 89, in get_window
window.setWindowState(window.windowState() & ~Qt.WindowMinimized)
RuntimeError: wrapped C/C++ object of type MainWindow has been deleted
There's actually no good reason to filter javascript links as we might want to
click them (or copy their URL) just like any other link - this fixes#2404.
With that being gone, we don't need FILTERS at all anymore, as we can check for
existence of the href attribute in the CSS selector instead.
Looks like we get this sometimes:
----> Waiting for 'Clicked non-editable element!' in the log
14:02:14.976 DEBUG webview webkittab:find_at_pos:618 Hit test result element is null!
14:02:14.976 DEBUG mouse mouse:_mousepress_insertmode_cb:149 Got None element, scheduling check on mouse release
14:02:14.977 DEBUG mouse webview:mousePressEvent:299 Normal click, setting normal target
14:02:14.978 DEBUG mouse mouse:mouserelease_insertmode_cb:173 Element vanished!
This could happen for any of the attributes, but for tagName this actually
happens in the wild... Since elem.tagName is equal to elem.nodeName we just try
to use this.
Fixes#2569
Before, we just returned the same data for both, but then we'll run into
same-origin restrictions as qute:history and qute:history/data are not the same
host.
Problem 1: Entering a command of `:::save` gives an error.
Problem 2: Entering a command of `:save\n` gives an error.
Both scenarios may seem a bit silly at first, but I encountered both by
copy/pasting a command:
1. Enter `:` in qutebrowser.
2. Copy a full line from a terminal starting with `:`.
3. You will now have both of the above problems.
Solution: Trim all whitespace and `:` of a command. This is also what
Vim does, by the way.
This really tripped me up yesterday, My "Vim default" is to use tabs.
This (where `!···` is a tab) does not work as you'll hope it works:
Scenario: Retrying a failed download when the directory didn't exist (issue 2445)
When I download http://localhost:(port)/data/downloads/download.bin to <path>
And I wait for the error "Download error: No such file or directory: *"
And I make the directory <mkdir>
And I run :download-retry
!···!···And I wait until the download is finished
Then the downloaded file <expected> should exist
Examples:
| path | mkdir | expected |
| asd/zxc/ | asd/zxc | asd/zxc/download.bin |
Unfortunately, pytest-bdd uses the "Python 2 behaviour" of "expand all
tabs to 8 spaces", and doesn't give any errors on strange/inconsistent
whitespace. It can cause very confusing errors.
