Greasemonkey: Sicherung/Wiederherstellung hinzufügen

Nun, Firefox und seine Probleme. Also habe ich dies implementiert (und natürlich eine 'Import'-Funktion). Ich bin fast fertig damit, aber es gibt einen Show-Stopper. Es funktioniert nur, wenn Sie browser toolbox öffnen und "Popups nicht automatisch schließen" auswählen. Der Import erfolgt über ein <input type="file"> (das ist der einzige Weg), jedoch wird beim Fokussieren des Browse-Fensters normalerweise das Popup geschlossen, somit wird das Fenster zerstört und es werden keine Funktionen ausgeführt. Relevante Fehler:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

Es ist so ärgerlich, eine halbherzige Umgebung zum Arbeiten zu haben.

Gilt auch für #2612. Die gleichzeitig angesprochen werden kann dieses Thema ist.

@Sxderp Wenn das Schließen des Umgehung darin, einfach eine Registerkarte oder ein Fenster zu öffnen (das auf eine HTML-Seite innerhalb der Erweiterung zeigt), in der Sie alles ausführen, was Sie tun müssen. Solche Registerkarten/Fenster werden nicht automatisch geschlossen und zeigen dieselbe Umgebung wie ein Popup. Das mag zwar nicht so sauber sein, wie alles im Browser-Popup zu haben, aber es sollte funktionieren.

Das könnte ich machen. Es würde bedeuten, eine Menge Code zu verschieben. Ich schaue mir das ein anderes Mal an.

Ich habe den Import/Export-Zeug abgeschlossen. Keine Tests und sehr wenig Fehlerbehandlung. Aber es funktioniert. Der Einfachheit halber habe ich es jedoch so gemacht, dass ein Import die gesamte Datenbank überschreibt. Natürlich mit Bestätigungsaufforderung.

Ich denke, im Idealfall könnte der Benutzer den Import ersetzen oder zusammenführen. Stylus führt nur zusammen, was auch ein schlechter IME ist. Die Benutzerauswahl mit Standardeinstellungen, die möglicherweise funktionieren, scheint am besten zu sein.

Sicher, aber dann stoßen wir auf viele Bedingungen. Ich hätte gerne eine Art Flussdiagramm zur _exakten_ Natur des Zusammenführens.

Vor allem in Bezug auf Konflikte. Inhalt überschreiben, Schlüssel/Werte überschreiben (ja, diese werden auch exportiert), für alles auffordern (das scheint eine schlechte Benutzererfahrung zu sein) usw.?

Ich meine nur: Importieren Sie jedes Skript in der Datei (und überschreiben Sie diesen Zustand vollständig), aber berühren/löschen Sie keine Skripte, die nicht in der Datei enthalten sind.

Oh. Das ist viel einfacher. Ja, das hört sich gut an.

Also habe ich drei verschiedene Importmethoden implementiert.

1. Verschmelzen. Berühren Sie keine installierten Skripte. Nur Skripte, die derzeit nicht existieren[1] werden der Datenbank hinzugefügt.
2. Ersetzen. Deinstallieren Sie alle aktuellen Skripte und ersetzen Sie sie durch die importierten.
3. Überschreiben. Wie Merge, aber wenn ein Konflikt[1] gefunden wird, haben die importierten Skripte Vorrang.

Warten auf andere PRs, bevor Sie einreichen.

[1] Ich bestimme die Eindeutigkeit durch id eines Skripts.

Was ist damit?

1. Aktualisieren. Nur bereits vorhandene Skripte importieren (überschreiben).

Dies ist komplementär zu 1. Zusammenführen

1. Überschreiben. Wie Merge, aber wenn ein Konflikt[1] gefunden wird, haben die importierten Skripte Vorrang.

@Sxderp Ich denke, "Wie Zusammenführen" enthält nicht die Einschränkung "Nur Skripte, die derzeit nicht existieren" ...
(diese Einschränkung macht hier keinen Sinn) Das heißt, Überschreiben = Alle Skripte importieren, widersprüchliche Skripte werden vom Archiv überschrieben...

Welche dieser Optionen (Aktualisieren/Zusammenführen/usw.) bietet VM, TM oder anderweitig?

1. Aktualisieren. Nur bereits vorhandene Skripte importieren (überschreiben).

Klar, das sollte machbar sein.

Das heißt, Überschreiben = Alle Skripte importieren, widersprüchliche Skripte werden vom Archiv überschrieben...

Richtig.

Welche dieser Optionen (Aktualisieren/Zusammenführen/usw.) bietet VM, TM oder anderweitig?

Nicht wirklich sicher. Aber dies brachte mir eine andere Sorge auf. Kompatibilität mit Archiven. Angenommen, diese Addons unterstützen den vollständigen Datenbankexport (Skripte + Daten), dann sollten die Importe idealerweise miteinander kompatibel sein.

Aktualisieren. Nur bereits vorhandene Skripte importieren (überschreiben).

Jetzt, wo ich darüber nachdenke (alle etwa 3 Minuten), habe ich ein Anliegen. Was ist mit den zugehörigen Daten (get/setValue)? Sollen die aktuell gespeicherten Daten erhalten bleiben? Sollen die importierten Daten Vorrang haben? Eine Art Fusion? Und dann diese Option / diesen Zustand dem Benutzer klar darstellen. Das ist tatsächlich etwas kniffliger als auf den ersten Blick.

Habe ein paar schnelle Checks gemacht, dies ist nicht 100% gründlich, aber gibt einen allgemeinen Überblick, sowie was ich in Bezug auf meine Implementierung wahrscheinlich ändern sollte.

VM und TM exportieren beide in ZIP-Dateien. In den Zip-Dateien finden Sie .user.js Dateien für jedes Ihrer Skripte. Was das Exportieren von speicher-/implementierungsspezifischen Details betrifft, tun sie es jedoch beide etwas anders. Die VM verpackt implementierungsspezifische Details und Skriptdaten für alle Skripts in einer einzigen Datei, violentmonkey . TM macht das etwas vernünftiger. Implementierungsspezifische Details für jedes Skript werden in .options.js Dateien exportiert, während Skriptdaten in .storage.json exportiert werden.

Ich denke, ich werde meine Implementierung überarbeiten, um TM zu folgen. Im Allgemeinen denke ich, dass es ein besserer Standard ist, da es Implementierungsdetails von den Daten trennt.

Was die "Importmethode" angeht (in meinem Beitrag oben beschrieben):

TM bietet eine 'jedes Skript auswählen'-Schnittstelle. Beim Importieren eines Archivs wählen Sie aus, ob Sie jedes einzelne Skript importieren möchten. Wenn Sie es aktivieren, werden alle Daten für dieses Skript überschrieben.

VM scheint nur das anzubieten, was ich oben als "Überschreiben" beschrieben habe. Es besteht jedoch die Möglichkeit, zugehörige Skriptdaten NICHT zu importieren (global für alle Skripte). Aus Sicht der Benutzeroberfläche denke ich, dass es schwierig wäre, diese Option in GM zu implementieren. Wenn wir jedoch den TM-Ansatz zum Exportieren / Importieren der Datenbank verwenden, könnte ein Benutzer einfach das Archiv öffnen und die .storage.json Datei entfernen.

Wenn jemand testen möchte, habe ich meinen Branch sxderp:import-export-database-merge aktualisiert, um die zuvor besprochene .zip Funktionalität aufzunehmen. Ich habe die Option update , die @Eselce vorgeschlagen hat, nicht implementiert, weil ich mir update Einzelheiten noch nicht sicher bin.

@Sxderp Vielen Dank für die Entwicklung dieser Funktion. Ich habe das Paket erstellt und in der Firefox Developer Edition installiert (um die Installation nicht signierter Erweiterungen zu ermöglichen). Ich habe ein bestehendes Profil mit dieser Browserversion aktualisiert, die vorhandene GreaseMonkey-Installation überschrieben und meine Datenbank problemlos exportiert.

Das Importieren in ein neues Firefox-Profil mit diesem installierten GreaseMonkey verursachte jedoch ein Problem. Es scheint, dass ein bestimmtes Benutzerskript, das ziemlich groß ist (sowohl user.js als auch gm_details.js sind etwa 230K groß), Importprobleme verursacht. Nach dem Ersetzen der Datenbank funktioniert GM nicht mehr. Ein Klick auf das GM-Symbol öffnet ein leeres Dropdown-Menü (ca. 10x10 Quadrat).

Ich würde das spezifische Userscript lieber nicht öffentlich teilen. Mit diesem Trick habe ich Ihre E-Mail-Adresse gefunden und schicke Ihnen so eine Nachricht.

Bearbeiten: Die einzige Möglichkeit, GM nach einer Unterbrechung zum Laufen zu bringen, besteht darin, die Erweiterung zu entfernen, Firefox neu zu starten und erneut hinzuzufügen.

GMexport_20180 2 17_164139.zip ???

Ein ganzes Bündel (teilweise) große Skripte (> 20) aus einer 3,4 MB ZIP-Datei ohne Beanstandung importiert. Aber keine genaue Untersuchung...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth() beginnt bei 0... ; fehlt...

IIRC, getMonth() beginnt bei 0... ; fehlen...

RUHE IN FRIEDEN

Ich habe schon lange nicht mehr an diesem Zweig gearbeitet. Ich werde heute auf Master rebasieren und eine Menge Aufräumarbeiten durchführen.

Ich habe meinen Branch auf Master umbasiert und einige bedeutende Änderungen am Layout vorgenommen, die meiner Meinung nach eine bessere Lesbarkeit bieten.
@ArmEagle In meinem aktualisierten Branch konnte ich die von Ihnen gesendete Datei importieren. Wenn Sie immer noch Probleme haben, lassen Sie es mich wissen und ich werde mich weiter darum kümmern.

Zusammengeführt mit Änderungen in 7fe8bfe94efbadeb1da1a6491aaf424fc8275f09 . Wiedereröffnung, um einige Probleme zu verfolgen/zu diskutieren, die ich gesehen habe.

Wiedereröffnung, um einige Probleme zu verfolgen/zu diskutieren, die ich gesehen habe.

Was waren die Probleme?

War ein einmaliger Schnelltest, ich bin mir nicht sicher, ein Teil des Skripts, von dem ich erwartet hatte, dass es installiert wird, war nicht aufgeführt. Aber ich möchte es wiederholen und sorgfältig verfolgen und die Ergebnisse aufschreiben. Es gibt viele mögliche Fälle.

Ich habe mir das endlich mal ein bisschen angeschaut.

Es sichert nur .user.js und die "Details". Was versehentlich den erforderlichen Inhalt einschließt, aber die Ressourcen übersieht (JSON-Serialisierung des Blobs auf {} ). AFAICT es wird .setKnownResources() mit leeren/gebrochenen Blobs und funktioniert daher nicht.

Es wäre besser, wenn jedes Skript seinen eigenen Ordner hat, dieser Ordner enthält eine Datei für die Hauptdateien .user.js , für jede @require und @resource und dann vielleicht die restlichen geparsten/ benutzerdefinierte Details und gespeicherte Werte. Ich denke, das könnte sogar besser genug sein, dass ich auf jegliche plattformübergreifende Kompatibilität verzichten würde.

Total einverstanden. Genauso wie das Speichern eines Dokuments "als Webseite", das ein htm -Dokument plus einen Ordner gleichen (Basis-)Namens mit den Abhängigkeiten erstellen würde...

Was zufällig den erforderlichen Inhalt enthält ...

War nicht zufällig. Beinhaltet es absichtlich für alle lokalen Änderungen, die möglicherweise aufgetreten sind. Ich würde die Ressourcen / Anforderungen als "Implementierungsdetails" betrachten und daher als "Details" exportieren. TM exportiert nicht einmal Ressourcen / erfordert.

aber vermisst die Ressourcen (JSON serialisiert das Blob auf {}). AFAICT es wird .setKnownResources() mit leeren/gebrochenen Blobs und daher nicht funktionieren.

Es gibt eine TODO, um herauszufinden, ob sich Blobs gut aufziehen. Diese Funktion wurde technisch zusammengeführt, bevor ich eine PR dafür eingereicht habe.

Für die Zeit würde das Blob-Problem mit #2937 gelöst werden.

Was das Erstellen weiterer Dateien im Backup-Archiv betrifft, glaube ich nicht, dass dies alle Vorteile bringen würde. Während das Archivieren von Ressourcen und Anforderungen und was auch immer in separaten Dateien abgelegt wird, beim Extrahieren _schön_ aussehen_ mag, würde dies den Code wahrscheinlich komplexer machen, da Sie mit vielen kleinen Dingen und nicht mit einem einfachen Dump zu tun haben.

Dies ist das "große Feature" für 4.4, also hoffe ich wirklich, dass ich es bald fertigstellen/verbessern kann.

Zweiter Gedanke, das ist funktional. Es gibt einige Verbesserungen, die ich gerne verfolgen würde, aber jedes Problem für diese gezielten Änderungen wird einfacher zu handhaben sein.