Greasemonkey: WebExt : prend en charge toutes les API GM

bug1323433 et bug1332273 peuvent être intéressants ici.

Merci pour les pointeurs, je suis d'accord qu'ils sont tous les deux super utiles.

Oh, peut-être qu'une certaine quantité de transmission de messages synchrone est possible !

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessage#Sending_a_synchronous_response

Testez ceci. Cela permet-il d'utiliser une implémentation synchrone simple (soutenue par des API en arrière-plan uniquement) pour les méthodes mentionnées ci-dessus ?

Cela renvoie une promesse du côté du contenu, il est donc effectivement asynchrone. Je pense que "synchrone" est un terme impropre ici, c'est plus comme associer un message d'un enfant à un parent avec une réponse afin que l'on n'ait pas à suivre manuellement les réponses en attente.

Afaik, la seule API synchrone disponible est la synchronisation XHR qui pourrait ensuite être interceptée avec une requête Web ou quelque chose comme ça.

La synchronisation XHR ne fonctionne pas correctement dans le script de contenu : https://bugzilla.mozilla.org/show_bug.cgi?id=1360968, donc pour le moment, nous n'avons aucun canal de synchronisation à partir du contenu > arrière-plan.

On dirait que GM_setValue et GM_getValue été conçus comme une opération de synchronisation et dans un seul navigateur de processus, ils fonctionnent très bien lorsque nous fonctionnons dans plusieurs onglets, mais dans e10s non (https://github.com/greasemonkey /greasemonkey/issues/2427). Avec l'ancienne API d'extension, cela peut être facilement réparé, mais pas dans WebExt. Sans message de synchronisation (même pour les petites données, n'émettez qu'une valeur courte), nous ne pouvons pas synchroniser correctement la valeur entre plusieurs onglets. à un moment donné, ce sera toujours une condition de course.

Quelle que soit la manière dont vous résolvez les problèmes ci-dessus dans la version WebExt, nous devrions obtenir une nouvelle méthode set/get conçue de manière asynchrone, donc là où il est important, nous pouvons écrire le script de manière asynchrone. Les documentations devraient contenir des informations sur le manque de GM_setValue et le comportement de GM_getValue lorsqu'ils fonctionnent sur plusieurs onglets.

imo, il est rare d'utiliser GM_setValue / GM_getValue sur plusieurs onglets et l'ordre doit être suivi. par conséquent, le stockage d'une copie (cache) de _GM_values_ dans le script de contenu, la lecture permanente à partir du cache, la réécriture asynchrone et la mise à jour du cache avec les événements déclenchés par le script d'arrière-plan devraient être une solution acceptable.

d'ailleurs, si c'est le cas, ajouter une API équivalente à GM_addValueChangeListener est super si possible. (et je n'aime pas le nom addValueChangeListener quelque chose d'autre devrait être mieux peut-être

Dans ma branche dev, il existe un support pour :

• GM.getResourceURL
• GM.deleteValue , GM.getValue , GM.listValues , GM.setValue

Je compte ne jamais ajouter :

• GM_log
• GM_addStyle

Il nous faut encore :

• GM_xmlhttpRequest

Je prévois de retarder (ou peut-être d'abandonner) :

• GM_registerMenuCommand (celui-ci a toujours été un énorme coût de support)
• GM_getResourceText

Ce qui signifie que les progrès ici sont en fait assez proches.

Bon retour au commit ci-dessus, n'oubliez pas.

Je viens d'essayer le nouveau module complémentaire. Il semble que la requête xhr interdomaine ait déjà été activée sans les fonctionnalités GM_xhr. Est-ce bien un comportement ?

Essayez simplement un script utilisateur n'en accordez aucun avec les codes suivants :

fetch(prompt()).then(resp => resp.text()).then(text => alert(text)).catch(error => alert(error));

Euh, confirmé. Nous exécutons actuellement des scripts utilisateur en tant que "scripts de contenu" -- de l'extension, avec toutes les autorisations de l'extension.

J'ai un peu examiné cela, mais jusqu'à présent, je ne sais pas comment exécuter du code non privilégié ("portée Web" - comment appelons-nous cela maintenant que la portée "contenu" est ambiguë ?!). La chose la plus proche que je puisse trouver concerne la création de balises de script, qui peuvent/seront bloquées par le CSP de la page, ce que je ne veux absolument pas.

Actuellement, le seul moyen de modifier le CSP est d'intercepter et de modifier les en-têtes pour chaque demande de document. Il existe des problèmes ouverts pour exempter les extensions Web des CSP de contenu, mais il ne semble pas y avoir beaucoup d'activité sur ceux-ci.

En plus d'injecter des balises <script> window.eval devrait également s'exécuter dans la portée de la page, je pense.

Les termes officiels sont « étendue du script de contenu » par rapport à « étendue de la page ».

Un autre problème est qu'ils auraient besoin d'un traitement de chaîne pour les envelopper dans une portée distincte qui pourrait définir les API GM.

J'ai également signalé un bogue pour les équivalents de Sandbox dans les extensions Web, mais ce n'est pas non plus une priorité élevée.

AIUI script et eval sont vulnérables au blocage par CSP. Mais j'ai confirmé que eval supprime les privilèges.

https://bugzilla.mozilla.org/show_bug.cgi?id=1391669

Nous devons avoir <all_urls> si nous voulons potentiellement exécuter un script de contenu sur n'importe quelle page. Si nous demandons cela, notre script de contenu l'obtient et peut donc XHR n'importe où.

Au moins dans Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval ()_in_content_scripts ) nous pouvons descendre à la portée de la page, mais alors nous sommes vraiment la portée de la page et nous ne peut pas exposer en toute sécurité les API au script sans l'exposer à quoi que ce soit/tout ce qui s'exécute dans la page (AFAIK), ce qui est encore pire.

Fetch et xhr peuvent-ils être écrasés dans le script de contenu ?
Peut-être fournir une récupération modifiée qui effectue sa propre vérification CORS.

• GM.xmlhttpRequest() été ajouté dans 60a50d05b1e565571d8a3e638b0683a1a9c2beaa
• GM.getResourceText() sera couvert dans #2548
• GM.registerMenuCommand() est intentionnellement ignoré.
• Chaque script héritant de cross-origin-fetch (selon le commentaire ci-dessus) est #2549

@the8472 Voir mon implémentation de withUnsafeWindow() dans https://github.com/greasemonkey/greasemonkey/issues/2232#issuecomment -326841025

Il imite le comportement de l'ancienne fonction with (object) ... , juste un peu plus sûr. (Besoin de navigateurs modernes.)

@arantius a écrit le 25 juillet :

Je compte ne jamais ajouter :

GM_log
GM_addStyle

Celles-ci ont été signalées dans la création de ce ticket (par @arantius le 3 mars ) comme triviales (en supposant un mappage de GM_log vers console.log).

D'après mon expérience, ce sont deux des appels d'API les plus couramment utilisés. Les abandonner ne briserait-il pas beaucoup de vieux scripts sans raison ? Ou faisiez-vous exclusivement référence à la branche dev ?

Dans Tampermonkey, GM_addStyle a une capacité spéciale pour injecter un style qui peut contourner la restriction CSP (au cas où l'inline <style> est interdit). Je serais heureux si nous pouvons également avoir cette fonctionnalité dans Greasemonkey.