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
Always interpret the first word in the command string as the command to
offer completions for, even if that word looks like a flag.
Fixes#3460, where the command string `:-w open` would attempt to offer
completions for `open` but crash because the parsing was thrown off.
By moving the flag-stripping logic to _after_ we determine the command,
`:-w open` interprets `:-w` as the command. Since that is not a valid
command, we won't offer any completions.
Update the description to mention the number of columns and change the
default to ["white", "white", "white"] to make it more obvious that
multiple colors can be specified. This also satisfies the config test
that expects the default value for ListOrValue types to be a list.
One other test had to be tweaked to use a config option that is still
just a QtColor rather than a ListOrValue.
While it is possible to provide just two colors, it is "undefined
behavior". It will use the first color as the third color, but that is
an artifact of the implementation and therefore not documented (though
also not an error, as it is harmless).
colors.completion.fg is now a list instead of a QColor. As this test
specifically wanted to test a QColor, I just changed it to a different
config option.
command-accept --rapid will run the command without clearing the prompt,
allowing "rapid fire" commands. For example, one could open completion
for `open -t` and open several tabs in a row.
The default binding is ctrl+enter.
Resolves#588.
I mistakenly checked the length of wheres instead of words. This fixes
that check, renames 'wheres' to 'where_clause' to be clear
that it is a string and not an array, and adds a test.
There are various small changes here:
- If the process is already finished, we don't try to terminate it.
- On Windows, we use QProcess::kill instead of QProcess::terminate, as terminate
will only work with processes which have a GUI loop.
- We assert that quitting the suprocess actually worked.
Fixes#3384
Perviously, 'foo bar' would match 'foo/bar' but not 'bar/foo'. Now it
will match both, using a query with a WHERE clause like:
WHERE ((url || title) like '%foo%' AND (url || title) like '%bar%')
This does not seem to change the performance benchmark. However, it does
create a new query for every character added rather than re-running the
same query with different parameters. We could re-use queries if we
maintained a list like self._queries=[1_arg_query, 2_arg_query, ...].
However, it isn't clear that such a complexity would be necessary.
Resolves#1651.
This test is supposed to ensure that user scripts don't run on iframes
when the @noframes directive is set in the greasemonkey metadata. It is
failing sometimes on travis but passing on local test runs. Personally I
haven't actually ran the whole test suite through, just the javascript
tests. It maybe be some stale state that only shows up when you run the
whole suite. It may be some timing issue that only shows up on travis
because ???. Hopefully this stops the red x from showing up on the PR.
For some reason, if we don't wait for about:blank to be fully loaded with
Qt 5.10, we get the next LoadStatus.finished notification with about:blank as
URL.
This is most likely caused by the changes in
https://codereview.qt-project.org/#/c/202924/
See #3003
