They make us to be luddits
Thankyou for this, I may give it a try when I have time :)
EDIT: Oh, I saw your note on GM_xmlhttpRequest ... my script also uses this, and not on the same domain.
GM without xmlhttpRequest to other domain is perfectly safe and absolutely useless
In GMC it should be possible to make a version of xmlhttpRequest for use on the same domain. It is on my todo.
BUT if you need to call services on other domains, I believe the only solution is to use the native GM.xmlHttpRequest() offered by GM4.
Actually, what I wrote just above might not be true. I have never used xmlhttpRequest myself, so have to take a closer look at how it works first. But I think it was a blunder saying I can only make a GMC.xmlhttpRequest() function for same-domain use. I think it would be possible to create a GMC.xmlHttpRequest() function working like GM_xmlhttpRequest(), but utilizing either GM.xmlHttpRequest() or GM_xmlhttpRequest() for cross-domain support. I'm putting it on my todo to take a closer look at some time...
And xmlHttpRequest() support is now added to latest version of the GMCommonAPI.js. Should work cross-domain too.
Don't know what I was thinking not having this included from the start :-)
Thanks for looking into that... :)
My next problem is there doesn't appear to be any support for GM_getResourceText() ... any suggestions?
Well, getResourceText() could maybe be implemented using getResourceUrl() GM.info metadata and xmlHttpRequest().
I will look at it for a future version of GMC, but if you will do it yourself I would say you can parse GM.info.scriptMetaStr to find the URL (using getResourceUrl() directly is probably a bad idea, xmlHttpRequest() probably wouldn't like it, if it got an URL for a locally cached resource - or maybe?) and use that to get the content with xmlHttpRequest(). There's just the problem with xmlHttpRequest, that it "returns" content via a callback method. It complicates it. And maybe makes it impossible to make a "straight" getResourceText() method in a nice way...
OK thanks!
FYI, I have edited above answer. On second thoughts the road is bit more bumpy than my first thoughts made it...
There's just the problem with xmlHttpRequest, that it "returns" content via a callback method
You can use a sync XMLHttpRequest by setting xhr.open third parameter to false. This is officially deprecated but works (the warning is spammed into the console though) and arguably will work for the foreseeable future.
@wOxxOm said:
> You can use a sync XMLHttpRequest by setting xhr.open third parameter to false
and which param should I set if I'm using GM4 GM.XMLHttpRequest?
@wOxxOm said:
> You can use a sync XMLHttpRequest by setting xhr.open third parameter to false
and which param should I set if I'm using GM4 GM.XMLHttpRequest?
I'm not sure if it's possible. But if, maybe there's some help to be found here:
https://github.com/greasemonkey/gm4-polyfill/pull/8
https://github.com/greasemonkey/greasemonkey/issues/2548
https://github.com/greasemonkey/greasemonkey/issues/2648
I would love to know if you are able to get something "truly synchronous" to work :-)
why is greasemonkey doing this anyway? cant they just wrap the functions internally if firefox changed
@elypter
I think they have prioritized to make a userscript manager with optimal performance and security in the new extension model, rather than simulate GM running in the old extension model. One of the arguments being that we already have Tampermonkey and Violentmonkey being 99% compatible with the old Greasemonkey.
Ok, let's face it, GM4 is dead, nobody'd want it anymore anyway
TM is left as the only big player on the market + some forks with little to no userbase
GM4/FF57 compatibility fixing. An alternative approach...
So, Greasemonkey 4 doesn't support the usual GM_* API. Instead it offers a new asynchronous GM.* API. This means that many userscripts using the old API, needs to be modified for compatibility with "both worlds". Probably no secret if your are a Greasemonkey user yourself, or if you've had a look at the "Scripts discussion" forum in the last couple of days.
The recommended way forward (and undoubtedly the most powerful and flexible) for script authors, is to adapt the asynchronous coding style and use something like gm4-polyfill to ensure compatibility with the other userscript managers and their "legacy" GM_* API. This might however not be a fast or easy task done for everyone, so some might look for something simpler...
I have created a library, GM Common API (GMC), which makes a subset of the functionality from the other two APIs, available in one "classic synchronous API". It works with scripts running in both the new Greasemonkey 4 and running in the other userscript managers. It is also available on Greasy Fork. I have used this library myself to make my own userscripts compatible with Greasemonkey 4 (Except Flickr Fixr, which currently doesn't need features of the APIs). If the features in GMC covers your needs, I think it is a much easier and faster way to GM4 compatibility.