Wo speichern Erweiterungen deren Einstellungen?

  • Hallo Kollegen,

    seit, ich glaube FF 66Beta, ist mir aufgefallen, dass Erweiterungen ihre Einstellungen offensichtlich nicht mehr im Ordner browser-extension-data im FF-Profil ablegen. Wenn ich diesen Ordner öffne und in weiterer Folge den Unterordner einer Erweiterung, sehe ich zwar weiterhin eine Einstellungsdatei namens storage.js, doch mit dem Zusatz "migrated". Also offensichtlich eine aus der/einer vorigen FF-Version übernommenen Einstellungsdatei. Lösche ich diese, so behält die betreffende Erweiterung nun dennoch deren Einstellungen. Das war davor nicht der Fall - die Erweiterung war auf Standard zurückgesetzt.
    Wo speichern Erweiterungen aktuell ihre Einstellungen?

    Gruß
    Manfred

    FF in aktueller Releaseversion, auf MacBook Pro 16" M1 2021 unter macOS Ventura

  • Hallo,

    im storage-Verzeichnis.

    Hintergrund: Das Storage-Backend wurde von einer JSON-Datei auf eine IndexedDB-Datenbank umgestellt. Nach Angaben von Mozilla resultiert diese Änderung in signifikanten Performance-Verbesserungen für viele Erweiterungen sowie einem reduzierten RAM-Verbrauch. Vor allem Werbeblocker sollen aufgrund ihrer Funktionsweise von dieser Änderung profitieren.

  • Vielen Dank für deine Info!
    Somit kann ich den Ordner browser-extension-data eigentlich löschen?

    So wie ich das sehe, scheint der Unterordner default der Speicherort zu sein. Weißt du ev. auch, wozu die Unterordner permanent und temporary dienen?

    Leider fällt das Identifizieren und Zuordnen der Einstellungsdateien (Im Verzeichnis storage\default) um einiges schwieriger aus als im "alten" Verzeicnis, da nirgendwo auch nur ansatzweise der Name der korrespondierenden Erweiterung zu erkennen ist. Lediglich der Dateiinhalt kann u. U. Aufschluss geben. :-|

    Gruß
    Manfred

    FF in aktueller Releaseversion, auf MacBook Pro 16" M1 2021 unter macOS Ventura


  • Leider fällt das Identifizieren und Zuordnen der Einstellungsdateien (Im Verzeichnis storage\default) um einiges schwieriger aus als im "alten" Verzeicnis, da nirgendwo auch nur ansatzweise der Name der korrespondierenden Erweiterung zu erkennen ist.


    Doch, die Ordner können weiterhin der jeweiligen Erweiterung zugeordnet werden, nur haben diese jetzt ein anderes Namensformat als bisher: Nämlich moz-extension+++Interne-UUID-der-Erweiterung. Die jeweilige Interne UUID welche Firefox für einer deiner Erweiterung vergeben hat, kannst du dabei unter about:debugging (in Adresszeile eingeben) nachsehen, damit du so die verschiedenen Ordner einer deiner Erweiterungen zuordnen kannst.

  • Ah, vielen Dank!

    Jetzt fehlt mir nur noch Info zu: "Somit kann ich den Ordner browser-extension-data eigentlich löschen?"

    Gruß
    Manfred

    FF in aktueller Releaseversion, auf MacBook Pro 16" M1 2021 unter macOS Ventura


  • Zumindest bei mir werden darin fast täglich Änderungen gespeichert :-??


    Seltsam, bei mir schon länger nicht mehr. Der Ordner mit Änderungsdatum "Heute" war der Ordner, aus dem ich heute die eingangs erwähnte Einstellungsdatei gelöscht hatte, was allerdings keine Wirkung an der Erweiterung zeigte und zu meiner Eingangsfrage führte. So sieht das bei mir unter macOS aus:

    [attachment=0]Bildschirmfoto 2019-02-20 um 15.06.58.jpg[/attachment]

  • Hallo klickman..

    sorry, ich sehe gerade du redest von der Beta Version.
    Da ist das bei mir auch anders.

    [attachment=0]Zwischenablage01.png[/attachment]

    Eben mal uBlock aktualisiert...trotzdem bleibt das Datum auf dem 4.2.

    Vorschlag von mir, benenn den Ordner doch erstmal nur um und teste ob bzw. was passiert.

    Edit:
    Danke Sören :klasse:

  • Danke @Sören und andreas, so etwas in Richtung "Release" und "Beta" dachte ich mir schon.

    Ich werde den Ordner testweise löschen. Wenn etwas nicht klappt, habe ich zur Sicherheit 3 Systemsicherungen, aus denen ich den Ordner wiederherstellen kann. ;)

    Gruß
    Manfred

    FF in aktueller Releaseversion, auf MacBook Pro 16" M1 2021 unter macOS Ventura

  • Da ihr von beta sprecht, warum wurde denn die userContextId angehängt

    Zitat

    moz-extension+++xyz123^userContextId=...

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • aha, ok, danke. Welches Thema trifft denn hier eher zu?
    a) https://bugzilla.mozilla.org/show_bug.cgi?id=1406181
    b) https://wiki.mozilla.org/Security/Conte…ject/Containers
    Für mich ist das recht abstrakt, deshalb ist meine Vorstellung auch eher ungenau, welchen Vorteil es haben könnte. (Performance oder Sicherheit?)

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • a) ist das Ticket für die Implementierung des neuen Storage-Backends, b) hat nur indirekt etwas damit zu tun. Der Mechanismus, die Datenbank auf diese Weise zu isolieren, ist durch die Contextual Identities, oder Tab-Umgebungen im deutschsprachigen Firefox, bereits vorhanden gewesen und wird für diesen Anwendungsfall mitgenutzt. Daher kommt die Bezeichnung userContextId, obwohl es hier nicht wirklich darum geht. Ansonsten hätte man eine weitere Dimension hinzufügen müssen, was den Code nur unnötig komplizierter machen würde.

    Der Performance-Vorteil kommt durch die Umstellung des Storage-Backends an sich, die userContextId tut nichts für die Performance. Der Grund dafür steht in meinem vorherigen Beitrag.

  • Also sowas
    https://developer.mozilla.org/en-US/docs/Moz…tual_identities
    https://developer.mozilla.org/en-US/docs/Moz…xtualIdentities

    Würde dann so ein Storage-Ordner eine andere ID bekommen bzw ein zusätzlicher Ordner für zB uBlock mit einer anderen ID für einen Container? Würde dadurch uBlock mit mehreren Datensätzen arbeiten?

    Wenn du weinen möchtest, bist du falsch hier. Hier gibt es nur Lösungen!
    Oh Herr, wirf Hirn, oder Steine - Hauptsache, du triffst endlich.
    Zu viele Goofies und Dulleks vom Dienst. Schlabokka!

  • Wie ich im letzten Beitrag bereits versuchte zu erklären, wird lediglich der vorhandene Mechanismus mitgenutzt. Es gibt keine verschiedenen Identitäten für Erweiterungen. Die Bezeichnung userContextId kommt von den Contextual Identities, hat ansonsten aber nichts damit zu tun. Die userContextId ist für alle WebExtensions und alle Nutzer gleich, da fix im Code hinterlegt, und stellt lediglich sicher, dass Erweiterungen nicht direkt auf die Datenbanken zugreifen können.