Yep, I know about @require. That’s not an option for Jitai, though - it needs access to the instance of jQuery that the page uses. Not to mention, it worked fine in previous versions of Greasemonkey. Despite that, this is not listed as a “breaking change” in the blog posts, so… looks like it’s a bug.
I wasn’t talking about @require. Greasemonkey has implemented sandbox support. IDK if its new or old. But it might be isolating your script execution env.
The sandbox has been around for a good while now. It’s possible that they’ve changed how it works, but if so, they haven’t mentioned it… 
1 Like
If your really wanna update jita to support GM 4, please keep it separate from current edition. Becuase most of the scripts don’t support GM 4 yet and many users here probably won’t like to have two different script injector addons.
Oh, no, I won’t make any changes that’d make Jitai incompatible with other popular userscript addons (like Tampermonkey, for example). If I update it, it’ll only be in a cross-compatible way. I think this might be a bug on the Greasemonkey side, though, so first of all I’ll wait to see if they do anything about it.
1 Like
@Obskyr Of course I understand that. But sometimes thinks look weird.
I installed Violentmonkey and my ten favorite scripts. All seem to work fine. That means it’s possible !
I’ve gotten an official response on the GitHub issue I opened (ping @rfindley)!
It seems Greasemonkey are prioritizing security over usability here. Basically, there are two levels of script execution in Firefox nowadays: “page scripts” and “content scripts”. Violentmonkey (and I assume Tampermonkey, although I haven’t checked) inject userscripts by creating and inserting a <script> tag. This means they run on the page script level, together with whatever scripts are on the page initially. Greasemonkey 4 instead uses a new Firefox API, tabs.executeScripts(), which means they run as content scripts. Content scripts run in a different scope, so accessing page-level variables isn’t as simple as it used to be. It’s supposed to be possible, but I haven’t quite gotten it to work myself.
At the moment, the official word on Greasemonkey is the following:
At this point, I’ve got a plan for how to improve this, but it’s waiting on Mozilla to implement a feature that would make it possible to do securely.
So it looks like it might be a while before Greasemonkey achieves cross- and backward compatibility again.
1 Like
^^^
Hmm… I hope this hiccup doesn’t kill off GreaseMonkey’s user base. In my understanding, the whole point of @grant none was to allow a script to run in the page context by not using any of the security-risky GM_* commands. I don’t use any GM_* stuff specifically for that reason.
Same here. The reasoning behind this choice seems to be about “potential security holes” as opposed to known issues. In my eyes, that isn’t the best reason to make a breaking change like this, but… I suppose what I think won’t change their decision.
I do hope we won’t have to write code specifically cross-compatible with content script scope in the future. That’d lead to things like var $ = $ || window.wrappedJSObject.$ (although I can’t say for certain how it’d look, since I haven’t gotten it to work).
1 Like
FF was completely rewritten and now loads 2x as fast as Chrome (on my PC at least) and all of my extensions and scripts work again after just updating them. Took 3 minutes.
1 Like
That’s great if you use extensions that are getting updates, but many of the ones I rely on are not being updated. Even just the fact that there’s no Tab Mix Plus is enough to render FF57 an inoperable browser for me (lack of tab management options is why I don’t use Chrome in the first place). And that’s just one of the extensions I’d lose. Scrapbook would also be a massive blow as I have thousands of pages saved and indexed that are super crucial to some projects I work on. The new limitations on mouse gestures on internal pages are also highly annoying. And so on.