Greasemonkey: Reconsidérer l'implémentation de GM_registerMenuCommand dans GM 4.x

Pour référence, je cite la discussion pertinente de https://github.com/greasemonkey/greasemonkey/issues/2559 :

(huit04)

_arantius J'ai vu que GM_registerMenuCommand est remplacé par le menu contextuel HTML5. Est-il prévu de l'ajouter dans GM 4.x ? Je ne trouve pas le problème de suivi._

(arantius)

_Non. La politique de Greasemonkey a été (pendant longtemps) de ne pas implémenter de fonctionnalités « espace utilisateur ». N'importe quel script peut le faire, ou @require quelque chose comme ce polyfill qui le fait. Greasemonkey n'a pas besoin de construire ni de prendre en charge cette fonctionnalité pour permettre aux scripts de l'utiliser. Le but ici est simplement de faire ce que fait le polyfill : faciliter la mise à jour des scripts pour qu'ils soient compatibles avec les anciennes et les nouvelles versions de Greasemonkey._

(huit04)

_Je voulais dire si GM4 fournira également une API pour exécuter des commandes de script à partir de l'interface utilisateur du gestionnaire de scripts utilisateur comme l'ancien GM_registerMenuCommand, sans demander s'il y aura une API de menu contextuel HTML5 dans GM. GM_registerMenuCommand est souvent utilisé pour lancer la boîte de dialogue de configuration de script, qui ne doit pas être polyremplie comme un menu contextuel HTML5 IMHO._

_BTW, j'ai créé une bibliothèque pour travailler avec le menu contextuel HTML il y a quelques mois à peine, qui réutiliserait la propriété contextmenu sur la page si elle est déjà définie :_
_ https://github.com/eight04/GM_context_

(arantius)

_GM_registerMenuCommand est souvent utilisé pour lancer la boîte de dialogue de configuration de script, qui ne doit pas être polyremplie comme un menu contextuel HTML5 IMHO_

_Pourquoi pas?_

(huit04)

_Pourquoi pas?_

_1. La commande du menu contextuel doit être :_

_- Une action qui fonctionne sur un contexte spécifié (élément). Par exemple, lorsqu'un texte est sélectionné, la commande "Copier", qui est une action pour travailler avec la sélection, est affichée._
_- Un raccourci pour exécuter la commande spécifiée pour plus de commodité._
_Une commande "My userscript setting" n'appartient pas aux deux catégories. Cela ne dépend pas du contexte, il n'est pas non plus nécessaire d'utiliser un raccourci pour la configuration._

_2, ce n'est pas fiable. Il peut être bloqué/remplacé par des scripts de page._

(trlkly)

_Je suis d'accord avec les difficultés au niveau conceptuel. Je n'ai plus d'extensions qui utilisent le menu contextuel pour les paramètres. Cela deviendrait assez occupé assez rapidement s'ils le faisaient, car j'exécute beaucoup d'extensions._

_Mais la principale raison que je vois est que Chrome a supprimé le menu contextuel HTML5 de la spécification , ce qui signifie qu'il sera probablement également supprimé de Firefox. Je ne savais même pas qu'il existait, vu que je n'ai vu aucun site l'utiliser. Les applications tournent simplement d'elles-mêmes, bloquant le menu contextuel réel (ce qui est un énorme, énorme ennui dans la plupart des cas. Cela supprime la fonctionnalité.)_

Cela me donne mal à la tête d'essayer de penser à la façon dont les scripts interagiraient. En supposant qu'il y ait une option de menu et que cette option de menu ouvre une sorte de fenêtre / boîte / boîte de dialogue / quoi que ce soit pour modifier les paramètres, cette fenêtre nouvellement générée est-elle considérée comme étant dans le contexte « script de contenu » et donc capable d'envoyer des messages à l'extension ? Et si ce n'est pas le cas, comment renvoyer un message au script de contenu, afin que les paramètres puissent être modifiés ?

Cependant, il semble qu'un thème commun soit les menus de paramètres. Je serais en faveur d'avoir des champs de configuration définis de manière statique dans le métabloc qui sont ensuite générés et peuvent être enregistrés / modifiés via le menu Monkey. Similaire à un resource mais sont modifiés en passant par Monkey Menu -> Script -> Config -> Items .

_Je serais en faveur d'avoir des champs de configuration définis de manière statique dans le métabloc qui sont ensuite générés et peuvent être sauvegardés/modifiés via le menu Monkey. Similaire à une ressource mais sont modifiés en allant dans Monkey Menu -> Script -> Config -> Items._

Je crains que l'utilisation de champs de configuration statiques dans le métabloc ne le rende trop restrictif :
par exemple, pour le 1er script mentionné Mouseover Popup Image Viewer ,
en dehors de la mise en page pratique actuelle (menus déroulants, cases à cocher, zones de texte avec barre de défilement, zone de texte),
le menu des paramètres propose actuellement :

• importer/exporter les paramètres (dans le presse-papiers),
• installer les règles du référentiel MPIV directement dans les paramètres,
• il y a des règles de recherche au fur et à mesure que de nombreuses règles d'hôte personnalisées sont installées,
• il valide si la règle d'hôte personnalisée saisie est un JSON valide et met en surbrillance la ligne d'entrée en rouge sinon,

De plus, son auteur devrait avoir à réécrire l'intégralité du "code d'installation".

FWIW, W3C ont supprimé le menu contextuel de HTML5 et Firefox va également le supprimer .

@legnaleurc Gosh, cela pourrait être un problème pour certaines personnes. En tant que profane, je n'en ai aucune idée, mais connaissez-vous un autre moyen d'ajouter des éléments de menu contextuel, pour remplacer la méthode qui utilise