Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable CanvasBlocker first-run page #270

Open
allo- opened this issue May 29, 2023 · 9 comments
Open

Disable CanvasBlocker first-run page #270

allo- opened this issue May 29, 2023 · 9 comments
Labels

Comments

@allo-
Copy link
Owner

allo- commented May 29, 2023

CanvasBlocker now supports disabling the first-run page: kkapsner/CanvasBlocker#656

Also "[email protected]": "" should be reviewed if it is needed / useful.

@allo-
Copy link
Owner Author

allo- commented May 29, 2023

Waiting for 1.10 on AMO for a short test before adding it.

@kkapsner
Copy link

You could test with the alpha version: https://canvasblocker.kkapsner.de/versions/

@kkapsner
Copy link

The default value for whitelist is the empty string since six years: https://github.com/kkapsner/CanvasBlocker/blob/master/lib/settingDefinitions.js#L47

@allo-
Copy link
Owner Author

allo- commented May 29, 2023

Is it signed with the right key for AMO or do I need to use a nightly to install the alpha version? The zip download bundles the xpi and I think the right signature would be enough, but I am not sure about the enterprise policy version. In the end, enterprise policies are the cleanest way to install addons by default, but they require the user to modify the installation directory instead of the profile directory and affect all profiles.

@kkapsner
Copy link

It is properly signed but self hosted. I have it installed in my daily Firefox profile (not nightly).

I have no clue about the enterprise policy version.

@allo-
Copy link
Owner Author

allo- commented May 31, 2023

Looks like for this type of settings yet another settings store needs to be implemented. Most settings are settings that afaik aren't used by extensions anymore and simple inline files, e.g., for settings as JS file are implemented, but I think the settings here are stored in indexedDB?

I'm not sure what's the best way to write them from outside Firefox. Current Firefox seems to store them as sqlite3, but a dump doesn't contain the settings in a readable format.

Infrastructure issue: #271

allo- added a commit that referenced this issue May 31, 2023
[email protected]: "" is not needed
as the whitelist is empty by default. See #270
@kkapsner
Copy link

kkapsner commented Jun 1, 2023

Yes - the storage of the webExtension settings is different to old legacy settings and it also changed over time.

Maybe you can work with the file browser-extension-data/[email protected]/storage.js and the preference (in pref.js)

user_pref("extensions.webextensions.ExtensionStorageIDB.migrated.CanvasBlocker@kkapsner.de", false);

Not tested at all and a shot in the dark but worth a try because it's quite simple.

@allo-
Copy link
Owner Author

allo- commented Jun 1, 2023

I already see the migration being the next thing that is removed by Mozilla.

What I do not understand is that the sqlite3 file contains the settings names as text in the binary, but a database dump does not contain these strings.

@allo-
Copy link
Owner Author

allo- commented Nov 20, 2023

I guess with the requirement to create the storage in the right way it does no longer count as easy. Or may become easy again with #271.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants