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.
shellcheck recently added SC2330 checking for this. "which" is non-standard, and
not guaranteed by POSIX to have a meaningful exit status, while "command -v" is
specified by POSIX: https://stackoverflow.com/q/592620
On some pages like Qt's Gerrit, Indiegogo or Telegram Web, this caused a crash
with QtWebEngine and Qt 5.10.1 in
QtWebEngineCore::WebContentsAdapter::webContents().
I'm not sure what causes the crash exactly, but I'm guessing it's some kind of
race condition between loading the URL initially and deserializing the history,
which both ends up loading the URL.
Since restoring the history means we end up on the given URL anyways, let's just
not open the URL beforehand, which seems to fix this.
Fixes#3619.
