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.
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
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.
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.
