Greasemonkey 4 / Firefox Quantum compatibility

[mastacheata]

Hello,

Greasemonkey changed their Userscript API to a backwards incompatible format.

Basically all the GM_* functions gone and now available as methods on the GM object. (Except for stuff like _addStyle, _registerMenuCommand and _log, which are gone without any internal replacement)

While your script is still compatible due to having alternatives to all the GM_ commands in it, it would sure be nice to just move to the GM4 API and pull the polyfill in for older versions and other script engines.

[uBlock-user]

Remove AAK, it's dead and no longer in development.

[mastacheata]

Ohh, ouch. I didn't think much about this repo not being maintained. (That happens way too often with extensions and stuff that is otherwise perfectly maintained)

Any ideas for replacements? I don't really want to add a new UserScript for every site with an Adblock notice.

[uBlock-user]

You didn't mention your blocker ??

[mastacheata]

Firefox and currently still on ABP / NoScript combo. Open for alternatives, though. After updating Firefox I had to redo most of my settings anyways, so I'm in the luxurious situation that changing the blocker software wouldn't cause too much trouble atm.

Am 18.11.2017 um 06:40 schrieb uBlock-user:

You didn't mention your blocker/browser??

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reek/anti-adblock-killer/issues/3750#issuecomment-345420318, or mute the thread https://github.com/notifications/unsubscribe-auth/AArt5SJ-Z9EmETffLkFA2P-K_qeenzzOks5s3m3FgaJpZM4QibJ0.

[uBlock-user]

AAK-Cont is the only one existing atm

[jspenguin2017]

AAK-Cont doesn't run on Greasemonkey 4 neither. You'll have to use Tampermonkey / Violentmonkey. If you use ABP then there isn't really another choice for now, you have to go with Tampermonkey + AAK-Cont. If you wants to switch browser then Chrome + uBO + uBR will work perfectly for you. Otherwise try uBO + ABR2 (on Quantum). You'll need to sign ABR2 extension yourself, which can be a bit difficult.

[mastacheata]

AAK-Cont doesn't run on Greasemonkey 4 neither. You'll have to use Tampermonkey / Violentmonkey.

Just replace all the Greasemonkey specific GM_ calls with GM. and make sure to put GM_getValue statements inside an async block and prefix the assignment with await. Took me about 5 minutes to fix the script for GM4. aak-cont-script-notubo.user.js.txt

Will still have a look at the alternative blockers, though. (Not really willing to switch to chrome. I love my Tab management extensions that will hopefully come back in Fx58 (unlikely, because the merge date is too soon) or 59 (with the Christmas days in between, this sounds like a realistic chance to land there)

[jspenguin2017]

I would accept a Merge Request if AAK-Cont is still maintained. If you feel like using that it's up to you.

[mastacheata]

The Gitlab repo is completely locked down. There's no way of opening a Merge Request or even an Issue for that matter. This is my fork with the changes applied to the split scripts in the build routine: https://gitlab.com/mastacheata1/AAK-Cont/commits/master

The CI build fails, though and I have no idea why it's complaining in line 278. I suppose that's the async wrapped block around the GM.getValue calls, but that looks just fine to me .

            (async function() {
                this.config.debugMode = await GM.getValue("config_debugMode", this.config.debugMode);
                this.config.allowExperimental = await GM.getValue("config_allowExperimental", this.config.allowExperimental);
                this.config.aggressiveAdflySkipper = await GM.getValue("config_aggressiveAdflySkiper", this.config.aggressiveAdflySkipper);
            })();

[jspenguin2017]

You'll need to wrap the entire script in async, as the script needs those config right away after.

[mastacheata]

Are you sure about that? The documentation at MDN says that await inside an async block causes the function to halt execution until the Promise with the await keyword is resolved. By encapsulating all 3 async GM. calls with in the async function and prefixing each with an await keyword that basically means the async function thing blocks until all 3 Promises are resolved and therefore the values are immediately available to any code that follows. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

But that's not what the Gitlab CI complains about. It complains about a mere syntactical error regarding the function keyword in the async function thing. The only way that's supposed to happen if the build script was run using a heavily outdated NodeJS <= 7.5 (because NodeJS only learned ES6 async functions in 7.6) But in gitlab-ci.yml it states to use node:latest image, which would be node 9.2 at the time of writing this. Therefore there shouldn't be a problem with the async function.

[jspenguin2017]

It only halt the execution of code inside, everything after will still be synchronous, which means the config will be loaded after it's being applied. I didn't set up the CI, I think it's using an older version of Esprima so it's compatible with older browsers. Might need to update package.json.

[mastacheata]

It only halt the execution of code inside, everything after will still be synchronous, which means the config will be loaded after it's being applied.

Ok, makes some sense. I still need to wrap my head around this whole async without callbacks concept.

I didn't set up the CI, I think it's using an older version of Esprima so it's compatible with older browsers. Might need to update package.json.

That did the trick. I had mistaken the esprima thing for just a library used by one of the scripts/build scripts. Didn't know this was actually the Test framework used. (even if only testing the syntax)