Greasemonkey: Das Setzen von privacy.firstparty.isolate unterbricht die Skriptspeicherung

Also habe ich das gesehen und meine Version jetzt überprüft: 67. Aber es musste ein Update angewendet werden, also habe ich es getan. Jetzt bin ich auf 68 und alle meine Skripte sind in Ordnung.

Skripte werden in IndexedDB gespeichert. Darauf gibt es keine einfache Antwort, es sind zufällige IDs beteiligt (außerhalb unserer Kontrolle).

OK, also scheint es kein allgemeines Problem zu sein.

Das einzige, was ich nach dem Upgrade geändert habe, war, Einstellungen > Sicherheit > Benutzerdefiniert > Identifikations-Tracker zu blockieren (ich kenne die genaue englische Übersetzung nicht). Aber das Zurücksetzen brachte meine Skripte nicht zurück :/

Wird nach dem IndexedDB-Speicherort suchen (ich kenne die ID von about:support, aber nicht das Verzeichnis) und einige meiner Backups.

"profile > storage > default > about+newtab^firstPartyDomain=about.MYGMID > idb > 3312185054sbndi_pspte.sqlite" --> Datei seit einem Monat nicht geändert gemäß Dateizeitstempel

"profile > storage > permanent > moz-safe-about+home^firstPartyDomain=about.MYGMID > idb > 818200132aebmoouht.sqlite" --> Datei seit einem Monat laut Zeitstempel der Datei nicht geändert

Aber auch keine dieser Dateien enthält mehr meine Skripte.

Das ist mir auch gerade passiert. Firefox 68.0 auf macOS. Bestätigtes Problem mit unterschiedlichen Profilen.

Das ist mir auch gerade passiert. Firefox 68.0 auf macOS. Bestätigtes Problem mit unterschiedlichen Profilen.

Habe herausgefunden, dass das einfache Kopieren eines alten Profils auf FF 68 Ihre Skripte nicht wiederherstellt. Ich musste FF 67 Portable herunterladen, meine alte Profilsicherung dorthin kopieren und die Skripte aus FF 67 exportieren (habe nicht versucht, nach FF68 neu zu importieren). Es scheint also, dass FF die Skripte irgendwo im Profilordner speichert, aber FF68 kann dies nicht lesen oder wird nicht korrekt von FF67 migriert.

Update: GM speichert die Skripte in „profile\storage\default\moz-extension+++MYGMID\idb\XXX.sqlite“. Dies ist eine andere ID als in about:support angezeigt. Scheinbar sind alle Skripte noch da, jetzt wäre es nur interessant, warum FF68 sie bei manchen Konfigurationen nicht mehr lesen kann ;)

Update 2: Ich kann auch mit meinem Backup-Profil regelmäßig reproduzieren. Leider kann ich dieses Profil nicht freigeben und ich konnte es nicht mit einer sauberen tragbaren FF-Installation reproduzieren.

@daleeidd Haben Sie eine detailliertere Beschreibung oder ein "leeres" Profil, das Sie teilen können, um dies auch für arantius reproduzierbar zu machen?

Ich denke, wir sollten das untersuchen. Dies ist der schlimmste Fall und sollte nicht passieren, auch wenn es nur für 1 % der Benutzer gilt.

Das hört sich so an, als hätte sich die Add-on-ID zwischen den Updates geändert.

Überprüft, ob in about:debugging : immer noch dieselbe Addon-ID und interne UUID angezeigt werden.

Okay, ich habe es gefunden.

Das Problem ist die Einstellung "privacy.firstparty.isolate;true". Normalerweise speichert GM seine Einstellungen in diesen 2 Ordnern:

• profile\storage\default\moz-extension+++MYGMID
• profile\storage\default\moz-extension+++MYGMID^userContextId=MYCONTID

Wenn die 1st-Party-Isolation aktiviert ist und Sie auf FF 68 aktualisieren, wird ein 3rd-Ordner erstellt:

• profile\storage\default\moz-extension+++MYGMID^firstPartyDomain=MYGMID

Wenn Sie die 1st-Party-Isolierung ("privacy.firstparty.isolate;false") deaktivieren und dann den oben erwähnten 3rd-erstellten Ordner löschen, werden Ihre Skripte wieder sichtbar.

@kekkc Danke. Befolgen Sie einfach Ihre Anweisungen, um die Skripts für den Export wiederherzustellen. Gut gemacht!

Tolle Diagnostik. Ich bin mir jedoch nicht sicher, was ich in Greasemonkey dagegen tun soll?

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

Irgendwie hatte die Hoffnung, dass da ein Workaround in GM möglich ist. Alle meine anderen Erweiterungen, die denselben Speicher verwenden (z. B. https://addons.mozilla.org/de/firefox/addon/textnotes/?src=search ), haben FF nicht dazu veranlasst, während des Upgrades einen neuen Ordner zu erstellen, auch nicht mit 1st Party-Isolation eingeschaltet.

Diese Erweiterung verwendet IndexedDB nicht.

Kann bestätigen, dass das Deaktivieren der First-Party-Isolation (ich hatte sie über dieses Add-on aktiviert, ein einfaches Umschalten) und das Neustarten von FF dazu geführt hat, dass meine Skripts wieder angezeigt wurden. Ich musste keine Ordner löschen.

Nachdem ich die Skripte sicher exportiert hatte, löste das erneute Aktivieren der First-Party-Isolation und das erneute Importieren der Skripte das Problem, sodass FPI Greasemonkey nicht dauerhaft oder dauerhaft zu beschädigen scheint. Es ist vielleicht erwähnenswert, dass (wenn ich mich richtig erinnere) dies dasselbe ist, was mit allen (Nicht-Erweiterungs-) Browsing-Daten passiert, wenn ein Benutzer anfänglich die First-Party-Isolierung aktiviert, also ist es möglich, dass FF68 gerade das normale FPI-Verhalten erweitert hat, um es anzuwenden auch zu Erweiterungen.

Ich stochere ein wenig herum und erwähnt nebenbei Add-On-Brüche mit FPI – ich konnte auf einen Blick keinen anderen bestätigten Fehler speziell für dieses Problem finden.

Thx, erwähnte den Fehler bei Bugzilla. Vielleicht sollte https://bugzilla.mozilla.org/show_bug.cgi?id=1564593 auch auf die FPI verweisen (FPI wurde als Teil des TorBrowser Uplift eingeführt und war für Mozilla so wichtig wie die UserScript-API)

Nur eine Anmerkung, dass wir (Mozilla) dies gesehen haben. Ich denke, der relevanteste Bugzilla-Bug ist 1554805.

Leider haben wir derzeit niemanden, der aktiv daran arbeitet, aber vielleicht finden wir einige Zyklen, um dies zu beheben. Leider wird der 'Fix' wahrscheinlich alles wieder löschen; Aber zumindest das Aktivieren / Deaktivieren von FPI schaltet den Speicher für die Erweiterung nicht aus ...

Nicht der richtige Ort für mich zu jammern, da ich kein GM installiert habe, aber mir ist dasselbe passiert und nichts funktioniert. Ich hatte FPI installiert, aber deaktiviert. Beim Upgrade auf FF 68 verloren sowohl OneTab als auch Stylus Daten.

Ich habe hier weitergemacht: https://github.com/openstyles/stylus/issues/747

@kekkc welche FF 67 Portable-Lösung hast du verwendet? Ich habe Portable Apps FF und FF ESR ausprobiert, beide sagen, dass ich kein altes FF-Profil verwenden darf ... und ich habe keine Ahnung, wie ich dieses Dialogfeld überschreiben kann. Irgendwie hat das Update auf FF 68 etwas mit meinem Profil gemacht und FF 66.0.4 und älter sagen immer wieder, dass ich ein neues Profil verwenden soll.

@b16r05 war im Urlaub, du hast es wahrscheinlich schon herausgefunden. Ich habe nur den Profilordner kopiert und FF 67 Portable vorher nicht gestartet. Ich erinnere mich an dieselbe Fehlermeldung, aber ich denke, diese Methode hat am Ende funktioniert.

Ich kann dieses Verhalten NICHT bestätigen. Ich habe es (FF68) deaktiviert.
Ich kann weder meine Skripte sehen, noch neue erstellen oder etwas installieren.
Es bringt einfach nichts.

Wenn ich neue Skripte installiere, steht im letzten Dialog „undefiniert“.
Wenn ich auf "Neues Skript hinzufügen" klicke, werden die folgenden Fehlermeldungen in der Konsole angezeigt:

IndexedDB UnknownErr: ActorsParent.cpp:581
Error opening user-scripts DB! <unavailable> user-script-registry.js:57:15
undefined
Error: undefined

Ich habe versucht, es zu deinstallieren, die Ordner storage\default\moz* gm_scripts umzubenennen und ihn neu zu installieren: Es funktioniert immer noch nicht.

Scheint, dass dies in FF71 https://bugzilla.mozilla.org/show_bug.cgi?id=1554805 behoben wurde

Beim Upgrade von FF70 auf FF71 habe ich 2019 zum zweiten Mal alle meine Skripte und Stiftstile verloren. privacy.firstparty.isolate ist aktiviert. Aber dieses Mal habe ich vor dem Upgrade ein Backup meines Profils erstellt.

Ich konnte meine Installation vorübergehend auf 70 zurückrüsten , mein Backup entpacken und die Skripte und Stile exportieren, die ich seit dem anderen Datenverlust zuvor neu erstellt hatte.

Dies lehrt mich, eine externe Kopie meiner gesamten Arbeit aufzubewahren. Dann kann ich sie in eine Versionskontrolle einchecken und sie in einem geeigneten Editor bearbeiten. Können Sie eine problemlose Möglichkeit empfehlen, meine extern geänderten Dateien automatisch in GM+Firefox bereitzustellen, außer durch Kopieren und Einfügen?