Rob--W / dont-track-me-google

Firefox and Chrome extensions to prevent Google from making links ugly.
MIT License
459 stars 26 forks source link

Extension not save toggle settings in storage.js #57

Closed moakt3 closed 3 months ago

moakt3 commented 3 months ago

Hi.

Windows 10, Firefox 126.0.1

When in firefox disable this two pref:

user_pref("extensions.webextensions.ExtensionStorageIDB.enabled", false); user_pref("webextensions.storage.sync.enabled", false);

extension not save toggle settings "noping" and "forceNoReferrer" in storage.js file like other extensions do.

Can you do something with this?

Rob--W commented 3 months ago

Why do you want to toggle these preferences?

And what do you expect the extension to do when you intentionally broke the storage.sync extension API that the extension uses for storing preferences?

moakt3 commented 3 months ago

When your extension cannot save settings than "noping" and "forceNoReferrer" disabled by default.

Broke? Nope. Just disable this heavy trashcan API. After this ALL extensions save it's settings in mach better way.

/mozilla/xxxxxxx.default/browser-extension-data/extension_name/storage.js

Better for backup and transfer. I'm first time see extension that not support this.

Rob--W commented 3 months ago

When your extension cannot save settings than "noping" and "forceNoReferrer" disabled by default.

Broke? Nope. Just disable this heavy trashcan API. After this ALL extensions save it's settings in mach better way.

The use of the storage.sync API enables users who are logged in into Firefox Sync to share the same extension preferences across their Firefox browsers. If the user is not signed in, the data is saved locally. Have you tried resetting the webextensions.storage.sync.enabled pref to its default value (true)?

/mozilla/xxxxxxx.default/browser-extension-data/extension_name/storage.js

Better for backup and transfer.

What do you mean by better for backup? If you want to back up your data, copy the whole xxxxxx.default directory, not just some bits and pieces. You cannot just take some files and expect the backup to accurately represent your configuration.

I'm first time see extension that not support this.

Other extensions probably use the storage.local API and are therefore not affected by your choice of preferences.

moakt3 commented 3 months ago

Yeah, right. More than 30+ extensions I have tested and all work as they should. Only yours has compatibility problems. But you see problems only in the user's actions. That says a lot about you. And please don't tell me how I should use my browser. If you don’t want to change anything, then just write about it in the first post. Bye.

Rob--W commented 1 month ago

The motivation behind my previous questions was to get a better understanding of your particular use case, since the current combination of what you're doing is not officially supported and therefore subject to change in any browser update. My interest is not just due to me being the developer of the extension in this repo, but also due to me being a browser engineer working on Firefox.

From your descriptions it sounds like your use case is to ease backup and transfer. The reason for my previous question about your selective backup is because there is no guarantee that the copy of a few files will result in a complete backup. I am therefore wondering how you're trying to back up and restore, because anything other than "copy whole profile directory (optionally except for some) + paste profile directory" has a high likelihood of breaking at some point. For example, if you only copy the "storage.js" without the extension itself (i.e. xpi file), then it is possible for a "restore" result in data that is incompatible with the extension (if the extension version differs).

As a browser engineer working on Firefox, I'm currently reviewing a patch that is going to remove the webextensions.storage.sync.enabled preference, and would like to understand your reasoning for using that preference, to see whether your desired effect is still supported even with the removal of the preference. My guess is that you're hoping that disabling the feature would somehow force extensions to fall back to storage.local instead of storage.sync, which in combination with the other pref would result in writing to storage.js. This alone is not a sufficiently strong reason to keep the pref.