Je pense vraiment que cela devrait être repensé. VM et TM se comportent contrairement à cela. Lorsque vous naviguez vers un script, une page qui comprend à la fois le contenu/la source du script et un bouton d'installation s'affiche. Alors que vous êtes techniquement " redirigé ", vous êtes toujours, en substance, " en train de naviguer " vers le script utilisateur. Peut-être que cela devrait être mentionné sur la liste de diffusion -users et -dev et voir les opinions des autres ?

Je soutiens la discussion communautaire.

Personnellement, je suis d'avis que ~personne ne révise la source, c'est donc une chose idiote de la montrer à tous les utilisateurs, y compris la majorité qui ne peut même pas la comprendre.

Et : examiner uniquement la source principale, lorsqu'il y a également un @require , n'apporte que très peu de résultats.

Je serais vraiment triste si la possibilité de revoir le code source ne revient pas. Je me sens toujours plus à l'aise en survolant le code. Et s'il y a des inclusions de @require qui ne pointent pas vers une bibliothèque bien connue (jQuery hébergée officiellement, etc.), je suis toujours sceptique et j'abandonne généralement l'installation à moins que j'aie vraiment besoin de ce script (auquel cas je survole le contenu de

Mais même si je suis une exception et que la plupart des gens ne regardent pas ou ne comprennent pas le code, je pense qu'il y a un effet préventif pour les scénaristes de savoir que la source est affichée lors de l'installation.

Si vous décidez toujours de ne pas afficher le code source, veuillez ajouter une vue source facilement accessible : des liens pointant vers le code source lors de l'installation d'un script (et de préférence également tous les scripts @require inclus).

Comme mentionné, j'apprécie également la capacité de révision. Pour la minorité des gens qui le veulent. Je veux juste que cela fonctionne comme #2567 afin que vous puissiez revoir _tout_ la source. Il vous suffit de cliquer sur modifier après l'installation et d'afficher toutes les ressources source et texte. Activez ou désinstallez comme vous le souhaitez.

L'exigence de plusieurs requêtes réseau a des implications sur les performances. Plus précisément, entre vos 3. et 4. il y a le "téléchargement jusqu'au point où nous avons un métabloc valide, afin que nous puissions ouvrir la boîte de dialogue d'installation".

Disons que le fichier n'est pas un script utilisateur réel et n'a pas de métabloc valide. La boîte de dialogue d'installation ne s'affichera jamais. La seule solution que je vois est de reprendre la navigation. Une fois la navigation reprise, le fichier doit être retéléchargé. Une requête inutile (#2830 résout ce problème en développant ce qui est actuellement fait dans onHeadersReceived ).

Vous avez déjà fait valoir ce point et il devrait être pris en compte. Que se passe-t-il si la connexion est lente ? À titre d'exemple, disons qu'il faut 10 secondes pour télécharger le fichier. L'utilisateur aura 10 secondes sans retour pendant que GM tente le téléchargement à la recherche d'un script. Il échoue et le remet au navigateur pour continuer la navigation. Encore 10 secondes supplémentaires en téléchargeant le fichier pour l'affichage.

Je ne vais pas dire qu'il n'y a aucun moyen de contourner cela. Par exemple, les données peuvent être mises en cache ou autre, puis écraser la sortie lors de la navigation réelle. Mais j'ai l'impression que cela conduit à une complexité de code inutile juste pour protéger les utilisateurs.

Alternativement, vous pouvez quand même afficher la boîte de dialogue d'installation et échouer à installer le fichier non-script (la VM le fait). Je considérerais cette mauvaise UX.

Si quelqu'un peut trouver une façon propre de le faire sans les demandes supplémentaires, tant mieux. Sinon, je ne peux pas m'en remettre sans les avantages _réels_. [1]

[1] Vous avez mentionné "être en mesure de revoir _tout_ le code source" en raison de #2567 comme étant un avantage potentiel. Mais je ne suis pas d'accord. J'ai l'impression que #2567 devrait être une fonctionnalité _peu importe_ si le code source est disponible à l'installation ou non.

Je ne sais pas. Sur d'autres sujets, j'ai pu revenir après quelques discussions. Mais c'en est un que je ne « vois » tout simplement pas.

De mon point de vue, je me fiche que le script soit immédiatement visible, mais je pense que si j'annule l'installation ou quelque chose, je devrais pouvoir voir le fichier brut comme je l'aurais fait si graissemonkey n'était pas installé. Peu m'importe s'il est masqué par défaut ou quelque chose du genre, mais un moyen de fermer la boîte de dialogue d'installation et de revenir au script semble critique.

Je ne pense pas qu'il soit logique d'interrompre la visualisation des choses appelées *.user.js . Cela supprime la fonctionnalité du navigateur.

Je considère un script utilisateur plus comme une extension qu'une page Web. Vous ne naviguez jamais non plus vers une extension. Vous le téléchargez/installez, ou vous ne le faites pas.

Je ne pense pas qu'il soit logique d'interrompre l'affichage des éléments appelés *.user.js. Cela supprime la fonctionnalité du navigateur.

Il fait également des choses comme le faisaient les versions précédentes de GM - y compris ne pas toucher aux navigations lorsqu'elles sont désactivées. Si vous avez désespérément besoin de voir cela dans votre navigateur, désactivez d'abord GM.

Je considère un script utilisateur plus comme une extension qu'une page Web. Vous ne naviguez jamais non plus vers une extension. Vous le téléchargez/installez, ou vous ne le faites pas.

Je ne suis pas d'accord avec ce raisonnement. Une extension est un ensemble de fichiers archivés. Un script utilisateur ne l'est pas. Vous pourriez argumenter sur @requires et @resources mais je pense que c'est ténu. Tous ne les utilisent pas et beaucoup d'entre eux ne sont que du texte brut. Lorsque vous accédez à une page de texte brut, vous n'êtes généralement pas obligé (en supposant que l'en-tête de pièce jointe/téléchargement n'est pas défini, ce que je trouve ennuyeux aussi) de la télécharger avant de la visualiser.

Il fait aussi des choses comme les versions précédentes de GM l'ont fait

Bien sûr, mais je ne pense pas que ce soit un bon argument pour ou contre une fonctionnalité en particulier. La version précédente peut donner une base mais à l'avenir, je pense que tout devrait être réexaminé dans de nouveaux contextes. Cela inclut la complexité du code, les avantages qu'il inculque ou non, les mérites, etc.

Vous ne naviguez jamais non plus vers une extension. Vous le téléchargez/installez, ou vous ne le faites pas.

Être un fichier texte fait une différence. Par exemple, github a une option "view raw" qui est maintenant cassée.

y compris ne pas toucher les navigations lorsqu'elles sont désactivées.

C'est bon à savoir. Je suppose que j'ai peut-être deviné cela, mais ce n'est vraiment pas évident. Je suis juste énervé parce que j'essayais de visualiser un fichier et il ne s'affichera pas. Peut-être pourrions-nous indiquer à l'utilisateur que cela peut être fait lorsqu'il le rencontre, plutôt que d'afficher une page blanche.

J'apprécie de prendre des décisions de conception qui offrent le plus de valeur au plus grand nombre d'utilisateurs, donc j'apprécie la contribution.

Ce sera cependant un cas rare où je mets le pied à terre. Ne vous embêtez pas à débattre des approches. Je veux le comportement de : il y a un lien vers un script utilisateur valide, je clique sur ce lien, je vois (seulement) la boîte de dialogue d'installation, et je ne navigue jamais vers un fichier texte, en fait je ne vois jamais la source. Je vais faire ce qu'il faut pour que Greasemonkey agisse de cette façon. Période.

Avant WebExt, nous obtenions cela en utilisant http-on-modify-request , pour suspendre dès que possible toute requête ressemblant à un script utilisateur. Nous déclencherions la boîte de dialogue d'installation et lancerions une opération annulerait la demande qu'il possède, et ... quelque chose redémarrerait la navigation (je pense en reprenant le canal exactement, mais je ne trouve pas).

Avec un script lent , rien ne se passe au début -- une fois la partie ==UserScript== chargée, la boîte de dialogue d'installation apparaît, puis sa barre de progression se remplit au fur et à mesure que le reste est téléchargé -- le reste du script, la ressource, nécessite , etc.

Il parvient à télécharger le script avec une seule connexion au serveur.

Sous WebExt, toutes les API sont bien sûr différentes, mais l'événement de blocage/filtrage onHeadersReceived déjà en place à HEAD _semble_ être la meilleure chose à utiliser. Je dois encore faire des recherches.

Je veux le comportement de : il y a un lien vers un script utilisateur valide, je clique sur ce lien, je vois (seulement) la boîte de dialogue d'installation, et je ne navigue jamais vers un fichier texte, en fait je ne vois jamais la source. Je vais faire ce qu'il faut pour que Greasemonkey agisse de cette façon.

Mais c'est un changement par rapport à l'ancien comportement. GM 3.x J'ai eu la possibilité de cliquer sur afficher la source au lieu d'installer et rien n'a été installé, mais j'ai eu un onglet qui affichait la source du script. A partir de là, j'avais la possibilité d'installer ou simplement de fermer l'onglet et de ne rien faire. Ce serait le comportement que j'aimerais au moins revoir. Pour moi, il n'est pas nécessaire de toujours afficher la source, mais une option pour l'inspecter avant d' installer quoi que ce soit comme avant, serait géniale.

La raison de cette demande est que j'ai vu les dommages que les scripts malveillants peuvent causer et donc j'inspecte toujours la source avant d'installer quoi que ce soit. C'est la raison pour laquelle je considère également la mise à jour automatique silencieuse comme un problème car elle pourrait apporter un nouveau code malveillant à l'utilisateur.

Avec webRequest vous pouvez renvoyer une fausse URL pour annuler le chargement et faire en sorte que le navigateur reste là où il se trouve. Mais cela interrompt immédiatement la connexion, vous ne pouvez pas également utiliser le filtre pour observer/analyser/modifier le contenu, vous devrez donc démarrer une nouvelle connexion. Je pense que c'est bien dans ce cas, car nous avons toutes les données dont nous avons besoin (méthode de requête, en-têtes de réponse) dans la portée et nous pouvons donc décider en toute confiance s'il s'agit vraiment d'un script utilisateur ou non, et c'est aussi très tôt dans le cycle de demande.

J'avais la possibilité de .. l'inspecter avant d'installer quoi que ce soit ...

2567

Et s'il ressemble à un script utilisateur, mais qu'il ne l'est pas ? Par exemple, si vous prenez votre exemple de chargement lent et supprimez simplement le // ==UserScript== initial. Ouvrez-le dans 3.x, la boîte de dialogue d'installation ne s'ouvre jamais (correct) puis le contenu du texte est écrit dans l'onglet / la page. Avec WebEx, si vous créez une nouvelle connexion en arrière-plan, je ne vois pas comment vous pouvez écrire le contenu sur la page. Pour autant que je sache, le seul moyen direct d'écrire du contenu sur une page en arrière-plan consiste à utiliser le filtre de flux.

Je peux penser à des façons de « contourner » cela. Encore une fois pas de bonnes solutions. Transmettez les données à un script de contenu qui fera simplement écho au contenu (devrait être faisable, je pense). Redirigez vers une page d'extension, mais cela brisera l'histoire. Ou faites en sorte que FF redémarre la demande avec un indicateur défini pour ignorer la vérification du script. Mais alors c'est une troisième demande..

Peut-être que j'ai raté quelque chose..

Ouvrez-le dans 3.x, la boîte de dialogue d'installation ne s'ouvre jamais (correct) puis le contenu du texte est écrit dans l'onglet / la page.

Euh, je voudrais corriger ce point. Je me suis trompé, j'avais une faute de frappe dans user lors du test initial.

@Sxderp permettez-moi de répéter que j'apprécie grandement les contributions que vous avez apportées à ce jour et j'espère que vous continuerez.

Mais pour un peu plus de clarté quant à ma décision décrite ci-dessus : j'ai nettoyé mon travail en cours ; d'abord, j'ai déplacé certains travaux sans rapport pour séparer les commits . Il ne restait plus qu'un renommage de fichier puis ce gros commit , qui n'est que de + 425 -491 .

La classe Downloader encapsule toute la logique concernant (le téléchargement et) l'installation d'un script, quelle que soit la source. Vous avez juste besoin de configurer les entrées - juste l'URL pour une installation, mais aussi la source principale du script et peut-être le contenu de l'exigence/de la ressource s'il est déjà connu (pour le cas d'édition), il télécharge tout ce qui manque (c'est-à-dire modifier dans une nouvelle exigence /resource) et passe toujours un même format à user-script-regstry qui le persiste dans un seul sens. L'ensemble du downloader.js est inférieur à 250 lignes. Il y a donc moins de messages passés entre l'arrière-plan/le contenu et aucun nouveau port.

Il y a des moments où il est très logique de diviser un gros morceau de code complexe en morceaux plus petits et plus simples. Mais l'OMI ce n'est pas ça. Les données qui circulent sont les mêmes, que nous installions un "nouveau" script, que nous en mettions un à jour ou que nous en modifiions un sur place. Seules des choses mineures changent (connaît-on déjà l'UUID du script déjà installé ? savons-nous déjà ou devons-nous télécharger ceci ou cela ?).

Cela résout-il également la structure récursive de parsedDetails (il y a un problème quelque part, vous n'avez pas le temps de le chercher) ?

Je ne sais pas. J'en doute?

Cela résout-il également la structure récursive de parsedDetails (il y a un problème quelque part, vous n'avez pas le temps de le chercher) ?

Tu veux dire #2806 ?