Greasemonkey: Ajouter une sauvegarde/restauration

Eh bien, Firefox et ses problèmes. Donc, j'implémentais ceci (et bien sûr une fonction « import »). J'en ai presque fini, mais il y a un obstacle. Cela ne fonctionne que lorsque vous ouvrez le browser toolbox et sélectionnez "ne pas fermer automatiquement les fenêtres contextuelles". L'importation se fait via un <input type="file"> (ce qui est le seul moyen), cependant, au focus de la fenêtre de navigation, la fenêtre contextuelle se ferme normalement, ainsi la fenêtre est détruite et aucune fonction n'est exécutée. Bogues pertinents :
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

C'est tellement ennuyeux d'avoir un environnement à moitié idiot dans lequel travailler.

S'applique également au #2612. Ce qui peut être abordé en même temps que cette question est.

@Sxderp Si la fermeture de la fenêtre contextuelle est un problème, le moyen normal de résoudre / contourner consiste simplement à ouvrir un onglet ou une fenêtre (pointant vers une page HTML dans l'extension) dans laquelle vous effectuez tout ce que vous devez faire. Ces onglets/fenêtres ne se ferment pas automatiquement et présentent le même environnement qu'une fenêtre contextuelle. Bien que cela ne soit peut-être pas aussi clair que d'avoir tout dans la fenêtre contextuelle du navigateur, cela devrait être fonctionnel.

Je pourrais faire ça. Cela impliquerait de déplacer un tas de code. Je me renseignerai une autre fois.

J'ai terminé l'import/export. Aucun test et très peu de gestion des erreurs. Mais ça marche. Cependant, pour plus de simplicité, j'ai fait en sorte qu'une importation écrase toute la base de données. Avec une demande de confirmation bien sûr.

Je pense qu'idéalement, l'utilisateur pourrait choisir de remplacer ou de fusionner l'importation. Le stylet ne fait que fusionner, ce qui est également un mauvais IME. Le choix de l'utilisateur, avec des valeurs par défaut qui pourraient fonctionner, semble le meilleur.

Bien sûr, mais nous rencontrons alors beaucoup de conditionnels. J'aimerais voir un organigramme quelconque sur la nature _exacte_ de la fusion.

Surtout en termes de conflits. Écraser le contenu, écraser les clés/valeurs (oui, celles-ci sont également exportées), demander tout (cela semble être une mauvaise expérience utilisateur), etc. ?

Je veux dire simplement : importez tous les scripts du fichier (et écrasez-les complètement dans cet état), mais ne touchez/supprimez pas les scripts qui ne sont pas dans le fichier.

Oh. C'est beaucoup plus simple. Ouais, ça sonne bien.

J'ai donc implémenté trois méthodes d'importation différentes.

1. Fusionner. Ne touchez à aucun script installé. Seuls les scripts qui n'existent pas actuellement[1] seront ajoutés à la base de données.
2. Remplacer. Désinstallez tous les scripts actuels et remplacez-les par ceux importés.
3. Écraser. Comme la fusion, mais si un conflit est trouvé[1], les scripts importés sont prioritaires.

Attendre d'autres PR avant de soumettre.

[1] Je détermine l'unicité par le id d'un script.

Et ça?

1. Mettre à jour. Importez (écrasez) uniquement les scripts qui existent déjà.

Ceci est complémentaire à 1. Fusionner

1. Écraser. Comme la fusion, mais si un conflit est trouvé[1], les scripts importés sont prioritaires.

@Sxderp Je suppose que "Comme la fusion" n'inclut pas la contrainte "Seuls les scripts qui n'existent pas actuellement"...
(cette contrainte n'a pas de sens ici) Cela signifie, Écraser = Importer tous les scripts, les scripts en conflit sont écrasés par l'archive...

Laquelle de ces options (mise à jour/fusion/etc.) est proposée par VM, TM ou autre ?

1. Mettre à jour. Importez (écrasez) uniquement les scripts qui existent déjà.

Bien sûr, cela devrait être faisable.

Cela signifie que, Écraser = Importer tous les scripts, les scripts en conflit sont écrasés par l'archive...

Correct.

Laquelle de ces options (mise à jour/fusion/etc.) est proposée par VM, TM ou autre ?

Pas vraiment sûr. Mais cela a soulevé une autre préoccupation pour moi. Compatibilité avec les archives. En supposant que ces addons prennent en charge l'exportation complète de la base de données (scripts + données), alors idéalement, les importations devraient être compatibles les unes avec les autres.

Mettre à jour. Importez (écrasez) uniquement les scripts qui existent déjà.

Maintenant que j'y pense (tout de genre 3 minutes), j'ai un souci. Qu'en est-il des données associées (get/setValue) ? Les données actuellement stockées doivent-elles rester ? Les données importées doivent-elles primer ? Une sorte de fusion ? Et puis représenter clairement cette option/état à l'utilisateur. C'est en fait un peu plus délicat qu'un premier coup d'œil.

J'ai fait quelques vérifications rapides, ce n'est pas complet à 100% mais donne un aperçu général, ainsi que ce que je devrais probablement changer en ce qui concerne mon implémentation.

VM et TM exportent tous deux dans des fichiers zip. À l'intérieur des fichiers zip, vous pouvez trouver des fichiers .user.js pour chacun de vos scripts. Cependant, en ce qui concerne l'exportation des détails spécifiques au stockage / à la mise en œuvre, les deux le font un peu différemment. VM encapsule les détails spécifiques à l'implémentation et les données de script, pour ce qui ressemble à tous les scripts, dans un seul fichier, violentmonkey . TM fait cela un peu plus sainement. Les détails spécifiques à l'implémentation, pour chaque script, sont exportés vers des fichiers .options.js , tandis que les données de script sont exportées vers .storage.json .

Je pense que je vais retravailler mon implémentation pour suivre la MT. En général, je pense que c'est une meilleure norme car elle sépare les détails de mise en œuvre des données.

Quant à la "méthode d'importation" (décrite dans mon message ci-dessus):

TM fournit une interface « sélectionner chaque script ». Lorsque vous importez une archive, vous sélectionnez si vous souhaitez importer chaque script spécifique. Si vous le cochez, il écrasera toutes les données de ce script.

VM ne semble offrir que ce que j'ai décrit ci-dessus comme « Ecraser ». Cependant, il existe une option pour NE PAS importer les données de script associées (globales pour tous les scripts). Du point de vue de l'interface utilisateur, je pense que la mise en œuvre de cette option dans GM serait difficile. Cependant, si nous adoptons l'approche TM pour exporter/importer la base de données, un utilisateur pourrait simplement ouvrir l'archive et supprimer le fichier .storage.json .

Si quelqu'un veut tester, j'ai mis à jour ma branche, sxderp:import-export-database-merge , pour inclure la fonctionnalité .zip j'ai parlé précédemment. Je n'ai pas implémenté l'option update suggérée par @Eselce car je ne suis toujours pas sûr des détails.

@Sxderp Merci d'avoir développé cette fonctionnalité. J'ai construit le package et l'ai installé dans Firefox Developer Edition (pour permettre l'installation d'extensions non signées). J'ai mis à niveau un profil existant avec cette version de navigateur, écrasé l'installation existante de GreaseMonkey et exporté ma base de données sans problème.

L'importation dans un nouveau profil Firefox avec ce GreaseMonkey installé a cependant causé un problème. Il semble qu'un script utilisateur spécifique qui soit assez volumineux (user.js et gm_details.js font environ 230 Ko cause des problèmes d'importation. Après avoir remplacé la base de données, GM cesse de fonctionner. Cliquer sur l'icône GM ouvre une liste déroulante vide (environ 10x10 carré).

Je préfère ne pas partager le script utilisateur spécifique publiquement. En utilisant cette astuce, j'ai trouvé votre adresse e-mail et je vais vous envoyer un message de cette façon.

Edit: La seule façon de faire fonctionner GM après sa panne est de supprimer l'extension, de redémarrer Firefox et de l'ajouter à nouveau.

GMexport_20180 2 17_164139.zip ???

Importation de tout un tas de scripts (en partie) volumineux (> 20) à partir d'un fichier zip de 3,4 Mo sans se plaindre. Pas d'examen détaillé cependant...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth() commence à 0... ; manquant...

IIRC, getMonth() commence à 0... ; manquant...

DÉCHIRURE

Je n'ai pas travaillé sur cette branche depuis un moment. Je vais prendre aujourd'hui et rebaser sur master et faire un tas de nettoyage.

J'ai rebasé ma branche sur master et apporté des modifications importantes à la mise en page qui, je pense, offre une meilleure lisibilité.
@ArmEagle Sur ma branche mise à jour, j'ai pu importer le fichier que vous avez envoyé. Si vous rencontrez toujours des problèmes, faites-le moi savoir et j'examinerai la question plus en détail.

Fusionné avec les modifications apportées à 7fe8bfe94efbadeb1da1a6491aaf424fc8275f09 . Réouverture pour suivre/discuter de certains problèmes que j'ai vus.

Réouverture pour suivre/discuter de certains problèmes que j'ai vus.

Quels étaient les problèmes ?

C'était un test rapide unique, je ne suis pas sûr, une partie du script que je m'attendais à installer n'était pas répertorié. Mais je veux le répéter et suivre attentivement et écrire les résultats. Il y a beaucoup de cas possibles.

J'ai enfin un peu réfléchi à ça.

Il ne sauvegarde que les .user.js et les "détails". Ce qui arrive à inclure accidentellement le contenu requis, mais manque les ressources (JSON sérialisant le blob jusqu'à {} ). AFAICT il va .setKnownResources() avec des blobs vides/cassés, et donc ne fonctionnera pas.

Il semblerait préférable que chaque script ait son propre dossier, que ce dossier contienne un fichier pour le .user.js , pour chaque @require et @resource , puis peut-être le reste les détails personnalisés et les valeurs stockées. Je pense que cela pourrait même être suffisamment meilleur pour que je renonce à toute compatibilité entre plates-formes.

Tout à fait d'accord. Tout comme enregistrer un document "en tant que page Web", ce qui créerait un htm -document plus un dossier du même nom (de base) avec les dépendances...

Ce qui arrive à inclure accidentellement le contenu requis ...

Ce n'était pas par accident. L'inclut à dessein, pour tout changement local qui aurait pu se produire. Je considérerais les ressources/requis comme des "détails d'implémentation", et donc exportés en tant que "détails". TM n'exporte même pas les ressources/nécessite.

mais manque les ressources (JSON sérialisant le blob jusqu'à {}). AFAICT, il .setKnownResources() avec des blobs vides/cassés et ne fonctionnera donc pas.

Il y a une TODO pour déterminer si les blobs se stringent bien. Cette fonctionnalité a été fusionnée techniquement avant que je ne soumette un PR pour cela.

Pour le moment, le problème du Blob serait résolu avec le #2937.

Quant à la création de plus de fichiers dans l'archive de sauvegarde, je ne pense pas que cela apporterait tous les avantages. Bien que l'archivage des ressources et des besoins et tout ce qui soit dans des fichiers séparés puisse sembler agréable lors de l'extraction, cela rendrait probablement le code plus complexe car vous traitez beaucoup de petites choses plutôt qu'un simple dump.

C'est la "grosse fonctionnalité" de la 4.4, donc j'espère vraiment finir/améliorer cela bientôt.

Deuxième réflexion, c'est fonctionnel. Il y a certaines améliorations que j'aimerais suivre, mais un problème pour chacun de ces changements ciblés sera plus facile à gérer.