Apart from checking for buttons with an href attribute (which made no sense at
all and should never return any element) this was identical to
webelem.Group.links.
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.
With coverage 4.4, the source name (qutebrowser/) is not added to the filename
anymore. To adjust for that, we remove qutebrowser/ from all paths, and also
make sure to remove it from what coverage returns (in case someone is running an
older version).
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
This allows users to change the size of the favicon independently from
the size of the font/tab, in order to adjust the balance between
favicons and text. The drawing code is also adjusted to place the icon
relative to the text center, rather than the text top.
Works as expected even for values of 0.0 (which is equivalent to hiding
the favicon completely).
Closes#2549.
This benchmark was running very quickly due to an improper setup.
The current history implementation expects that a newly inserted entry must
be more recent than any existing entries and sorts according to this
assumption.
The benchmark test inserts increasingly older entries, breaking this invariant.
When run in the benchmark, the qute://history/data implementation would
see an entry older than the oldest time in the time window and would
immediately return with a single "next" entry.
This patch inserts data in an order that mantains history's invariant and adds
a sanity-check at the end of the test. It does not check for the exact length
as not all entries will be within the time window. The length will be some
values <= 100000, the check just ensures that there is at least something more
than a "next" entry.
Before:
---------------------------------------------- benchmark: 1 tests ----------------------------------------------
Name (time in us) Min Max Mean StdDev Median IQR Outliers(*) Rounds Iterations
----------------------------------------------------------------------------------------------------------------
test_qute_history_benchmark 9.3050 21.9250 9.6143 0.2454 9.5880 0.1070 230;360 9930 1
----------------------------------------------------------------------------------------------------------------
After:
-------------------------------------------------- benchmark: 1 tests -------------------------------------------------
Name (time in ms) Min Max Mean StdDev Median IQR Outliers(*) Rounds Iterations
-----------------------------------------------------------------------------------------------------------------------
test_qute_history_benchmark 220.7040 223.1900 221.7536 1.1070 221.1939 1.8803 1;0 5 1
-----------------------------------------------------------------------------------------------------------------------
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.
