This is needed when we want to display an error page after the user
requested a qute:// URL, as qute:// URLs can't access file:// content
with QtWebEngine.
From the QApplication.postEvent docs:
http://doc.qt.io/qt-5/qcoreapplication.html#postEvent
The event must be allocated on the heap since the post event queue
will take ownership of the event and delete it once it has been
posted. It is not safe to access the event after it has been posted.
We can't reliably guarantee that from Python, so we need to use
sendEvent instead.
With QtWebKit or QtWebEngine with Qt < 5.7, the functions end up in the
page's namespace. We can't easily avoid this, but at least we can name
them in a way which reduces conflicts.
webelem.javascript_escape got renamed to javascript.string_escape, and a
new javascript.assemble got added to make it easier to call a function
inside a .js file.
Running test_standarddir would pollute the user's home with
`~/.cache/qute_test`.
The `no_cachedir_tag` fixture was supposed to prevent this, but was not
working because [usefixtures does not work on fixtures]
(https://github.com/pytest-dev/pytest/issues/1014).
This fixes the fixture to actually prevent cachedir creation, but
applies it to tests individually (or by class) rather than with autouse
because the cachedir tests cannot pass if it is working.
Running the tests would create ~/.config/qute_test and
~/.local/share/qute_test on the user's machine. The test_standardir
module needed a bit more mocking to prevent it from cluttering the
user's machine.
Two tests that created the data dir were fixed by passing basedir in
args, and one test that created the config dir was fixed by patching
os.makedirs to a noop.
Per one of the diff comments on #1597:
> I used to use a tuple for constant things, but nowadays I'd actually
> prefer a list as a tuple is something more heterogeneous (i.e. it
> makes sense to have a `(x, y)` point as a tuple, but a list of points
> would be a list).
> At some point I should probably change it to a list everywhere 😉
For some reason the behaviour of QHostAddress("31c3").isValid() changed
with Qt 5.6.1: https://bugreports.qt.io/browse/QTBUG-53983
This causes the test to fail because Qt thinks this is a valid IP, so we
think it's a valid URL.
The check `key.startswith('<') and key.endswith('>') is repeated many
times in code to check for a special key. Replace all these with a call
to the same function.
colorlog was problematic for various reasons:
- Not commonly packaged for Linux distributions
- Calling colorama.init() automatically on import
- Not supporting {foo} log formatting
- Not supporting an easy way to turn colors off
Instead we now do the log coloring by hand, which is simpler and means
everyone will have colored logs.
We can get UndefinedError when a new function got added to the jinja
env (and gets called from a template) and the user did update the
on-disk templates but not restart qutebrowser yet.
In this case, let's show a special error page to the user and tell them
to do :report in the unlikely case it's actually a bug.
Fixes#1362.
See #1360.
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.
Before we raised QtValueError (via qtutils.ensure_valid), but maybe there are
more callers out there which call fuzzy_url with an empty input - and it makes
more sense to raise InvalidUrlError which gets displayed to the user than
raising QtValueError which is more like an assertion.
