Reprise du message précédent :
Test imgur

https://i.imgur.com/ShX3a39.jpg

edit : re-merci roger21, la manip fonctionne nickel pour imgur
Modif lignes 726 et 727 pour ma version du script.

Si je comprends bien, les données locales sont uploadées sur reho.st et les données copiées en ligne sur imgur ?

oui l'url du script a changé, il faut le réinstaller à partir du bon lien (cf. liste)

ou là

edit : bon la maj est pas terrible des boutons seraient plus simple (et pourquoi pas le format medium aussi) et là si on clic pas au bon endroit (ce qui n'est pas clair déjà) le truc disparait et on est bon pour recommencer (sans parler du cliquer en dehors qui à le même effet et qu'on préfererait ne pas avoir ici), la transparence est pas pratique (ou trop élévée) et le style des polices n'est pas celui du forum ???
mais bref une vignette de l'image et 4 boutons de choix et pas de clic en dehors (et un bouton annuler plutot que simplement la croix pour plus de clarté et qui annulerai que l'image en cours pas tout le lot)

En gros le script ne s'est pas complètement initialisé, donc les styles de la page de config ne sont pas actifs et elle apparaît en fin de page (pareil pour les pastilles qui ne sont pas présentes). Bref il y a une truc qui pose problème entre la ligne 840 et 1100, mais il faudrait regarder la console pour mieux identifier le problème (je parie sur la ligne 1100 GM.addStyle() avec un conflit à la con).

J'ai ça dans la console si j'active copié/collé:
 
TypeError: GM.addStyle is not a function[En savoir plus]

Alors, j'ai désinstallé Color Tag, redémarré Firefox, réinstallé Color Tag, tout ça en laissant Copié/Collé activé, plus d'erreur.
edit:
J'ai compris le problème: si Color Tag est exécute avant Copié/Collé, le bug est présent, si c’est Copié/Collé qui est exécuté avant, plus de bug.
On peut déplacer les scripts dans la page de configuration de VM.

C'est bizarre car j'ai aussi testé l'ordre des scripts et je n'ai pas eu d'erreur.
GM.addStyle() n'existe pas dans l'API de Greasemonkey (avant GM4 il y avait GM_addStyle()). Dans colortag la fonction est créée de toute pièce ou redirige vers GM_addStyle() si cette dernière est compatible avec l'extension de l'utilisateur. Tout est géré via un script externe (gm4-polyfill.js) qui permet de faire le pont entre les différentes extensions assez proprement.
Le seul truc bizarre que je vois dans copier-coller c'est des @grant dans les metadata qui pointent vers des fonctions inexistantes/non-standard, dont GM.addStyle() (et beaucoup ne sont même pas utilisées).

Je peux reproduire en important mes scripts sur un nouveau profil, avec uniquement uBlock Origin et ViolentMonkey.
Je t'envoie ça, ainsi qu'à PJ, en MP

Après reflexion, je le poste ici, il n'y a rien de privé dans mes scripts, et j'ai viré tous ceux non relatifs à HFR.
 
Ma configuration: Windows 7 x64, Firefox 64 bits stable, ViolentMonkey.
Pour créer un nouveau profil avec Firefox: firefox.exe  -P  --no-remote ensuite pour lancer le profil firefox.exe  -P  nomduprofil --no-remote
--no-remote permet de lancer autant d’instances de Firefox que l'on souhaite.
 
Voila le zip, à importer depuis ViolentMonkey: scripts_2019-05-20_14.36.46.zip
 
Vous devriez constater le bug dès l'import du zip après avoir rafraichi une page du forum.

je verrai ça ce soir

elle a le bouton gris celle-ci ? et le placement est vers le bouton de validation de message ?

Essaye-là, tu verras bien.

en attendant le script copié/collé est revenu une version en arrière

Bon j'ai regardé un peu plus en détail. En fait copié/collé réinitialise l'objet GM à {} si l'extension utilisée n'est pas exactement GreaseMonkey 4 (ligne 103). Forcément ça ne plait pas aux scripts qui l'avaient déjà instancié notamment Colortag qui le fait via un script externe (metadata @require, j'imagine que c'est pour ça que ce GM particulier est accessible à d'autres scripts et n'est pas limité au scope Colortag).
4 Solutions différentes :
A. Lancer Colortag à la fin, il pourra alors créer son objet GM tout propre que personne ne viendra sacager.
B. Modifier copié/collé pour ne plus tester la version de l'objet GM, juste sa présence et les fonctions nécessaires (on peut supposer que si l'objet a déjà été créé, le polyfill a été fait correctement).
C. Intégrer le contenu du script gm4-polyfill.js (avec quelques modifs) directement à Colortag, il n'y a alors plus de problème de portée car Colortag aura son propre GM
D. Standardiser la méthode permettant la retrocompatibilité de l'API Greasemonkey pour l'ensemble des scripts HFR, histoire de ne pas réinventer la roue à chaque fois et venir polluer le début des scripts. Il suffit d'une ligne dans les metadonnées, par exemple :

Si on a pas confiance dans le repo github greasemonkey, on peut toujours créer une copie sur le repo d'un membre HFR de confiance.

Je suis pour D

Ddst  

Je vais modifier copie/collé donc

E. Je klaxonne.

En y réfléchissant, gm4-polyfill.js n'est peut-être pas une si bonne solution s'il crée un objet GM accessible à tous. Un script pourrait en profiter pour détourner une fonction et accéder au contenu des autres scripts l'utilisant. Si on rajoute Object.freeze(GM) au script ça résoudrait peut-être le problème ?

bon, est-ce qu'on pourrait commencer par changer le code isGM4 en quelque chose de plus consensuel comme pour le polifyl ou les autres (solution B)

et revenir à un simple

correction du 13/10/2019

sinon vm implose

ensuite il n'y a qu'avec vm que GM est construit puisque les 2 autres l'ont, donc si on fait un code propre qui ne cherche pas à tout casser et à s'imposer, avec gm et tm il y a aucun problème (et on utilise les api respectives de chacune qui malheureusement sont légèrement différente pour le GM.notification et pour lequel on peut rajouter un isGM4 pour adapter l'appel à GM.notification voir Rehost pour l'exemple)

ensuite oui, je suppose qu'il faut s'homogénéiser lorsque l'on crée ou modifie GM puisqu'il est global (encore une fois si on code propre, seul vm est concerné), perso j'ai repris en dur dans les scripts le code du polyfil mais en me limitant aux fonctions dont j'ai besoin, donc mon code ne devrait pas interférer avec un appel au polyfil

je suis pas fan du D (simplement parce que j'aime pas inclure des trucs extérieurs qui apporte des trucs dont j'ai pas besoin) mais clairement on ne doit pas sortir du polyfil si on crée/modifie GM

et après les gens font comme ils veulent soit le polyfil soit du code en dur mais qui doit avoir exactement le même comportement que le polyfil

Un petit nouveau dans la famille des singes: FireMonkey.  
Par rapport aux autres *monkey, il gère aussi les styles Stylus/Stylish.
 

MAJ [HFR] Copié/Collé (version 0.9.3.2)
 
Correction compatibilité GM4
 
effectivement, ça a l'air mieux
 

ça avait l'air intéressant sur le papier mais :

et :

apparemment il faut passer par le fichier uniquement pour installer un script (les urls il s'en fout), j'ai testé rehost, last post highlight et copié collé, aucun ne fonctionne et y'a pas d'erreur ... bref

liste à jour

Tu vas te flinguer les yeux à lire mes posts  
Je confirme, plus de soucis

T'as essayé ça ?

valeur à "true" dans la config de firefox comme indiqué au dessus

je t'ai foutu des "console.log (index)" toutes les 3 lignes, avec l'index incrémenté.

le premier console.log non affiché était après "GM_registerMenuCommand" ...
et GM_info m'affiche une fonction dans la console. OK....

On va attendre pour FireMonkey hein

J'ai rien compris

bah relis mieux
la moitié des fonctions sont inexistantes. Au lieu de retourner les objets attendus, ça ne retourne que des objets vides

Je suis pas dev  

même pas un petit peu ?

 
Trad : c'est de la merde ton singe en feu  

 
Je fait du batch    

 
Oui ça j’avais compris  

alors non, mais même à true j'ai rien qui marche même avec des scripts gentils et surtout j'ai aucune erreur dans les console (en ff 67 là)
 
donc bon je dis pas, j'ai ptet merder un truc et je pourrais chercher un peu plus à coup de logs comme pj mais là bof quoi

Donc les deux devs principaux du topic sont d'accord: le singe de feu c'est pas encore ça
On va rester sur le singe violent alors    
 
 
Bon de toute façon j'avais pas prévu de changer, Violentmonkey me va bien, et je serais même resté sur GM si les devs n'avaient pas eu l'idée saugrenue de casser la compatibilité avec leur v4 (qui a mis du temps à sortir d'ailleurs, ce qui a poussé une partie des utilisateurs sur TM et VM, qui eux n'ont pas cassé la compatibilité et sont rapidement sortis en webext).

qu'ils préfèrent un objet global à plusieurs fonctions, pourquoi pas. Le plus chiant c'est le passage à l'asynchrone

Encore du chinois pour moi
Je suppose que tu parles de GM4.
Reste que casser la compatibilité avec les scripts existants c'est pas très malin.

GM4 oui. avec la v3, tu utilisais une fonction, la valeur arrivait tout de suite. Maintenant, tu utilises la fonction, mais il faut lui ajouter un tout petit truc, comme un signal, pour récupérer la valeur dès que la fonction sera terminée.

Et les nouvelles fonctions de GM4 sont compatibles avec VM et TM ?
Je veux dire, si tu développes un script pour GM, est-ce qu'il fonctionnera sur les deux autres (et même trois autres maintenant) ?

Avec le polyfill oui
Si il détecte l'objet GM, il ne fait rien. Sinon il le recrée.

Mais ce polyfill, c'est le dev du script qui doit l'ajouter ?

oui