GM4/FF57 compatibility fixing. An alternative approach...

تم تعديل 2017/11/18 في التطوير Firefox
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.


  • They make us to be luddits
    239 x 211 - 14K
  • تم تعديل 2017/11/17 Firefox
    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?
  • تم تعديل 2017/11/21 Firefox
    Well, getResourceText() could maybe be implemented using getResourceUrl() 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 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...
  • تم تعديل 2017/11/21 Firefox
    FYI, I have edited above answer. On second thoughts the road is bit more bumpy than my first thoughts made it...
  • تم تعديل 2017/11/21 Chrome

    There's just the problem with xmlHttpRequest, that it "returns" content via a callback method

    You can use a sync XMLHttpRequest by setting 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.