Migrate “GM_*” calls to Greasemonkey 4’s “GM.*” API

[roryokane]

See Greasespot: Greasemonkey 4 For Script Authors.

Greasemonkey 4 introduced new APIs for the functionality provided by GM_ functions. As the blog post says, these APIs will eventually be faster than the old APIs. The new APIs also have clearer names and better organization.

Currently, this script uses these GM_ functions:

webcomic_reader/webcomic_reader.user.js

Lines 54 to 59 in 26a1f6e

	// @grant GM_getValue
	// @grant GM_setValue
	// @grant GM_deleteValue
	// @grant GM_xmlhttpRequest
	// @grant GM_registerMenuCommand
	// @grant GM_openInTab

Steps to migrate:

• Rewrite the code’s GM_ function calls to use the asynchronous GM. equivalents.
• Update the @grant comments
• @require the polyfill, allowing the script to continue working with Violentmonkey, etc.

I haven’t tested this script in Greasemonkey 4, but Greasemonkey 4 For Users implies that any functionality that relies on the @grants above will not work in Greasemonkey 4 until those calls are migrated. Since GM_xmlhttpRequest is one of the grants, it is likely that the core functionality of this script is broken in Greasemonkey 4.

[anka-213]

The code is currently constructed in a fairly synchronous way and may require a major rewrite to completely get rid of the synchronous calls.

[SoraHjort]

My 2 cents:
It might be unneeded to do a rewrite. Or at the very least, not worry about it for quite a long while.

• Greasemonkey still works with the script. While they have said that they will phase out the old API at some point, the last update for the addon was back in 2021, so it's development is at best on hiatus.

• Tampermonkey still works. They also tends to notify you of things they're going to phase out in their built in editor. So far, they haven't warned about the old API calls. But have been warning about needing @includes being changed over to @match. (On my list of things to check and do.)
  Checking their changelog shows they're even fixing bugs related to the old API, so probably not something that is going to be phased out any time soon.

• ViolentMonkey also still works. They haven't said anything about phasing out the old API. They did add in support fort he 4.0 API a while back, but documentation still largely points to GM_ * calls, with the GM.* calls getting a footnote at the bottom. (Also oddly they make better quick notes which calls are async than greasemonkey's own docs)

• The script actually doesn't appear to need the @grants. Taking them out causes the script to use fallbacks it has to where it's reading and writing to local storage via a different method. They are there for ease and compatibility.
  The @xmlhtmlRequest is strictly related to an old experimental labeled feature for base64 images. To prevent browsers from unloading the images. No clue if anyone actually uses it, I should check to see how that works. And whether it's something worth keeping. It is also part of the initial init 11 years ago. And browsers have changed a lot since then and may not even need such a feature anymore.
  Of course the register commands don't work when taken out. But that's a little minor issue since that just adds menu commands from the addon's window.

As is, I think we should be unconcerned of needing to change when two of the three main engines haven't stated plans to phase out the old API. Which maybe is not the wisest of statements.

Even if Greasemonkey were to update after years of hiatus, and removed the old API completely, it'd probably be best to recommend using one of the other two. Not only because the script still works on them, but both are built for multiple browser engines. Greasemonkey's hold is Firefox only. I also don't think the other engines have incentive to remove the API since that would kill a lot of old scripts that don't get updates anymore.

Also, on a personal annoyance note, in it's current state, Greasemonkey's built in editor is terrible to do any live troubleshooting with. It would freeze up the whole extension when I would go and select all to paste a new version of the script into. Requiring task killing firefox itself to get it to stop. It ended up being quicker to just uninstall the script and creating a new one every time.
Also it intercepts ctrl-f to do their own built in search function, which... finds the next result and then closes the search. So if you press enter more than once, well there went a line of code.

That personal note aside, let's worry about a rewrite when the others state plans to phase out. It should keep working regardless. Keep the issue open incase when that happens it manages to also break the fallbacks. But as is, I'm not inclined to believe it'll occur any time soon.