Greasemonkey: Autoriser l'installation des fichiers locaux

Peut - être * dans le sélecteur de correspondances pour le schéma ne renvoie que vers http ou https. Suggérez d'ajouter une correspondance supplémentaire pour file:// .

Ça ou le sélecteur <all_urls> .

L'ajout d'un modèle de correspondance pour détecter les scripts file:/// nous amène simplement à démarrer un XHR qui ne parvient pas à lire le contenu de cette URL, ce qui est surprenant.

J'ai un peu regardé ça. Et je suis arrivé à deux conclusions. Le problème peut être lié à l'interdiction d'accès au système de fichiers aux WebExtensions, même en lecture seule via XHR (aucune source à ce sujet directement ; éditez : ici tout en bas). Ou cela pourrait être lié à la même politique d'origine .

À partir de Gecko 1.9, les fichiers ne sont autorisés à lire que certains autres fichiers. Concrètement, un fichier ne peut lire un autre fichier que si le répertoire parent du fichier d'origine est un répertoire ancêtre du fichier cible.

Cela pourrait valoir la peine de mentionner un rapport de bogue pour autoriser l'accès au système de fichiers aux chemins définis dans le manifeste avec le protocole file:// .

Oui, c'est probablement la règle "pas de fichiers". Je ne sais pas où trouver des conseils officiels à ce sujet, mais je sais que c'est vrai maintenant que j'y pense. Vous n'obtenez que des exceptions très spéciales comme l'API de téléchargement pour créer de nouveaux fichiers.

Nous pourrions essayer de trouver une solution de contournement comme gérer directement le glisser/déposer, ou (LOL) lire le contenu de l'onglet déjà ouvert. Mais alors, nous ne parviendrions pas à récupérer l'icône / la ressource / les exigences relatives, donc cela ne fonctionnera toujours pas, sans encore plus de solutions de contournement.

Ne pourriez-vous pas utiliser storage.local pour mettre en cache le contenu en utilisant l'url comme clé avant de naviguer sur la page d'installation ? Vous avez déjà le contenu dans une variable. Bien sûr, le cache devrait être vidé une fois installé / décidément pas installé. Ce serait plus pratique si WebExtensions disposait d'une sorte de stockage temporaire afin de ne pas avoir à gérer manuellement l'expulsion.

J'ai déconné avec ce que j'ai dit et ce n'est pas aussi simple que je l'aurais pensé. Tout d'abord, tout script utilisateur a accès à browser.storage.local , il s'agit donc par nature d'un stockage dangereux pour les addons comme Greasemonkey. Deuxièmement, il en va de même pour l'envoi du contenu via un message à un script d'arrière-plan. Je ne sais pas vraiment comment sécuriser cela pour m'assurer que le message a été envoyé uniquement à partir de script-detect.js . Et en raison de la nature asynchrone des scripts, je ne suis pas tout à fait sûr que script-detect.js s'exécute avant les scripts utilisateur (je vais faire quelques tests à ce sujet).

Et bien sûr, sauf erreur, les scripts d'arrière-plan ne reçoivent aucune référence au DOM/contenu dans aucun des écouteurs de navigation ?

Il s'avère que vous pouvez obtenir le contenu de la page en utilisant onBeforeRequest avec une correspondance sur ['*://*/*.user.js'] , puis en créant un StreamFilter . J'ai implémenté du code pour tester cela dans ma branche récemment publiée, aucune demande d'extraction pour le moment car cela ne répare rien. Cependant, cela évite les problèmes de sécurité que j'ai évoqués dans mon post précédent.

Malheureusement, cela ne résout pas le problème de fichier qui a été discuté. Quelques tickets bugzilla dessus :
https://bugzilla.mozilla.org/show_bug.cgi?id=1341341
https://bugzilla.mozilla.org/show_bug.cgi?id=1266960

J'ai été dirigé ici à partir du #2671

Si ce fil concerne l'importation à partir d'un fichier local .... alors ...
Pourquoi utilisez-vous XHR pour lire le fichier local ? Cela provoque toutes sortes de complications avec les origines et les autorisations.
Le moyen le plus simple est d'utiliser new FileReader() partir du résultat de input type="file"

Si ce fil concerne la reconnaissance des URL file:///.....user.js tant que scripts et leur installation, c'est le problème différent et la solution différente.

Le moyen le plus simple est d'utiliser new FileReader() à partir du résultat de input type="file"

Ah, ça pourrait marcher. Ce n'est pas aussi gracieux que de naviguer vers un chemin file:// et que l'extension fasse tout pour vous, mais cela pourrait fonctionner. La majorité du flux de travail pourrait rester le même.

import script -> script selected -> contents cached in backend -> install dialog prompt -> retrieve content from backend -> continue install as usual

Et c'est beaucoup plus sûr que les méthodes que j'essayais d'utiliser lorsque j'essayais de conserver le flux de travail de navigation.

J'ai trouvé un exemple d'extension Web fonctionnel en utilisant "input type="file"". Il semble qu'il n'y ait pas besoin de cache, peut être directement importé :
https://github.com/mdn/webextensions-examples/pull/171/files/6c066cfff4e8c662984f704cb17c8b39211ed062#diff -098de1750b345156f3cfd46f8199aa34

Semble qu'il n'y a pas besoin de cache, peut être directement importé

Ce n'est pas que le cache soit _nécessaire_, mais plutôt une mesure de sécurité. Tout comme lorsque vous accédez à un fichier .user.js, la boîte de dialogue s'affiche pour vous donner des informations sur le script. Je pense que la même chose devrait se produire lorsque vous effectuez l'importation. Par conséquent, vous devez stocker, quelque part en dehors de la base de données normale, le contenu du script de sorte que si l'utilisateur clique sur le bouton d'installation, il est toujours disponible et n'a pas besoin de demander à nouveau l'utilisateur.

Que cela soit mis en cache à l'aide d'une API de stockage ou simplement dans un objet global quelque part n'a pas particulièrement d'importance pour le flux de travail.

Je voudrais également dire qu'une fonctionnalité d'importation devrait devenir la priorité absolue[1] car elle aiderait les personnes ayant des problèmes de migration. Ils peuvent simplement importer les fichiers de 3.x.

[1] J'examinerais la question si

J'ai import./Export dans un certain nombre de mes addons si des exemples sont nécessaires.

L'importation est initiée par l'utilisateur, il n'y a donc pas besoin de précautions/fenêtres contextuelles/notifications/avertissements supplémentaires.

Ajouter un bouton d'importation (entrée de fichier) à l'un des dialogues
Une fois que l'utilisateur a cliqué dessus, le sélecteur de fichiers s'ouvre. L'utilisateur sélectionne le fichier requis et clique sur Ouvrir (tout en HTML5 intégré)
Le fichier est lu et analysé
S'il est conforme à un USER Script, il est alors ajouté à l'IDB
Ensuite, mettez à jour les écouteurs en cours d'exécution

C'est tout....

Je fais de même dans les préférences d'import/export, les données de thème (jusqu'à 500ko) et bien d'autres dans mes add-ons avec la fonction d'import/export.

Je voudrais également dire qu'une fonctionnalité d'importation devrait devenir la priorité absolue[1]

En effet .... cela permet aux scénaristes d'écrire de nouveaux scripts et d'importer pour les exécuter ou les tester et en cas de mise à niveau GM3 -> 4, ajouter les scripts manqués.

Le code et la fonction sont très simples... quelques lignes de code qui peuvent être faites en une heure.
Vous pouvez utiliser mon code comme base si vous le souhaitez.

... L'importation est initiée par l'utilisateur, il n'y a donc pas besoin de précautions/fenêtres contextuelles/notifications/avertissements supplémentaires. ... S'il est conforme à un USER Script, il est alors ajouté à l'IDB

Je ne suis pas sûr à ce sujet cependant. Je n'aime pas particulièrement sauter la boîte de dialogue d'installation standard. Peut-être que @arantius peut donner un aperçu de ce qu'il aimerait voir dans l'addon.

Je ne suis pas sûr à ce sujet cependant. Je n'aime pas particulièrement sauter la boîte de dialogue d'installation standard.

Le dialogue standard est utilisé lorsque l'utilisateur est confronté à un script utilisateur provenant d'une source distante. Un dialogue de confirmation est alors nécessaire.

En cas d'importation initiée par l'utilisateur :

• L'utilisateur décide d'importer un script
• L'utilisateur clique sur le bouton d'importation
• L'utilisateur accède au script sélectionné par l'utilisateur
• Est-il nécessaire de demander à nouveau à l'utilisateur avec une boîte de dialogue "Voulez-vous vraiment installer ce script ?" :)
  Cela semble ennuyeux. Un avertissement en cas d'erreur est cependant nécessaire.

• L'utilisateur accède au script sélectionné par l'utilisateur

Mais ce n'est pas comme ça que ça se passe... L'installation se fait par callback (déclenchement sur *.user.js)...

Mais ce n'est pas comme ça que ça se passe... L'installation se fait par callback (déclenchement sur *.user.js)...

Actuellement, oui. Mais il est possible d'ajouter un bouton d'importation pour les fichiers locaux. Et ne pas faire d'installation sur la navigation pour file:// .

Ah, d'accord, pour les fichiers locaux, c'est tout à fait approprié. Pas pour les fichiers distants ! ;-)

Mais ce n'est pas comme ça que ça se passe... L'installation se fait par callback (déclenchement sur *.user.js)...

Comme mentionné, nous parlons d'une importation manuelle à l'aide d'une entrée de fichier

Oui je l'ai eu. Ce n'est pas grave pour moi pour les fichiers locaux (voir ci-dessus)...

Je pense qu'il est possible de simplement glisser-déposer le fichier .user.js sur la fenêtre Greasemonkey pour y charger le code du script?
Étant donné que cela fonctionne définitivement pour Firefox lui-même (c'est-à-dire que je pourrais télécharger un fichier sur le site Web, comme imgur, ou megaupload en le déposant)

Existe-t-il un moyen (même maladroit, sans glisser-déposer) qui me permette d'importer des scripts GM locaux ?

Dans quel répertoire "cache" exactement les scripts doivent-ils être finalement placés ? J'ai trouvé plusieurs fichiers "cache" dans le profil Firefox

Je pense qu'il est possible de simplement glisser-déposer le fichier .user.js sur la fenêtre Greasemonkey pour y charger le code du script?

C'est possible, comme n'importe quelle autre boîte de dépôt (consultez mon IMGoolge pour un exemple). Cependant, l'entrée de fichier directe serait la méthode la plus simple sans avoir besoin d'auditeurs et de processus supplémentaires.

Mozilla a mis à jour la doc (résumé des exemples ci-dessus) :
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_files

1. Ouvrir des fichiers dans une extension à l'aide d'un sélecteur de fichiers
2. Ouvrir des fichiers dans une extension par glisser-déposer

Avec cela implémenté, nous aurions le même comportement que dans GM3.

Alors, des suggestions possibles pour installer manuellement un script qui n'est pas proposé sous une forme en ligne appropriée ?

@Samizdata Actuellement, le moyen le plus simple est d'obtenir la version bêta de GM (https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/beta), ouvrez le menu Monkey -> nouveau script.

Si vous avez des scripts qui nécessitent des fichiers locaux, vous ne pouvez le faire qu'à la dure. Par exemple, récupérez Proxomitron ( http://www.proxomitron.info/files/ ), exécutez-le, configurez FF pour utiliser le proxy 127.0.0.1:8080, placez vos fichiers dans le dossier HTML de Proxomitron et accédez-y ensuite dans FF avec " http: //bweb..local.ptron/VOTRE FICHIER.user.js ".

@kekkc , je pense qu'une nouvelle version avec le problème de ressource distante résolu a été poussée vers AMO.

À votre santé. C'est fait, @kekkc !

@kekkc , je pense qu'une nouvelle version avec le problème de ressource distante résolu a été poussée vers AMO.
Pas encore... d'après ce que je peux voir

@Sxderp Faisons -nous référence à #2707 ?

@Eselce , oui. Cela _devrait_ résoudre les problèmes présents lors de la création d'un nouveau script avec le bouton « nouveau script », puis de l'application d'une balise @require au script.

Pour qu'un .user.js ou un script requis soit servi localement, il existe plusieurs possibilités. Mais le moyen le plus simple consiste à utiliser ce one-liner Python sur votre ligne de commande :

• pour Python 2.x :
  python -m SimpleHTTPServer

• pour Python 3.x :
  python -m http.server

... qui commence immédiatement à servir tous les fichiers du répertoire où vous l'exécutez, sur http://127.0.0.1:8000/

(_notez que 8000 est le port par défaut ; vous pouvez le modifier ; voir ci-dessous_)

C'est ainsi que j'ai mis mon .user.js local et que j'ai besoin de fichiers sur un serveur http local. Je fais ça pour Greasemonkey mais aussi pour Tampermonkey.

Python est installé par défaut sous Linux et MacOs. Si vous utilisez Windows et ne l'avez pas installé et prévoyez toujours de continuer à vous appeler développeur, alors... _sérieusement ?! qu'est-ce qui ne va pas chez toi ?_ tu as des problèmes bien plus sérieux que tu ne peux commencer à réaliser ! Je suggérerais de jardiner :semis: ou de tricoter comme passe-temps plutôt que d'ordinateurs pour vous :wink: (_hey, je plaisante !_)

Il n'est pas nécessaire d'installer des programmes étranges -- vous _ pouvez _, mais c'est _absolument inutile_. Python n'est pas une "application", c'est un langage de programmation fondamental. Mais vous n'avez même pas besoin de "parler" Python pour cette solution, alors n'abandonnez pas ou ne vous précipitez pas sur vos outils de tricot pour l'instant !

Procédure triviale :

1. cd dans le répertoire contenant vos .user.js et/ou fichiers requis. Disons, par exemple, requiredFile1.js et requiredFile2.js

2. À partir de ce répertoire : pour Python 2.x, exécutez

python -m SimpleHTTPServer

OU : pour Phython 3.x, exécutez

python -m http.server

1. Assurez-vous que vos lignes @require sont comme celles-ci :

// <strong i="42">@require</strong>  http://127.0.0.1:8000/requiredFile1.js
// <strong i="43">@require</strong>  http://127.0.0.1:8000/requiredFile2.js

...où requiredFile1.js et requiredFile2.js sont les fichiers locaux requis que vous souhaitez servir.

1. Lorsque votre script graissemonkey se déclenche, il récupère correctement les exigences, qui sont servies par Python.

Terminé.

Pour fermer votre serveur local, accédez simplement à la console où vous exécutez la commande python et appuyez sur <Ctrl><C> .

De plus, -_-et j'espère que cela est ridiculement évident pour vous_--, n'oubliez pas d'exécuter la ligne de commande de votre serveur HTTP Python avant de vous attendre à ce que Greasemonkey ou Tampermonkey puisse trouver les fichiers...

Astuce : Si vous souhaitez utiliser un autre port que celui par défaut 8000 , saisissez simplement le numéro souhaité (un numéro de port valide) dans votre commande, comme ceci :

• pour Python 2.x :
  python -m SimpleHTTPServer 12345

• pour Python 3.x :
  python -m http.server 12345

...et mettez naturellement à jour les URL @require avec ce numéro au lieu de 8000.

Ok, supposons que je clique sur l'icône de la barre d'outils GM et que je sélectionne "Nouveau script utilisateur...".

Le nouvel onglet correspondant est automatiquement nommé "Unnamed Script 821696"

Ensuite, je colle un code GM de fichier local dans le volet d'onglets et je clique sur l'icône "enregistrer" en haut à gauche.

Où puis-je trouver plus tard ce script ? Lire : Comment modifier ultérieurement ce script ?

Comment puis-je changer le nom du script en "foobar" par exemple ?

@bsto Le nom sera tiré du script @name.
Tous les nouveaux scripts apparaîtront au-dessus de "Nouveau script utilisateur...".
Pour supprimer ou modifier celui que vous cliquez sur le titre du script, il y aura un sous-menu.

D'accord, merci.

Juste une autre question :

Le 25 novembre, l'utilisateur kekkc nous a dit dans sa publication (voir ci-dessus) que Mozilla offrait un moyen de glisser-déposer des fichiers (depuis WinExplorer).

Le glisser-déposer des fichiers utilisateur devrait donc être possible maintenant.

Ai-je raison?

Quand sera-t-il implémenté dans GM (disponible pour le glisser-déposer des fichiers *.user.js) ?

FWIW Je pense que nous pouvons/devrions détecter la navigation vers file://.../anything.user.js , et attacher une action de page qui pourrait ouvrir une interface utilisateur avec n'importe quel type de navigateur de fichiers que nous pouvons faire fonctionner.

Nous pouvons détecter les événements de navigation mais ne pas obtenir de contenu (peut-être dans un script de contenu)

Bien que je trouve idiot de naviguer vers un file:// juste pour ouvrir un navigateur de fichiers (je ne pense pas que nous puissions faire autre chose qu'une entrée de sélecteur de fichiers).

Bien que je trouve idiot de naviguer vers un fichier:// juste pour ouvrir un navigateur de fichiers (je ne pense pas que nous puissions faire autre chose qu'une entrée de sélecteur de fichiers).

Oui exactement, nous sommes paralysés. Mais nous pouvons détecter l'intention et être aussi utiles que possible dans notre environnement limité.

Mes 2 centimes...

FWIW Je pense que nous pouvons/devrions détecter la navigation vers file://.../anything.user.js ,
Nous pouvons détecter les événements de navigation mais ne pas obtenir de contenu (peut-être dans un script de contenu)

Comme évoqué par Sxderp, c'est possible mais un peu brouillon...

• Ajoutez un écouteur (comme tabs.onUpdated.addListener puisque vous auriez besoin du contenu de toute façon)
• Laissez la page se charger en affichant le script
• Injecter le script de contenu pour récupérer le contenu de la page et le transmettre au script bg
• Fermer la page/l'onglet

Alternative ....

• Ajouter un écouteur de navigation
• Arrêtez le chargement de la page et affichez une notification pour utiliser l'option d'importation ... OU .... popup indiquant l'option d'importation sur laquelle l'utilisateur doit cliquer pour lancer le sélecteur de fichiers

Personnellement, si c'était moi, j'opterais pour ne pas ajouter d'auditeurs supplémentaires et ajouterais simplement l'option IMPORT au popup browserAction

De plus, je n'utilise pas le format .user.js depuis GM4 de toute façon et je pense qu'il peut être laissé de côté. ;)

Personnellement, si c'était moi, j'opterais pour ne pas ajouter d'auditeurs supplémentaires et simplement..

C'est ce que je voulais dire. Je pourrais cependant injecter une interface utilisateur dans la page de contenu. Nous avions l'habitude d'afficher une barre d'informations si vous naviguiez vers un script alors que GM était désactivé ; ce genre de chose.

De plus, je n'utilise pas le format .user.js depuis GM4 de toute façon et je pense qu'il peut être laissé de côté. ;)

Qu'est-ce que ça veut dire?

Qu'est-ce que ça veut dire?

GM3 exigeait que les scripts soient nommés abc.user.js afin qu'ils puissent être reconnus comme des scripts GM.

Dans GM4, les scripts sont enregistrés dans IndexedDB et le nom du script n'a pas vraiment d'importance car il tire son nom de @name . Par conséquent, j'ai créé et enregistré mes scripts (sur ordinateur) en tant que abc.js (sans le .user ) et les ai copié/collé dans GM.

L'IMPORT manuel, j'imagine, n'aurait pas besoin d'être lié au format de nommage .user .

Des progrès à ce sujet ?

FireMonkey Extension peut faire ceci :

https://addons.mozilla.org/en-US/firefox/addon/firemonkey/