If we don't do this, when doing:
self.config_stub.val.content.user_stylesheets = css_path
then _update_stylesheet gets called before the stylesheet QWebEngineScript did
run (as there was no load yet), so we get:
[:2] Uncaught TypeError: Cannot read property 'stylesheet' of undefined!
Instead, load the page first and then update the stylesheet.
This tests that live updating works properly, and also makes sure we don't run
into the problem described above.
Like the spec says, if a value for the @include or @exclude rules starts
and ends with a '/' it should be parsed as a regular expression.
Technically a ECMAScript syntax regular expression, but I am not sure of
the differences and I assume they are far fewer than the similarities.
One that I did see mentioned was that javascript RegExp doesn't support
unicode. Although it apparently does support a 'u' flag now.
Note that code will only be ran for QtWebkit and QWebEngine < 5.8
we rely on the builtin support for metadata it QWebEngine for most
things greasemonkey related. Sadly it seems that they missed the regex
requirement too. I've opened a ticket to track that https://bugreports.qt.io/browse/QTBUG-65484
- 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.
