Greasemonkey: la configuration de privacy.firstparty.isolate rompt le stockage des scripts

J'ai donc vu ceci et vérifié ma version maintenant : 67. Mais il y avait une mise à jour à appliquer, alors je l'ai fait. Maintenant, je suis sur 68 et tous mes scripts sont en place très bien.

Les scripts sont stockés dans IndexedDB. Il n'y a pas de réponse simple à cela, il y a des identifiants aléatoires impliqués (hors de notre contrôle).

OK, il semble que ce ne soit pas un problème général.

La seule chose que j'ai changée après la mise à niveau a été de mettre à jour les paramètres > sécurité > personnalisé > bloquer les trackers d'identification (je ne connais pas la traduction exacte en anglais). Mais le changer n'a pas ramené mes scripts :/

Recherche l'emplacement IndexedDB (je connais l'ID d'environ: support, mais pas le répertoire) et certaines de mes sauvegardes.

"profile > storage > default > about+newtab^firstPartyDomain=about.MYGMID > idb > 3312185054sbndi_pspte.sqlite" --> fichier non modifié depuis un mois selon l'horodatage du fichier

"profile > storage > permanent > moz-safe-about+home^firstPartyDomain=about.MYGMID > idb > 818200132aebmoouht.sqlite" --> fichier non modifié depuis un mois selon l'horodatage du fichier

Mais aucun de ces fichiers ne contient plus mes scripts.

Cela vient de m'arriver aussi. Firefox 68.0 sur macOS. Problème confirmé avec différents profils.

Cela vient de m'arriver aussi. Firefox 68.0 sur macOS. Problème confirmé avec différents profils.

J'ai découvert que le simple fait de copier un ancien profil dans FF 68 ne restaurera pas vos scripts. J'ai dû télécharger FF 67 Portable, y copier mon ancienne sauvegarde de profil et exporter les scripts hors de FF 67 (je n'ai pas essayé de réimporter dans FF68). Il semble donc que FF stocke les scripts quelque part dans le dossier de profil, mais FF68 ne peut pas le lire ou ne migre pas correctement depuis FF67.

Mise à jour : GM enregistre les scripts dans "profile\storage\default\moz-extension+++MYGMID\idb\XXX.sqlite". Il s'agit d'un ID différent de celui indiqué dans about:support. Il semble que tous les scripts soient toujours là, maintenant il serait intéressant de savoir pourquoi FF68 ne peut plus les lire pour certaines configurations ;)

Mise à jour 2 : Je peux également reproduire régulièrement avec mon profil de sauvegarde. Malheureusement, je ne peux pas partager ce profil et je n'ai pas pu reproduire avec une installation portable FF propre.

@daleeidd Avez-vous une description plus détaillée ou un profil "vide" que vous pouvez partager pour que cela soit également reproductible pour arantius ?

Je pense qu'on devrait enquêter. C'est le pire des cas et cela ne devrait pas arriver, même si ce n'est que pour 1% des utilisateurs.

Cela ressemble à l'identifiant du module complémentaire peut avoir changé entre les mises à jour.

Vérifié que dans about:debugging : affiche toujours le même ID d'addon et UUID interne.

OK, j'ai trouvé.

Le problème est le paramètre "privacy.firstparty.isolate;true". Habituellement, GM stocke ses paramètres dans ces 2 dossiers :

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

Si l'isolation 1ère partie est activée et que vous mettez à niveau vers FF 68, un 3ème dossier est créé :

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

Si vous désactivez l'isolement de la 1ère partie ("privacy.firstparty.isolate;false") puis supprimez le 3ème dossier créé mentionné ci-dessus, vos scripts redeviendront visibles.

@kekkc Merci. Suivez simplement vos instructions pour récupérer les scripts à exporter. Bon travail!

Excellent diagnostic. Je ne sais pas quoi faire à ce sujet depuis Greasemonkey, cependant?

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

D'une manière ou d'une autre, j'avais l'espoir qu'il existe une solution de contournement possible dans GM. Toutes mes autres extensions qui utilisent le même stockage (par exemple https://addons.mozilla.org/de/firefox/addon/textnotes/?src=search ) n'ont pas amené FF à créer un nouveau dossier lors de la mise à niveau, même avec le 1er l'isolement du parti est activé.

Cette extension n'utilise pas IndexedDB.

Peut confirmer que la désactivation de l'isolement de première partie (je l'avais activé via ce module complémentaire , une simple bascule) et le redémarrage de FF ont provoqué la réapparition de mes scripts. Je n'ai pas eu besoin de supprimer de dossier.

Une fois que j'ai exporté les scripts en toute sécurité, la réactivation de l'isolation de première partie, puis la réimportation des scripts ont résolu le problème, de sorte que FPI ne semble pas casser Greasemonkey de manière persistante ou permanente. Il convient peut-être de noter que (si je me souviens bien), c'est la même chose qui arrive à toutes les données de navigation (sans extension) lorsqu'un utilisateur active initialement l'isolation de première partie, il est donc possible que FF68 ait juste étendu le comportement FPI normal à appliquer également aux extensions.

En fouinant un peu, ce bogue mentionne une rupture de module complémentaire avec FPI en aparté - impossible de trouver un autre bogue confirmé spécifiquement pour ce problème en un coup d'œil.

Merci, j'ai mentionné le bogue sur bugzilla. Peut-être que https://bugzilla.mozilla.org/show_bug.cgi?id=1564593 devrait également faire référence au FPI (FPI a été introduit dans le cadre de TorBrowser Uplift et était aussi important pour Mozilla que l'API UserScript)

Juste une note que nous (Mozilla) avons vu cela. Je pense que le bogue Bugzilla le plus pertinent 1554805.

Malheureusement, personne ne travaille activement sur ce problème pour le moment, mais nous pouvons peut-être trouver des cycles pour résoudre ce problème. Malheureusement, le "correctif" est susceptible de tout supprimer à nouveau ; mais au moins activer/désactiver FPI ne désactivera pas le stockage pour l'extension...

Ce n'est pas l'endroit pour me plaindre car je n'ai pas installé GM, mais la même chose m'est arrivée et rien ne fonctionne. J'avais FPI installé, mais désactivé. Lors de la mise à niveau vers FF 68, onetab et stylus ont perdu des données.

J'ai continué à ce sujet ici : https://github.com/openstyles/stylus/issues/747

@kekkc quelle solution FF 67 Portable avez-vous utilisée ? J'ai essayé les applications portables FF et FF ESR, toutes deux disent que je ne dois pas utiliser un ancien profil FF... et je n'ai aucune idée de la façon de remplacer cette boîte de dialogue. D'une manière ou d'une autre, la mise à jour vers FF 68 a fait quelque chose à mon profil et FF 66.0.4 et les versions antérieures n'arrêtent pas de dire d'utiliser un nouveau profil.

@b16r05 était en vacances, vous l'avez probablement déjà compris. Je viens de copier le dossier de profil et je n'ai pas démarré FF 67 Portable auparavant. Je me souviens du même message d'erreur, mais je pense que cette méthode a fonctionné à la fin.

Je ne peux PAS confirmer ce comportement. Je l'ai (FF68) désactivé.
Je ne peux ni voir mes scripts, ni en créer de nouveaux ni installer quoi que ce soit.
Cela ne fait rien.

Lorsque j'installe de nouveaux scripts, il est indiqué "indéfini" dans la boîte de dialogue finale.
Lorsque je clique sur "ajouter un nouveau script", cela met les messages d'erreur suivants dans la console :

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

J'ai essayé de le désinstaller, de supprimer les dossiers storage\default\moz* , de renommer le dossier gm_scripts , de le réinstaller : ça ne marche toujours pas.

Il semble que cela ait été corrigé dans FF71 https://bugzilla.mozilla.org/show_bug.cgi?id=1554805

Lors de la mise à niveau de FF70 vers FF71, j'ai perdu tous mes scripts et styles de stylet pour la deuxième fois en 2019. privacy.firstparty.isolate est activé. Mais cette fois, j'ai fait une sauvegarde de mon profil avant de mettre à jour.

Je pourrais rétrograder temporairement mon installation à 70, décompresser ma sauvegarde et exporter les scripts et les styles, que j'ai refaits depuis l'autre perte de données précédente.

Cela m'apprend à garder une copie externe de tout mon travail. Ensuite, je peux les enregistrer dans un contrôle de version et travailler dessus dans un éditeur approprié. Pouvez-vous recommander un moyen simple de déployer automatiquement mes fichiers modifiés en externe dans GM + Firefox autre que le copier-coller ?