| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Fixes #6353
|
|
This is already done in GreasemonkeyScript.__init__.
|
|
|
|
|
|
|
|
Closes #6015
|
|
See #6023
|
|
See #6023
|
|
|
|
fixes #5615
|
|
|
|
|
|
The type comments have also been changed to annotations, since Python
3.5 support will be dropped with the next release.
See #5396
|
|
- Use utils.Unreachable instead of NotImplementedError (which has a kind of predefined
meaning for abstract methods):
https://docs.python.org/3/library/exceptions.html#NotImplementedError
- Add additional asserts/conditionals for all places checking for a backend.
|
|
|
|
See #640
|
|
|
|
|
|
|
|
|
|
|
|
See #4322
|
|
|
|
|
|
|
|
|
|
See e.g. https://github.com/jerone/UserScripts/issues/135
|
|
Previously calling `script.code()` would fail if the script didn't have
a `name`. This wasn't being hit in practice because the only place that
constructs GreasemonkeyScripts was checking for that condition and add
the filename there as a fallback.
This change make the `name` attribute more explicitly mandatory by
failing with a `ValueError` if it is not provided and make it still
possible to use the filename fallback in that case by adding a
`filename` keyward argument to `__init__()`.
Additionally where `script_meta` is used in `script.code()` a fallback
to and emptry string was added so it doesn't fail for raw javascript
files without greasemonkey metadata.
|
|
|
|
QtWebEngine (via chromium) has the ability to run injected scripts in
isolated "worlds". What is isolated is just the javascript environment,
so variables and functions defined by the page and the script won't
clobber each other, or be able to interact (including variables saved to
the global `window` object). The DOM is still accessible from "isolated"
scripts.
This is NOT a security measure. You cannot put untrusted scripts in one
of these isolated worlds and expect it to not be able to do whatever
page js can do, it is just for namespacing convenience. See
https://stackoverflow.com/questions/9515704/insert-code-into-the-page-context-using-a-content-script
for some examples of how to inject scripts into the page scope using DOM
elements.
Now you can specify the world ID in a `@qute-js-world` directive like:
```
// ==UserScript==
// @name Do thing
// @match *://some.site/*
// @qute-js-world 1234
// ==/UserScript==
document.body.innerHTML = "<strong>overwritten</strong>"
```
The QtWebEngine docs say worldid is a `quint32` so you can put whatever
number (positive, whole, real) you want there. I have chosen to allow
the `qutebrowser.utils.usertypes` enum as aliases for IDs that are
predefined in
`qutebrowser.browser.webengine.webenginetab._JS_WORLD_MAP`. So you can
pass `main`, `application`, `user` or `jseval` in there too. `main` (0)
is the default one and is the only one in which JS disabled when
`content.javascript.enabled` is set to `false`. All others are still
enabled.
I'm not sure whether using any of those already-named worlds makes
sense, apart from `main`. We could stop people from using them I
suppose. Another option is to allow people to pass in `*` as a value to
have scripts put into their own little worlds, probably backed by a
counter in the GreaseMonkeyManager class.
Chrome docs: https://developer.chrome.com/extensions/content_scripts#execution-environment
Webengine docs: https://doc.qt.io/qt-5/qwebenginescript.html#details
|
|
Since the JSCore used by WebKit 602.1 doesn't fully support Proxy and I
can't think of a way to provide isolation otherwise just revert to the
old behaviour in that case. I am checking for the specific WebKit
version because I'm pretty sure that version just happened to be
released when Proxy support was only partially done, any later release
will presumably have a newer JSCore where it works.
There I changed the indentation of a block in the jinja template which
will have inflated the diff.
I added mocking of `objects.backend` to the `webview` and
`webenginewebview` fixtures, I am pretty sure they are mutually
exclusive so don't expect any issues from that.
Because of the feature detection being at template compile time I had to
tweak the test setup to be done via a fixture instead of the setupClass
functionality that I was using before.
|
|
|
|
|
|
The greasemonkey `@match` directive is used to match urls against
chromium url patterns (as opposed to `@include` which treats its
argument as a glob expression). I was using fnmatch for both here
because I am lazy and knew someone else was going to implement chromium
url patterns for me eventually. Now it is done and I should switch to
using them instead. The most common failing case that this will fix is
something matching on `*://*.domain.com/*` because it wouldn't match
the url with no subdomain.
This codepath is only used on webengine 5.7.1 and webkit backends.
|
|
Greasemonkey scripts are supposed to default to running on all pages.
@jgkamat and @nemanjan00 repurted some script not running on all pages
unless they either removed (or broke) the metadata block or added an
include directive. Indeed I had a logic error when it only defaulted to
being included on all pages when no metadata block at all was included.
Whoops.
|
|
|
|
|
|
Previously to add a greasemonkey script you had to write it to the
greasemonkey data directory and call load_scripts(). Now you can just
make a new GreasemonkeyScript and pass it to add_script(), yay.
There are no users of the method yet although I could have used it while
writing the tests.
|
|
When `@require`ing local files (with the `file://` scheme) the
greasemonkey manager was not catching the DownloadItem.finished signal
because it was being emitted before it had managed to connect.
I didn't see this happening while testing with files that should have
been in cache but I wouldn't be surprised.
I had to change the download mock to be able to give it the appearance
of asynchronicity. Now when using it one must set download.successful
appropriately before firing download.finished. I also added a list of
downloads to the stub so a test could enumerate them in case the
unit-under-test didn't have a reference to them.
|
|
This is for the case where a script uses `@require` to pull down another
greasemonkey script. Since QWebEngineScript doesn't support `@require`
we pass scripts to it with any required ones pre-pended. To avoid
QWebEngineScript parsing the first metadata block, the one from the
required script, we indent the whole lot. Because the greasemonkey spec
says that the //==UserScript== text must start in the first column.
|
|
Added a new argument to the greasemonkey-reload command to support
also re-downloading any `@required` scripts.
|
|
This is to support the non-interactive use case of setting a
`FileDownloadTarget` and passing auto_remove and not caring if the target
file exists or not.
An alternative to adding the attribute to `FileDownloadTarget` and
having set_target pull it out would be to add a new param to `fetch()`
and `set_target()`. But it would only be used for one target type
anyway.
|
|
|
|
The greasemonkey spec states that user scripts should be able to put the URL
of a javascript source as the value of an `@require` key and expect to have
that script available in its scope. This commit supports deferring a user
script from being available until it's required scripts are downloaded,
downloading the scripts and prepending them onto the userscripts code before
placing it all in an iffe.
TODO:
* should I be saving the scripts somewhere else? Maybe the cache dir?
The are just going to data/greasemonkey/requires/ atm.
|
|
|
|
|
|
Apparently is is not an unusual situation to leave it unset and rely on
the default. Logging a warning about this could be unnecerasily
confusing for users.
I'm leaving the log message in there if it is set to something weird
like `window-load` or `document-complete` which scriptish may support.
|
|
Moving `QUrl.toString()` out of the `_match()` function which is called
for every pattern in every stript seems to make it ~40% faster.
|
|
Sometimes I don't read specs so good.
|
