Greasemonkey: WebExt: Unterstützt alle GM-APIs

bug1323433 und bug1332273 könnten hier von Interesse sein.

Danke für die Hinweise, ich stimme zu, dass beide super nützlich sind.

Oh, vielleicht ist eine gewisse Menge an synchroner Nachrichtenweitergabe möglich!

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

Testen Sie dies. Ermöglicht dies die Verwendung einer einfachen synchronen Implementierung (unterstützt durch Nur-Hintergrund-APIs) für die oben genannten Methoden?

Dies gibt ein Versprechen auf der Inhaltsseite zurück, sodass es effektiv asynchron ist. Ich denke, "synchron" ist hier eine falsche Bezeichnung, es ist eher so, als würde man eine Nachricht von einem Kind an ein Elternteil mit einer Antwort koppeln, damit man ausstehende Antworten nicht manuell verfolgen muss.

Afaik die einzige verfügbare synchrone API sind Sync-XHRs, die dann mit Webrequest oder ähnlichem abgefangen werden könnten.

Die Synchronisierung von XHR funktioniert im Inhaltsskript nicht richtig: https://bugzilla.mozilla.org/show_bug.cgi?id=1360968, daher haben wir derzeit keinen Synchronisierungskanal von Inhalt > Hintergrund.

Sieht so aus, als ob GM_setValue und GM_getValue als Synchronisierungsvorgang konzipiert wurden und in einem einzelnen Prozessbrowser funktionieren sie gut, wenn wir in mehreren Registerkarten arbeiten, aber in e10s nein (https://github.com/greasemonkey /greasemonkey/issues/2427). Mit der alten Erweiterungs-API lässt es sich leicht reparieren, in WebExt jedoch nicht. Ohne Sync-Nachricht (auch für kleine Daten, nur kurze Werte ausgeben) können wir den Wert zwischen mehreren Registerkarten nicht richtig synchronisieren. Irgendwann wird dies immer eine Rennbedingung sein.

Unabhängig davon, wie Sie die oben genannten Probleme in der WebExt-Version lösen, sollten wir eine neue asynchrone set/get-Methode erhalten, damit wir das Skript, wo es wichtig ist, asynchron schreiben können. Dokumentationen sollten einige Informationen über das Verhalten von GM_setValue und GM_getValue , wenn auf mehreren Registerkarten gearbeitet wird.

Imo, es gibt seltene Anwendungsfälle, in denen GM_setValue / GM_getValue auf mehreren Registerkarten verwendet wird und die Reihenfolge eingehalten werden muss. Daher sollte das Speichern einer Kopie (Cache) von _GM_values_ im Inhaltsskript, das Lesen immer aus dem Cache, das asynchrone Zurückschreiben und das Aktualisieren des Caches mit Ereignissen, die durch das Hintergrundskript ausgelöst werden, eine akzeptable Lösung sein.

Übrigens, wenn ja, fügen Sie ein API-Äquivalent zu GM_addValueChangeListener wenn möglich. (und ich mag den Namen nicht addValueChangeListener etwas anderes sollte vielleicht besser sein

In meinem Dev-Zweig gibt es Unterstützung für:

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

Ich habe vor, niemals hinzuzufügen :

• GM_log
• GM_addStyle

Wir brauchen noch :

• GM_xmlhttpRequest

Ich plane zu verzögern (oder vielleicht fallen zu lassen):

• GM_registerMenuCommand (dieser war schon immer ein enormer Supportaufwand)
• GM_getResourceText

Was bedeutet, dass der Fortschritt hier tatsächlich ziemlich nahe ist.

Gutes Feedback zu obigem Commit, nicht vergessen.

Ich habe gerade das neue Add-On ausprobiert. Es scheint, dass die domänenübergreifende xhr-Anfrage bereits ohne GM_xhr-Funktionen aktiviert wurde. Ist das wirklich ein Verhalten?

Versuchen Sie es einfach mit einem Userscript-Grant None mit den folgenden Codes:

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

Äh, bestätigt. Wir führen derzeit Benutzerskripte als "Inhaltsskripts" aus – der Erweiterung mit allen Berechtigungen der Erweiterung.

Ich habe mir das ein wenig angesehen, aber bisher tappte ich im Dunkeln, wie man unprivilegierten Code ("Web-Bereich" - wie nennen wir das jetzt, da "Inhalt"-Bereich mehrdeutig ist?!)) ausführt. Das nächste, was ich finden kann, ist das Erstellen von Skript-Tags, die vom CSP der Seite blockiert werden können/werden, was ich definitiv nicht möchte.

Derzeit besteht die einzige Möglichkeit zum Ändern von CSP darin, die Header für jede Dokumentanforderung abzufangen und zu ändern. Es gibt noch offene Fragen, um Weberweiterungen von Content-CSPs auszunehmen, aber es scheint nicht viel diesbezüglich zu geben.

Neben dem Einfügen von <script> Tags sollte window.eval auch im Seitenbereich laufen, denke ich.

Die offiziellen Begriffe sind "Inhaltsskriptbereich" vs. "Seitenbereich".

Ein weiteres Problem besteht darin, dass sie eine String-Verarbeitung benötigen, um sie in einen separaten Bereich einzuschließen, der die GM-APIs definieren könnte.

Ich habe auch einen Fehler für Sandbox Äquivalente in Weberweiterungen gemeldet, aber er hat auch keine hohe Priorität.

Sowohl Skript als auch eval von AIUI sind anfällig für Blockierungen durch CSP. Aber ich habe bestätigt, dass eval Privilegien verliert.

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

Wir müssen <all_urls> wenn wir möglicherweise ein Inhaltsskript auf einer beliebigen Seite ausführen möchten. Wenn wir danach fragen, bekommt unser Inhaltsskript das und kann XHR überall hin senden.

Zumindest in Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval ()_in_content_scripts ) können wir bis zum Seitenbereich herunterfallen, aber dann sind wir wirklich Seitenbereich und wir kann APIs dem Skript nicht sicher zugänglich machen, ohne es für alles/alles auszusetzen, was auf der Seite (AFAIK) ausgeführt wird, was noch schlimmer ist.

Können fetch und xhr im Content-Skript überschrieben werden?
Stellen Sie möglicherweise einen modifizierten Abruf bereit, der seine eigene CORS-Überprüfung durchführt.

• GM.xmlhttpRequest() wurde hinzugefügt in 60a50d05b1e565571d8a3e638b0683a1a9c2beaa
• GM.getResourceText() wird in #2548 behandelt
• GM.registerMenuCommand() wird absichtlich übersprungen.
• Jedes Skript, das Cross-Origin-Fetch erbt (wie im Kommentar oben) ist #2549

@the8472 Siehe meine Implementierung von withUnsafeWindow() in https://github.com/greasemonkey/greasemonkey/issues/2232#issuecomment -326841025

Es ahmt das Verhalten der alten with (object) ... Funktion nach, nur ein bisschen sicherer. (Brauchen Sie moderne Browser.)

@arantius schrieb am 25. Juli :

Ich habe vor, niemals hinzuzufügen :

GM_log
GM_addStyle

Diese wurden bei der Erstellung dieses Tickets (von @arantius am 3. März ) als trivial bezeichnet (unter der Annahme einer Zuordnung von GM_log zu console.log).

Nach meiner Erfahrung sind dies zwei der am häufigsten verwendeten API-Aufrufe. Würde es nicht viele alte Skripte grundlos brechen, wenn man sie aufgibt? Oder hast du dich ausschließlich auf den Dev-Zweig bezogen?

In Tampermonkey hat GM_addStyle eine spezielle Fähigkeit, Stil einzufügen, der die CSP-Einschränkung umgehen kann (falls Inline <style> verboten ist). Ich würde mich freuen, wenn wir diese Funktion auch in Greasemonkey haben können.