The strict_min_version
in GM 4.1 is 52.0
. This causes people using versions of Firefox which do suport legacy extensions (e.g. FF56 and 52ESR) to "upgrade" to 4.1. Many people who are on FF 52ESR, or continuing to use FF55/56, are on doing so specifically so they are able to continue to use legacy extensions.
The legacy version of Greasemonkey is far more functional than the 4.x version, and always will be. People running versions of Firefox < FF57 should not be auto-"upgraded" to Greasemonkey 4.x.
Thus, the manifest.json should have:
"strict_min_version": "57.0"
While users can choose to disable auto-updates for GM, or extensions in general (i.e. this strict_min_version
setting can be worked-around on a profile by profile basis), GM4 is not really an "upgrade". Most users consider it to be a downgrade. Users should not be auto-upgraded to GM4 when using GM4 is not required by the lack of support for legacy extensions in the Firefox version they are using.
I think the min version setting is an artifact of the period of time in which the 3.x version has an embedded WebExtension to facilitate script migration. Without lowering it I don't believe the addon would install properly.
4.1 was pushed with a lower minimum version, _oops?_. I don't think this was done to 'purposely force' people onto 4.x, and the hostility in the post is uncalled for.
@Sxderp No hostility was intended. I'm sorry that it sounded that way. Even re-reading what I wrote, I'm not entirely sure which part(s) you're considering hostile. So, I've edited it, guessing (in part) what you felt was objectionable.
Please note that while I did say "forced" (which I intended only as a description of what happens to users), I did not say "purposely force" (which would have indicated I was ascribing some intent behind the setting, which I was not trying to do). [You've got me second guessing myself. I don't think I said "purposely force", but now that I've edited the original comment, I can't 100% verify it, because as the author of the post I don't get an email with the contents. If I did, I'm sorry. It was not intended.]
Note: While I do have negative feelings towards Mozilla surrounding the cut-over to WebExtensions-only, I feel that people involved with GM are handling well the situation in which Mozilla has placed them. That includes having to deal with the large number of people that blame extension writers for things which are completely the Mozilla's fault.
eyep, I've "frozen" my FF at v56 and now with GM4.1 I'm getin some obscure errors like "Error: Permission denied to access property "nodeType""
on very simple scripts.
I'm getin some obscure errors like
Userscripts are run in a 'content script' context. If objects / functions are declared in this context they need to be cloned to the window before they window can access them. Mozilla implemented this security feature and it prevents leakage into the page scope.
@Sxderp yeah, I've already read in the update notes that unsafeWindow
works somehow differently and one should use exportFunction() or cloneInto()
and links the same article you did (which explains how to write extensions, not userscripts)). Nobody is giving any examples how to actually do it in the userscripts. But thats beside the point. The point is FF<=56 doesn't suffer from this whole retardation so there is no reason to force it.
Nobody is giving any examples how to actually do it in the userscripts.
Pretty much exactly the same. If someone says 'content script' replace it with 'userscript'. Proceed as normal.
As for example, here is something I posted some time ago.
Further, if you use window.eval()
the argument will be run directly in the page scope without having to deal with exporting.
thanks. as for eval()
- eval is evil and the first rule of using eval is "don't use eval".
@Spown IMO, exportFunction()
and cloneInto()
should be avoided, because they are Firefox only. A significant benefit of both userscripts and WebExtensions is that they can be run in various different browsers. There are a variety of ways in which you can execute code in the page context. The way I do it in both userscripts and content scripts is a function, executeInPage()
, which you can find in this answer on Stack Overflow. It allows you to pass parameters to the function you are calling, cloning those parameters into the page context. With a simple function that assigns the parameter value passed to a variable in the window context (e.g. window[variableName]
), you can easily do what cloneInto()
does.
It's not as flexible as cloneInto()
, as it only handles Object
, Array
, function
, RegExp
, Date
, and/or other primitives (Boolean
, null
, undefined, Number
, and String
, but not Symbol
).
@Sxderp this all may be true, but I don't really care as I choose not to partake in this whole thing by not updating to FF>56. But it still seeps through like in this case.
BTW, trying to reuse page's jQuery in my script (which returns the aforementioned error) like you did in your example still yields the same error. nvm
I think the impetus is on you to install the version of Greasemonkey you want and then turn off auto-update.
If I upgrade to Greasemonkey 4, is it possible to install Greasemonkey 3 to downgrade and continue using that, if I want? Or does Greasemonkey 4 make changes that are irreversible?
@garyking you should be able to downgrade without problem. Script files should remain.
Most helpful comment
I think the impetus is on you to install the version of Greasemonkey you want and then turn off auto-update.