Greasemonkey: WebExtension-Kompatibilität

Ich habe darüber eine Menge nachgedacht. Ich habe keine klare "Entscheidung", aber einige Punkte:

• Wir sind _gerade_ mit der Portierung für die e10s-Kompatibilität fertig geworden. Es war viel schwieriger, als wir anfingen; zB Services.ppmm und .cpmm sind nette Abkürzungen, auf die man sich gerne von Anfang an verlassen könnte, aber sie existierten noch nicht, als wir (verantwortlich) anfingen.
• Diese Arbeit war lang und sehr schmerzhaft, und ich freue mich nicht darauf, sie effektiv zu wiederholen.
• Der Rollout von e10s ist von Firefox 36 (Stand Sep 2014) auf Firefox 42 (Stand Sep 2015) oder mindestens neun Monate gerutscht.
• In der Ankündigung heißt es, dass Webextensions-only mindestens 1 oder 2 Jahre entfernt ist; wird es in 2, 3, 4 Jahren rutschen?
• Wenn wir dies tun, ist es meiner Meinung nach der richtige Zeitpunkt, um einen klaren Bruch zu machen und die Architektur neu zu gestalten.
  
  
  
  • Ich wünschte mir, wir hätten halbwegs gute Unit-Tests, obwohl wir viele Probleme haben, die sie nie lösen würden, aber wir haben auch einige, die sie haben würden.
  
  
  • Können wir endlich Android-Unterstützung hinzufügen?
  
  
  • Wir müssen nicht von Grund auf neu schreiben, aber es kann angebracht sein, sorgfältig zu prüfen, welchen Code wir behalten und welchen wir löschen.
  
  
• Ich würde wirklich gerne eine viel stärkere Beziehung zwischen Greasemonkey und Mozilla haben, bevor wir eine so große Aufgabe beginnen. Ich habe nur schwache Vermutungen, wie man das in die Realität umsetzen kann.
  
  
  
  • Ich denke, wir sind heute effektiv ein Foltertest für die Portierung auf so etwas wie Weberweiterungen; Im Laufe der Jahre haben wir einige erweiterte Funktionen entwickelt. Eine Zwei-Wege-Kommunikation als Teil des Plans wird wahrscheinlich viel helfen.
  
  

Es wäre eine großartige Idee, mit einem Design-Dokument zu beginnen. Im Wesentlichen müssen wir den gesamten Greasemonkey, wie er existiert, in einen Plan für einen guten Weg zurückentwickeln, anstatt in einen ungeplanten organisch gewachsenen Weg, damit alles strukturiert werden kann.

zB Services.ppmm und .cpmm sind nette Abkürzungen, auf die man sich gerne von Anfang an verlassen könnte, aber sie existierten noch nicht, als wir (verantwortlich) anfingen.

Ich befürworte sicherlich noch nicht die Verwendung von WebExtensions, sie sind viel zu unreif für so etwas wie GM

Wir müssen nicht von Grund auf neu schreiben, aber es kann angebracht sein, sorgfältig zu prüfen, welchen Code wir behalten und welchen wir löschen.

Hm, nun, ich habe es hauptsächlich von einem Technologie-POV aus betrachtet. Im Moment verwendet die Benutzeroberfläche XUL-Overlays und die direkte Skriptausführung in der gemeinsam genutzten Chrome-Umgebung.

Dinge in HTML umzuwandeln und alle Dinge in einem unabhängigen Fensterkontext laufen zu lassen und nur über Message-Passing zu kommunizieren, scheint die Art zu sein, wie die Dinge in Zukunft gemacht werden sollen.

Der Nachrichtenmanager ist im Grunde die unterste Ebene, auf der dies implementiert ist. Darauf bauen höhere Abstraktionen auf. WebChannel.jsm/BroadcastChannel/MessageChannel/WebExtension-Kanäle und dergleichen.

Es wäre eine großartige Idee, mit einem Design-Dokument zu beginnen.

Wäre das GH-Wiki dafür der richtige Ort? Gibt es Benachrichtigungen beim Bearbeiten, um die Zusammenarbeit zu vereinfachen?

Ich denke, wir brauchen meistens eine Feature- / interne Installationsliste und wie man sie sauber implementiert.

Wenn Sie sich für das Thema dieser Ausgabe interessieren, lesen Sie bitte:

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

Vielen Dank!

Relevant:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

Dies ist eine superinteressante API, aber "Diese Funktion ist nicht standardmäßig und befindet sich nicht auf einem Standardpfad" und die Kompatibilität ist sehr begrenzt.

Alle meine jüngsten Versuche (siehe #2483, #2484), voll funktionsfähige Greasemonkey-under-WebExtensions zu entwerfen, waren frustrierend. Ich beginne über einen progressiveren Entwicklungsstil nachzudenken: Wählen Sie eine begrenztere Anzahl von Funktionen aus und unterstützen Sie nur diese. Seien Sie ein wenig nützlich und finden Sie später hoffentlich einen Weg zu mehr Funktionalität.

Bei der Überprüfung meiner 3.x-Installation sehe ich, dass (für mich) jedes einzelne Skript <strong i="6">@grant</strong> none . Von 27 verwenden nur sechs @run-at document-start , und die meisten davon würden zumindest einigermaßen anmutig funktionieren, wenn dies nicht unterstützt würde. Das Feature @require wird stark genutzt und @resource ziemlich oft.

Das scheint also ein anständiges Ziel zu sein, das man zuerst anstreben sollte: Unterstützung einfacher Benutzerskripte im <strong i="12">@grant</strong> none Modus, keine Unterstützung für GM_ APIs. Unterstützen Sie @require . Ich hoffe, @resource irgendwie zu unterstützen, vielleicht ineffizient.

(Randbemerkung, weil ich es immer wieder vergessen: Plan verwenden sourceURL Fehler leicht lesbarer machen in Schauen Sie, ob mehrere sourceURLs unterstützt werden, oder ob wir müssten (wir können) erzeugen ein sourceMap, Factoring.? @require berücksichtigt.)

Wir erhalten zusätzlich zu den WebExtension-APIs Zugriff auf einfache Web-APIs, also:

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? Was ist das Speicherlimit von IndexedDB für eine WebExtension? Dies sieht nach einer viel besseren Option aus als storage.local . Die Schnittstelle ist nicht die einfachste, aber sie gibt uns mehr Möglichkeiten, Skripte voneinander zu trennen und selektive Lesevorgänge durchzuführen. Ich denke. Docs sind auch nicht die einfachsten zu verwenden.

https://github.com/mdn/webextensions-examples/pull/171 scheint eine wertvolle Diskussion und ein Beispiel für IndexedDB zu haben

Ich habe einige Fortschritte gemacht.

https://github.com/arantius/greasemonkey/tree/webbymonkey (bei 88d53b4c67b7825858405eb2591f27c8487ce413 )

Von Grund auf neu implementiert. Checken Sie aus, gehen Sie zu about:debugging , klicken Sie auf "Temporäres Add-on laden" und wählen Sie eine beliebige Datei aus dem Stammverzeichnis aus. Sie können Benutzerskripte installieren und kaum ausführen. Absolut keine weiteren Funktionen. (Nun, es gibt das Affenmenü, aber es ist eine leere Fälschung, die nichts anderes tut, als OK zu sehen.) Viele TODOs sind im Code verstreut, selbst für dieses kleine Feature-Set. Ich kann nicht garantieren, dass dies der "richtige Weg" zu mehr Funktionen ist oder nicht.

Da ältere Versionen von Tampermonkey sowie Violentmonkey Open Source sind, könnte ein Teil dieses Codes hier verwendet werden, da WebExtensions Chromium Extensions ähnelt?
EDIT: Eigentlich bin ich mir bei der Lizenzkompatibilität mit dem alten Tampermonkey nicht sicher. Aber Violentmonkey ist MIT-lizenziert, also kompatibel.

@PorygonZRocks : Aus Violentmonkey wird Greasemonkey?

Ich bin nicht sehr erfahren mit Codieren, aber ich dachte, es könnte zumindest einige Richtlinien zur Implementierung von Dingen enthalten. Auch hier nicht sehr erfahren / sachkundig, also kann ich mich irren.

Es ist erwähnenswert, dass FF56 alle nicht mit mehreren Prozessen kompatiblen Add-Ons deaktiviert hat, sodass sich die Frist möglicherweise ändern muss.

Siehe meinen Dev-Zweig . Was ziemlich rau ist, aber minimal funktional ist. Dies wird getan, es gibt nichts, was speziell in dieser breit angelegten Ausgabe zu verfolgen ist.

@arantius Schreiben Sie aus Neugier neuen Code oder verwenden Sie den alten wieder?

Brauchst du Hilfe?

Nochmals aus Neugier, zum Beispiel, besteht der Zweck von "parse-meta-line.js" lediglich darin, die Metadaten in ein Objekt zu parsen?

@arantius Schreiben Sie aus Neugier neuen Code oder verwenden Sie den alten wieder?

Meist neu. Kopieren wann/wo es hilfreich ist. (Bisher ist das Skript-Parsing ein gutes Beispiel.)

Brauchst du Hilfe?

Hilfe wäre nett. Die Koordination wäre schwierig.

Nochmals aus Neugier, zum Beispiel, besteht der Zweck von "parse-meta-line.js" lediglich darin, die Metadaten in ein Objekt zu parsen?

Eine Zeile davon, ja.

Eine Zeile davon, ja.
Ich meinte, macht es etwas anderes, als die Metadaten zwischen diesen zu analysieren:

// ==UserScript==
....
// ==/UserScript==

Es scheint viel Code zu sein, wenn das das einzige Ziel ist.

Ja das tut es. Es ist generierter Code. Bitte führen Sie diese Diskussion zu https://groups.google.com/d/topic/greasemonkey-dev .

Ich verwende keine Google-Gruppen :(
Wenn ich es wäre... würde ich es wahrscheinlich anders machen.

Die Google-Gruppe existiert nicht mehr.

Schlechter Link: https://groups.google.com/forum/#!forum/greasemonkey -dev

Ich bin mir nicht ganz sicher, ob dies der richtige Ort dafür ist, aber hier ist es trotzdem. Wenn Sie möchten, dass ich eine separate Ausgabe @arantius öffne , sicher.
Soll die 4.0.0 nicht die bestehenden Skripte migrieren? Ich habe auf Alpha 3 aktualisiert (von der neuesten Nicht-Beta) und bemerkte, dass ich keine Skripte mehr hatte.

@Phyxion , wenn Sie 3.14 installieren, sollten die Skripte migriert werden. Stellen Sie sicher, dass Sie den Browser nach der Installation neu starten.

Danach sollten Sie bei der Installation von 4.x die Skripte haben. Wenn Sie dies nicht tun, wären einige detaillierte Reproduktionsschritte in einer neuen Ausgabe hilfreich.

Greasemonkey 4 alpha ist nicht mit Firefox 57 kompatibel.

@erkinalp , näher erläutern? Ich habe 4alpha2 für viele meiner Tests und Modifikationen verwendet, es funktioniert, obwohl nicht alle Funktionen in 3.x verfügbar sind. Ich habe die Änderungen in 4alpha3 nicht übernommen, daher weiß ich nicht, dass die wenigen Commits für diese Version etwas kaputt machen.

@Sxderp Nun, die Reproduktion auf meinem Computer ist einfach. Ich habe 3.14 mit 10 Benutzerskripten installiert. Gehen Sie zu AMO und laden Sie die neueste Alpha herunter. Neustart bei Aufforderung. Dann heißt es nur, dass keine Userscripts installiert sind. Ich bin mir nicht sicher, wie nützlich dies für die Reproduktion ist.

Ich habe dies noch nicht getestet, aber ich glaube, GM4 sollte seine Konfiguration nach einer Deinstallation verlieren , während GM3 sie behalten sollte, also würde ich vorschlagen, dass Sie es versuchen:

1. Deinstallieren Sie Greasemonkey vollständig
2. Firefox neu starten
3. Installieren Sie Greasemonkey 3.14 (einschließlich Neustart)
4. Starten Sie Firefox zur Sicherheit neu
5. Installieren Sie Greasemonkey 4 (Punkte alles)

Hilft das?

Ich denke, die oberste Ebene zu erwarten - dh alles in eine asynchrone Funktion zu packen - ist keine gute Designwahl, da sie zukünftige Implementierungen einschränkt (zB wenn / wenn wir Sandboxen zurückbekommen oder es-zukünftige Realms). Es macht die Dinge inkonsistent mit der Vanilla-JS-Ausführung, bei der das Warten auf oberster Ebene nicht verfügbar ist und Skripte ... nun ja ... auf oberster Ebene ausgeführt werden.

@arantius
Hier ist immer noch nichts :(
Übrigens, 4.0 soll so aussehen: https://i.imgur.com/CPuWWKM.png
Es gibt keine Schaltflächen oder ähnliches, um ein Skript hinzuzufügen.

... alles in eine asynchrone Funktion packen ...

Mit dem, was jetzt verfügbar ist, "muss" ich eine Funktion für Scope-Zwecke einschließen. Ich denke, ich kaufe Ihre Argumentation dafür, dass Sie es nicht asynchron machen. (Zumindest ist das Hinzufügen einer asynchronen Wrapper-Funktion im Skript selbst trivial.)

Ja, es ging hauptsächlich um async/await, da dies derzeit in Javascript absichtlich nicht zulässig ist , sodass die Aktivierung in Benutzerskripten eine Gefahr für zukünftige Änderungen darstellt. Ich weiß, dass der Wrapper derzeit unvermeidlich ist, aber ich hoffe, dass die Dinge in Zukunft wieder auf die oberste Ebene verschoben werden können.

@arantius Warum die

@arantius hat 2017 kommentiert 28. 14:57 MESZ :

... alles in eine asynchrone Funktion packen ...

Mit dem, was jetzt verfügbar ist, "muss" ich eine Funktion für Scope-Zwecke einschließen. Ich denke, ich kaufe Ihre Argumentation dafür, dass Sie es nicht asynchron machen. (Zumindest ist das Hinzufügen einer asynchronen Wrapper-Funktion im Skript selbst trivial.)

Versuchen Sie, den Inhalt von [Mozilla-Profil]\storage\default\ zu löschen (nachdem Sie es gesichert haben)
Dann versuchen Sie es erneut.

Apropos UserScript-Objekte, ich verstehe die Designentscheidung für drei UserScript-Klassen nicht ganz. Im Moment haben sie einen einzigartigen Vererbungsbaum, der ein wenig albern ist.

Außerdem wird RemoteUserScript nur einmal verwendet und dafür nur erstellt, um die id zu erfassen. Und RunnableUserScript wird nie direkt verwendet.

Nur zur Info ...

Ich verwende FF57.0a1 und verwende ältere Addons und GM 3.13
Leider bekomme ich die Updates (3.14, 3.15) nicht, da ihre maximale Version auf 56 gesetzt ist.*

Es kann aber manuell installiert werden..

GM 3.16 hängt immer noch den Browser beim Start (ich vermute, es aktualisiert die DB)