Greasemonkey: Compatibilité WebExtension

J'y ai pensé un tas. Je n'ai pas de "décision" claire mais quelques points :

• Nous venons juste d'en finir avec le processus de portage pour la compatibilité e10s. C'était beaucoup plus difficile quand nous avons commencé; Par exemple, Services.ppmm et .cpmm sont de bons raccourcis, sur lesquels il aurait été agréable de s'appuyer depuis le début, mais ils n'existaient pas lorsque nous avons (responsablement) commencé.
• Ce travail a été long et très pénible, et je n'ai pas hâte de le répéter efficacement.
• Le déploiement e10s est passé de Firefox 36 (en septembre 2014) à Firefox 42 (en septembre 2015), soit au moins neuf mois.
• L'annonce indique que les extensions Web uniquement sont dans au moins 1 ou 2 ans ; il glissera dans 2, 3, 4 ans ?
• Si nous voulons faire cela, je pense que c'est le bon moment pour faire une rupture nette et ré-architecturer.
  
  
  
  • Je me surprends à souhaiter que nous ayons de bons tests unitaires semi-souvent, même si nous avons beaucoup de problèmes qu'ils n'attraperaient jamais, nous en avons aussi.
  
  
  • On peut enfin ajouter le support Android ?
  
  
  • Nous n'avons pas à réécrire à partir de zéro, mais il peut être justifié de réfléchir au code que nous conservons et à celui que nous supprimons.
  
  
• J'aimerais vraiment qu'une relation Greasemonkey/Mozilla beaucoup plus forte soit en place avant que nous commencions une autre tâche de cette envergure. Je n'ai que de faibles suppositions sur la façon de faire de cela une réalité.
  
  
  
  • Je pense que nous sommes effectivement un test de torture pour le portage vers quelque chose comme des extensions Web aujourd'hui ; au fil des ans, nous avons développé un certain nombre de fonctionnalités avancées. Une communication bidirectionnelle dans le cadre du plan aidera probablement beaucoup.
  
  

Commencer par un document de conception serait une excellente idée. Essentiellement, nous devons procéder à une ingénierie inverse de tout Greasemonkey tel qu'il existe dans un plan pour une bonne voie, plutôt qu'une voie organique non planifiée, pour que tout soit structuré.

Par exemple, Services.ppmm et .cpmm sont de bons raccourcis, sur lesquels il aurait été agréable de s'appuyer depuis le début, mais ils n'existaient pas lorsque nous avons (responsablement) commencé.

Je ne préconise certainement pas encore l'utilisation des WebExtensions, elles sont bien trop immatures pour quelque chose comme GM

Nous n'avons pas à réécrire à partir de zéro, mais il peut être justifié de réfléchir au code que nous conservons et à celui que nous supprimons.

Hrm, eh bien, je le regardais principalement à partir d'un point de vue technologique. À l'heure actuelle, l'interface utilisateur utilise des superpositions XUL et l'exécution directe de scripts dans l'environnement Chrome partagé.

Donc, convertir les choses en HTML et exécuter chaque chose dans un contexte de fenêtre indépendant et communiquer uniquement via la transmission de messages semble être la façon dont les choses sont censées être faites à l'avenir.

Le gestionnaire de messages est fondamentalement le niveau le plus bas où cela est implémenté. Les abstractions de niveau supérieur s'appuient sur cela. Canaux WebChannel.jsm/BroadcasstChannel/MessageChannel/WebExtension et autres.

Commencer par un document de conception serait une excellente idée.

Le wiki GH serait-il le bon endroit pour ça ? Fait-il des notifications lors de la modification pour simplifier le travail collaboratif ?

Je pense que nous avons surtout besoin d'une liste de fonctionnalités / de plomberie interne et de la façon de les mettre en œuvre de manière propre.

Si le sujet de ce numéro vous intéresse, veuillez lire :

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

Merci!

Pertinent:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

C'est une API super intéressante, mais "Cette fonctionnalité n'est pas standard et n'est pas sur une piste standard" et la compatibilité est très limitée.

Toutes mes tentatives récentes (voir #2483, #2484) pour concevoir des Greasemonkey-under-WebExtensions complètes ont été frustrantes. Je commence à envisager un style de développement plus progressif : choisissez un ensemble plus limité de fonctionnalités et ne supportez que cela. Soyez un peu utile, puis, espérons-le, trouvez plus tard un chemin vers plus de fonctionnalités.

En inspectant mon installation 3.x, je constate que (pour moi) chaque script est <strong i="6">@grant</strong> none . Sur 27, seuls six utilisent @run-at document-start , et la plupart d'entre eux fonctionneraient au moins assez gracieusement si cela n'était pas pris en charge. La fonctionnalité @require est très utilisée, et assez souvent @resource .

Cela semble donc être une cible décente à viser en premier : prise en charge des scripts utilisateur simples en mode <strong i="12">@grant</strong> none , pas de prise en charge des API GM_ . Prend en charge @require . J'espère prendre en charge @resource manière ou d'

(Remarque, car je l'oublie sans cesse : prévoyez d' utiliser @require en considération.)

Nous avons accès à des API Web simples en plus de celles de WebExtension, donc :

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? Quelle est la limite de stockage d'IndexedDB, pour une WebExtension ? Cela ressemble à une bien meilleure option que storage.local . L'interface n'est pas la plus simple, mais elle nous donne plus de pouvoir pour séparer les scripts les uns des autres et faire des lectures sélectives. Je pense. Les documents ne sont pas non plus les plus faciles à utiliser.

https://github.com/mdn/webextensions-examples/pull/171 semble avoir une discussion et un exemple précieux pour IndexedDB

J'ai fait quelques progrès.

https://github.com/arantius/greasemonkey/tree/webbymonkey (au 88d53b4c67b7825858405eb2591f27c8487ce413 )

Réimplémenté à partir de zéro. Vérifiez, accédez à about:debugging , appuyez sur "Charger le module complémentaire temporaire" et sélectionnez n'importe quel fichier à partir de l'emplacement racine. Vous pouvez installer et à peine exécuter des scripts utilisateur. Absolument aucune autre fonctionnalité pour le moment. (Eh bien, il y a le menu du singe, mais c'est un faux vide qui ne fait rien d'autre que l'air OK.) Beaucoup de TODO éparpillés dans le code même pour ce petit ensemble de fonctionnalités. Je ne peux pas garantir que tout cela soit le "bon chemin" vers plus de fonctionnalités ou non.

Étant donné que les anciennes versions de Tampermonkey, ainsi que Violentmonkey, sont open source, une partie de ce code pourrait-elle être utilisée ici, puisque WebExtensions est similaire aux extensions Chromium ?
EDIT : En fait, en le regardant, je ne suis pas sûr de la compatibilité de la licence avec l'ancien Tampermonkey. Mais Violentmonkey est sous licence MIT, il est donc compatible.

@PorygonZRocks : Violentmonkey devient Greasemonkey ?

Je ne suis pas très expérimenté avec le codage, mais je pensais qu'il pourrait au moins avoir des directives sur la mise en œuvre des choses. Encore une fois, pas très expérimenté/bien informé, donc je peux me tromper.

Il convient de noter que FF56 a désactivé tous les modules complémentaires non compatibles multiprocessus, il se peut donc que la date limite doive changer.

Voir ma branche dev . Ce qui est assez rugueux mais est peu fonctionnel. Cela est en train d'être fait, il n'y a rien à suivre spécifiquement dans ce problème à large portée.

@arantius Par curiosité, écrivez-vous un nouveau code ou réutilisez-vous l'ancien ?

As-tu besoin d'aide?

Encore une fois par curiosité, par exemple, le but de "parse-meta-line.js" est-il simplement d'analyser les métadonnées dans un objet?

@arantius Par curiosité, écrivez-vous un nouveau code ou réutilisez-vous l'ancien ?

Surtout neuf. Copier quand/où c'est utile. (Jusqu'à présent, l'analyse de script est un grand exemple.)

As-tu besoin d'aide?

De l'aide serait sympa. La coordination serait difficile.

Encore une fois par curiosité, par exemple, le but de "parse-meta-line.js" est-il simplement d'analyser les métadonnées dans un objet?

Une ligne, oui.

Une ligne, oui.
Je voulais dire, fait-il autre chose que d'analyser les métadonnées entre celles-ci :

// ==UserScript==
....
// ==/UserScript==

Cela semble être beaucoup de code si c'est le seul objectif.

Oui c'est ce que ça fait. C'est du code généré. Veuillez transmettre cette discussion à https://groups.google.com/d/topic/greasemonkey-dev .

Je n'utilise pas les groupes Google :(
Si c'était moi... je le ferais probablement différemment.

Le groupe google n'existe plus.

Mauvais lien : https://groups.google.com/forum/#!forum/greasemonkey -dev

Pas tout à fait sûr que ce soit le bon emplacement, mais le voici quand même. Si vous voulez que j'ouvre un numéro distinct @arantius , bien sûr.
La 4.0.0 n'est-elle pas censée migrer les scripts existants ? J'ai mis à jour vers l'alpha 3 (provenant de la dernière version non bêta) et j'ai remarqué que je n'avais plus de scripts.

@Phyxion , si vous installez 3.14, les scripts doivent être migrés. Assurez-vous de redémarrer le navigateur après l'installation.

Après cela, lorsque vous installez 4.x, vous devriez avoir les scripts. Si vous ne le faites pas, des étapes de reproduction détaillées dans un nouveau numéro seraient utiles.

Greasemonkey 4 alpha est incompatible avec Firefox 57.

@erkinalp , pouvez-vous préciser ? J'ai utilisé 4alpha2 pour beaucoup de mes tests et modifications, cela fonctionne, bien que toutes les fonctionnalités de la version 3.x ne soient pas disponibles. Je n'ai pas retiré les changements dans 4alpha3, donc je ne sais pas que les quelques commits pour cette version cassent quoi que ce soit.

@Sxderp Eh bien, le reproduire sur ma machine est facile. J'ai installé 3.14 avec 10 scripts utilisateur. Allez sur AMO et téléchargez la dernière version alpha. Redémarrez lorsque demandé. Ensuite, il dit simplement qu'aucun script utilisateur n'est installé. Je ne sais pas à quel point cela est utile pour le reproduire.

Je n'ai pas encore testé cela mais je pense que GM4 devrait perdre sa configuration après une désinstallation, tandis que GM3 devrait la conserver , je vous suggère donc d'essayer :

1. Désinstaller complètement Greasemonkey
2. Redémarrez Firefox
3. Installez Greasemonkey 3.14 (y compris le redémarrage)
4. Redémarrez Firefox pour faire bonne mesure
5. Installez Greasemonkey 4 (pointez n'importe quoi)

Est ce que ça aide?

Je pense que le plus haut niveau d'attente - c'est-à-dire tout envelopper dans une fonction async - n'est pas un bon choix de conception car il restreint les implémentations futures (par exemple, si/quand nous récupérons les bacs à sable ou les royaumes es-future). Cela rend les choses incohérentes avec l'exécution de vanilla JS où l'attente de niveau supérieur n'est pas disponible et les scripts s'exécutent... eh bien... à un niveau supérieur.

@arantius
Toujours rien ici :(
BTW, 4.0 est censé ressembler à ceci : https://i.imgur.com/CPuWWKM.png
Il n'y a pas de boutons ou quoi que ce soit pour ajouter un script.

... enveloppant tout dans une fonction asynchrone ...

Avec ce qui est disponible maintenant, je "dois" envelopper une fonction à des fins de portée. Je pense que j'accepte votre raisonnement pour ne pas le rendre asynchrone. (Au moins, l'ajout d'une fonction wrapper asynchrone dans le script lui-même est trivial.)

Oui, il s'agissait principalement d'async/wait, car cela n'est actuellement intentionnellement pas autorisé dans javascript , donc l'activer dans les scripts utilisateur semble être un danger pour les changements futurs. Je sais que le wrapper est actuellement inévitable, mais j'espère que les choses pourront revenir au plus haut niveau à l'avenir.

@arantius Pourquoi le vote

@arantius a commenté 2017. szept.

... enveloppant tout dans une fonction asynchrone ...

Avec ce qui est disponible maintenant, je "dois" envelopper une fonction à des fins de portée. Je pense que j'accepte votre raisonnement pour ne pas le rendre asynchrone. (Au moins, l'ajout d'une fonction wrapper asynchrone dans le script lui-même est trivial.)

Essayez de supprimer le contenu de [profil mozilla]\storage\default\ (après l'avoir sauvegardé)
Puis réessayez.

En parlant d'objets UserScript, je ne comprends pas très bien la décision de conception d'avoir trois classes UserScript. Pour le moment, ils ont un arbre d'héritage singulier qui est un peu idiot.

De plus, RemoteUserScript n'est utilisé qu'une seule fois et pour cela il n'est créé que pour récupérer l'id . Et RunnableUserScript n'est jamais directement utilisé.

Juste pour info...

Je suis sur FF57.0a1 et j'exécute des addons hérités et GM 3.13
Malheureusement, je ne reçois pas les mises à jour (3.14, 3.15) car leur version maximale est définie sur 56.*

Il peut cependant être installé manuellement.

GM 3.16 bloque toujours le navigateur au démarrage (je suppose qu'il met à jour la base de données)