Scribe for Medium #9

dertuxmalwieder commented 2021年10月27日 18:17:28 +02:00

+Scribe

+Scribe

izzy commented 2021年10月27日 23:47:25 +02:00

Thanks! But updating to this version breaks it, as there was no scribe instance defined before. Fix suggested.

Somehow, updating to your variant (even if fixed) seems to break the menus for me – they are all gone, even if downgrading to the previous version. No idea what's that. Will try now if a browser restart fixes that – else it might be some update to the included polyfill.js or I have no idea (update: stays broken for me and I am mightily confused!).

Further, is there a list of instances somewhere, like with all the other services already covered by the script?

Thanks! But updating to this version breaks it, as there was no scribe instance defined before. Fix suggested. Somehow, updating to your variant (even if fixed) seems to break the menus for me – they are all gone, even if downgrading to the previous version. No idea what's that. Will try now if a browser restart fixes that – else it might be some update to the included `polyfill.js` or I have no idea (update: stays broken for me and I am mightily confused!). Further, is there a list of instances somewhere, like with all the other services already covered by the script?

dertuxmalwieder commented 2021年10月28日 01:09:28 +02:00

I have not found a list of instances yet. I would imagine that there is no officially endorsed list...

I have not found a list of instances yet. I would imagine that there is no officially endorsed list...

izzy commented 2021年10月28日 02:11:26 +02:00

OK, got the menus back. But I still don't understand what changed that behavior. I had to also

@grant GM_registerMenuCommand
@grant GM.registerMenuCommand

(both are needed, for compatibility with e.g. Waterfox Classic the GM_ and for newer the GM.), and then replace all GM_registerMenuCommand() calls by GM.registerMenuCommand(). Now I just need to find out why the script suddenly runs twice on some sites (e.g. DDG), thus duplicating the menus, but not on others... It never did that before. Debugging a bit (console.log(location);): yuck. DDG calls itself with a POST as a sub-request – so when you visit https://duckduckgo.com/?t=ffsb&q=scribe+medium&ia=web, it additionally calls https://duckduckgo.com/post3.html thus running the script a second time and adding the menus once more. I still don't get why this does not happen to my other scripts. Or how to avoid this (don't know of a way to find out which menus are already registered, for example) – so ideas are welcome.

OK, got the menus back. But I still don't understand what changed that behavior. I had to also ```js @grant GM_registerMenuCommand @grant GM.registerMenuCommand ``` (both are needed, for compatibility with e.g. Waterfox Classic the `GM_` and for newer the `GM.`), and then replace all `GM_registerMenuCommand()` calls by `GM.registerMenuCommand()`. Now I just need to find out why the script suddenly runs twice on *some* sites (e.g. DDG), thus duplicating the menus, but not on others... It never did that before. Debugging a bit (`console.log(location);`): yuck. DDG calls itself with a POST as a sub-request – so when you visit `https://duckduckgo.com/?t=ffsb&q=scribe+medium&ia=web`, it additionally calls `https://duckduckgo.com/post3.html` thus running the script a second time and adding the menus once more. I still don't get why this does not happen to my other scripts. Or how to avoid this (don't know of a way to find out which menus are already registered, for example) – so ideas are welcome.

dertuxmalwieder commented 2021年10月28日 02:14:34 +02:00

I would probably just set (and check) a script_is_loaded variable which is true after the initial loading.

I would probably just set (and check) a `script_is_loaded` variable which is true after the initial loading.

izzy commented 2021年10月28日 03:01:15 +02:00

I tried exactly that in at least 3 different ways to no avail:

• variable in the script: is not visible when the script runs again
• window.variable or unsafeWindow.variable had no effect either (as the 2 locations differ, they are most likely considered two different documents)
• for the same reason, window.eval() did not work.

If I missed something, I'm all ears. Unfortunately it's not a part of the script repeated (like a function called twice), but the entire script is run a second time as if it were installed twice. But I only noticed that for DDG so far – and if you cannot reproduce that (would be interesting what browser you are using), it must be something "borked" on my end. For now I locally adjusted to skip that second DDG URL.

Last question before I merge: Which browser & version & extension did you test with, as obviously GM_ didn't break for you? If I again can address that to "something local here only", I don't want to hold your changes back 😉

I tried exactly that in at least 3 different ways to no avail: * variable in the script: is not visible when the script runs again * `window.variable` or `unsafeWindow.variable` had no effect either (as the 2 locations differ, they are most likely considered two different documents) * for the same reason, `window.eval()` did not work. If I missed something, I'm all ears. Unfortunately it's not a part of the script repeated (like a function called twice), but the entire script is run a second time as if it were installed twice. But I only noticed that for DDG so far – and if you cannot reproduce that (would be interesting what browser you are using), it must be something "borked" on my end. For now I locally adjusted to skip that second DDG URL. Last question before I merge: Which browser & version & extension did you test with, as obviously `GM_` didn't break for you? If I again can address that to "something local here only", I don't want to hold your changes back :wink:

ltguillaume commented 2021年10月28日 03:17:35 +02:00

Was GM_ only for Waterfox Classic? I just tried GM.registerMenuCommand with Waterfox Classic in ViolentMonkey and it worked perfectly. All other GM* in my fork were already GM.-only, because they already worked with Waterfox Classic, but I must have left GM_registerMenuCommand in there, because it did not work before. Now it does.

Was `GM_` only for Waterfox Classic? I just tried `GM.registerMenuCommand` with Waterfox Classic in ViolentMonkey and it worked perfectly. All other `GM*` in my [fork](https://codeberg.org/ltGuillaume/yt2invidio) were already `GM.`-only, because they already worked with Waterfox Classic, but I must have left `GM_registerMenuCommand` in there, because it did not work before. Now it does.

dertuxmalwieder commented 2021年10月28日 04:57:52 +02:00

As far as I know, GM_ only exists as a backwards-compatible wrapper around GM.* these days. While Greasemonkey only supports the latter, both Violentmonkey and Tampermonkey still support both variants.

I am not sure whether Waterfox does anything differently here, but if it does, it is a bug in the particular userscript manager. Waterfox does not support userscripts OOTB, does it?

As far as I know, `GM_` only exists as a backwards-compatible wrapper around `GM.*` these days. While Greasemonkey only supports the latter, both Violentmonkey and Tampermonkey still support both variants. I am not sure whether Waterfox does anything differently here, but if it does, it is a bug in the particular userscript manager. Waterfox does not support userscripts OOTB, does it?

izzy commented 2021年10月28日 08:49:47 +02:00

GM_ was mostly Greasemonkey < 4. Some of the GM_/GM. are wrapped via the polyfill script which is @required – with the intention of having the same script working for browsers still supporting the full extensions like Classic (and Palemoon), using Greasemonkey 3, as well as for the "modern variants". And funny that this obviously broke for me yesterday with this script, while it remains working for others. Must be something local here then – so I worked around that locally here for now. As it was broken even when I restored the previous version, it should not be related with your changes.

`GM_` was mostly Greasemonkey < 4. Some of the `GM_`/`GM.` are wrapped via the polyfill script which is `@require`d – with the intention of having the same script working for browsers still supporting the full extensions like Classic (and Palemoon), using Greasemonkey 3, as well as for the "modern variants". And funny that this obviously broke for me yesterday with this script, while it remains working for others. Must be something local here then – so I worked around that locally here for now. As it was broken even when I restored the previous version, it should not be related with your changes.

izzy commented 2021年10月28日 09:07:08 +02:00

Thanks again!

Thanks again!

ltguillaume commented 2021年10月28日 12:15:03 +02:00

Thx for the explanation. I had no need for backwards compatibility, as long as it also worked with Waterfox Classic. Not sure what the polyfill was needed for, if at all, with regard to Waterfox, because I removed it without issues: ltGuillaume/yt2invidio@530d20dc7a
Unfortunately, I failed to explain in the commit why I didn't change the GM_registerMenuCommand, but I think I tried it back then and it didn't build the menu with GM.. Either way, now it does.

Thx for the explanation. I had no need for backwards compatibility, as long as it also worked with Waterfox Classic. Not sure what the polyfill was needed for, if at all, with regard to Waterfox, because I removed it without issues: https://codeberg.org/ltGuillaume/yt2invidio/commit/530d20dc7a0484c4c4b4457c280b9be8d0f970ad Unfortunately, I failed to explain in the commit why I didn't change the `GM_registerMenuCommand`, but I think I tried it back then and it didn't build the menu with `GM.`. Either way, now it does.

izzy commented 2021年10月28日 23:24:19 +02:00

IIRC I added that so the very same calls could be used (GM_ worked with GM 3.* but not with 4.* and GM. just the other way around – so that polyfill script maps all GM_ to the proper GM. counterpart). No idea if GM_ was added back later to the monkey directly. Long time no updates to it either...

I cannot test if GM_ would consistently work without polyfill, because... see above. Something strange here. And other than with GM 3.* where you could simply remove the script directory (or directly edit inside), 4.* uses a database with no "clearly visible" content (all looks like either binary or something base64, but you cannot read it in plain). Got no time to dig into that.

IIRC I added that so the very same calls could be used (`GM_` worked with GM 3.* but not with 4.* and `GM.` just the other way around – so that polyfill script maps all `GM_` to the proper `GM.` counterpart). No idea if `GM_` was added back later to the monkey directly. Long time no updates to it either... I cannot test if `GM_` would consistently work without polyfill, because... see above. Something strange here. And other than with GM 3.* where you could simply remove the script directory (or directly edit inside), 4.* uses a database with no "clearly visible" content (all looks like either binary or something base64, but you cannot read it in plain). Got no time to dig into that.