Hopefully closes#3627
This feels like fixing the symptom instead of the problem but I am not
sure how such a situation would arise. Never the less, the crash logs
clearly show that `_inject_userjs()` is being called with a deleted
frame sometimes. It is being called from a closure that gets triggered
on frame.loadFinished so I am not sure how frame could be deleted at
that time unless:
* the error message is misleading and it is actually some reference to
the object that is no longer valid
* the frame gets deleted from some other handler of loadFinished.
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.
Apparently the currently available QtWebkit's javascript engine doesn't
support Object.entries[1]. It was only using that because I had copied
it from the official gm4 polyfill (maybe I should open an issue there?).
Tested with libqt5webkit5 version 5.212.0~alpha2-5 (debian) and I was
getting the same type of failures as Travis so it looks like this is the
case in arch too.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/entries
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.
Based on the gm4-polyfill.js script from the greasemonkey devs. But not
the same because that script doesn't work for us for a couple of
reasons:
* It assumes all GM_* functions are attributes of `this` which in
this case is the global window object. Which breaks it out of our iife.
It is possible to change what `this` is within the iife but then we
would have to do something weird to ensure the functions were available
with the leading `this.`. And I don't think user javascripts tend to
call GM functions like that anyway, that polyfill script is just making
weird assumptions and then claiming it'll work for "any user script
engine".
* It tries to provide implementations of GM_registerMenuCommand and
GM_getResource text which do unexpected thins or implement a circular
dependency on the new version, respectively.
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.
When min_chars is nonzero, if the first command that opens the
completion has < min_chars on the word under the cursor, it triggers a
check for a condition where last_cursor_pos is None.
By setting last_cursor_pos=-1 we ensure that the completer always
updates the first time it is opened, and that there is never a check
against None.
This adds a test for the min_chars feature.
Resolves#3635.
