The buffer_troubling_args tests may look a little un-intuitive but that is
because they are testing the edge cases for the current behaviour. If these
edge cases are encountered during normal usage you are doing something wrong.
Since XPath doesn't have a way to escape quotes (or any other
character), we have to use a workaround by using concat() and switching
between quoting styles.
The userscript is a bash script and there is no bash on windows.
One solution could be to use a python userscript, but there may be
other issues (file associations), too.
On windows, using '/' in pathnames won't work, so it's impossible to use
to describe a path in a feature spec. The solution is to move the path
logic out of the feature spec and hand it over to `os.path.join` in a
new custom step for userscripts.
Before this change, adding a new logging message involving logging e.g. the
default duckduckgo setting value failed.
Now we basically use a black- instead of a whitelist and only fail if we get a
load status message for duckduckgo.
Trying to get the device location while running the tests can trigger all kind
of funny effects.
Since we can't easily mock the GPS responses, we only run those on the CI where
we at least have some predictable setup.
Fixes#1297.
This is based on HTML files with a global YAML comment, currently with "target"
as the only allowed key.
The tests then do this:
- Open a HTML file in data/hints/html
- Start hinting
- Make sure only one hint is visible
- Follow it, and make sure the page mentioned in "target:" is reached
Some ideas for the future:
- A "scroll" key, to scroll before hinting
- A "zoom" key, to zoom
- Multiple hints via a list
- Checking position of hints?
- A mode to manually check the pages (to check hint positions)
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
When a end-to-end test failed which would've marked an error message as
expected later in the test, seeing the teardown message about an unexpected
error being logged is really confusing.
For some reason, when comparing the repr in the two processes, we get different
results on OS X and Windows:
- expected: "fünf"
- "f\xfcnf" coming back from the subprocess on OS X
- "fnf" on Windows
Instead we're comparing the json dump now, which should be more predictable.
There are a lot of problems and flakiness with using a real clipboard.
Instead we now have a :debug-set-fake-clipboard command to set a text, and use
logging when getting the contents.
Fixes#1285.
Otherwise, if a test fails to actually put something into the clipboard, we end
up pasting "Does this work?" which could e.g. trigger a search.
When it's cleared, we at least get some "clipboard is empty" error instead.
In the long run, we should detect any accidental external accesses using
mitmproxy, as per #1282. In the meantime, we try to detect duckduckgo requests
being logged and fail the tests if that happens.
However, a duckduckgo URL is logged in fuzzy_url during startup/config init,
which is why we ignore it there.
The-Compiler wants a more beautiful test case since the old one was
pretty weird and took lots of explaining at pytest demos, so I made a
new one. This one is a bit nicer on the eye and - to say it with
The-Compiler's words - has no "weird pixelated globe with the
geocities-like background".
To compensate for the globe I've put in some trivia facts so that - if
you are one of the people that like to stare at test pages - you can
always learn something.
After pressing the button to open a window, we have to wait until it's loaded
before continuing, otherwise the test is flaky:
http://www.qutebrowser.org/testresults/osx/1295.html
We can't simply wait with "wait until about:blank is loaded" as that page is
already loaded earlier.
This hopefully fixes this flaky error in test_notifications_with_ask__true on
OS X:
Failed: Logged unexpected errors:
LogLine('22:40:06 DEBUG js webpage:javaScriptConsoleMessage:531 [http://localhost:57758/data/prompt/notifications.html:28] [FAIL] unknown initial value for Notification.permission: denied')
[...]
testprocess.WaitForTimeout: Timed out after 15000ms waiting for {'message': 'Entering mode KeyMode.* (reason: question asked)'}.
This is a bit tricky since the test will actually run, but be marked as
skipped. The problem is we can't raise a pytest.skip.Exception during a test,
or it'll show up as an exception in a virtual Qt method.
Still this is better than nothing.
- The paste command will now open one tab/window per url if multiple
URLs (separated by newline) are present in the clipboard
- Adds the tests for the new multitab functionality
- Changes test/integration/conftest.py to be able to insert newlines in
the clipboard for the test
Using pytest.fail with pytrace=False hides the quteprocess output, which makes
it a lot harder to debug stuff.
This is because TestReport.longrepr is suddenly a string and we can't add infos
to it - see https://github.com/pytest-dev/pytest/issues/1316
- qtbot.waitSignal with raising=True is the default this way, so we remove the
raising=True.
- qtbot.waitSignal with raising=False stay untouched
- Some qtbot.waitSignal without raising had one added (because we don't want it
to raise)
- Some qtbot.waitSignal without raising actually should've raised, which they
do now.
For some reason I can't explain, since 2b0870084b
we got test failures on OS X, as the clipboard had the old value before waiting
for the change, the new (correct) value after waiting for it, but never
actually emitted 'changed'.
We could just re-check the contents after the timeout, but that'd mean we wait
1s for every test where this weird thing happens.
Instead, we poll the clipboard for every 100ms as long as the timeout (1s)
hasn't passed, and return as soon as it has the correct contents.
