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

Active/disabled flag not saved #2652

Closed
McBen opened this Issue Nov 9, 2017 · 10 comments

Comments

Projects
None yet
3 participants
@McBen

McBen commented Nov 9, 2017

Greasemonkey 4.1beta2
Firefox 58.0b1 - Linux/Kubuntu

on FF startup GM is always active even if disable in previous session

@Sxderp

This comment has been minimized.

Contributor

Sxderp commented Nov 9, 2017

After tracing the toggle button through a message and quite a few function calls, we're eventually lead here. In which an 'EnabledChanged' message is sent but nothing is listening. So, the setting isn't saved nor is it actually loaded. It's currently, from what I can tell, hard coded as enabled on startup.

Looks like this needs to be added as a database entry somewhere so it's saved.

@arantius

This comment has been minimized.

Collaborator

arantius commented Nov 9, 2017

Indeed; setGlobalEnabled() should be doing some persistence.

The EnabledChanged message was an analog from 3.x whereby there were multiple places that it could be changed, so the change was broadcasted to enable all the UIs to update when any one of them was used. Might be obsolete now.

@arantius arantius closed this Nov 9, 2017

@arantius arantius added this to the 4.1 milestone Nov 9, 2017

@arantius

This comment has been minimized.

Collaborator

arantius commented Dec 11, 2017

This shouldn't have been closed!

@arantius arantius reopened this Dec 11, 2017

@arantius arantius modified the milestones: 4.1, 4.2 Dec 11, 2017

@Sxderp

This comment has been minimized.

Contributor

Sxderp commented Dec 11, 2017

Initially I'd want to stick this in storage.local because it's a simple pref. However, if memory serves, when I tested this (some time ago) userscripts (i.e. content scripts) have access to the same storage.local instance that privileged extension pages and the background page have access to. While the harm that a userscript could potentially cause is fairly minimal (set extension onload state enabled / disabled), it still feels bad.

rip sandboxes

@arantius

This comment has been minimized.

Collaborator

arantius commented Dec 12, 2017

This (user scripts execute at full extension-content-script privs) should be temporary, but for now I have to agree.

@arantius

This comment has been minimized.

Collaborator

arantius commented Jan 5, 2018

We're already using local storage in one place. And there's not much a script could do with access to this single value. So for now, it's easy and we're going there.

@arantius arantius closed this in d2d7984 Jan 5, 2018

@arantius

This comment has been minimized.

Collaborator

arantius commented Jan 5, 2018

The above fix has been packaged in a new beta version:
https://addons.mozilla.org/firefox/downloads/file/830369/greasemonkey-4.2beta1-an+fx.xpi?src=devhub

Testing and confirmation would be appreciated!

@arantius arantius reopened this Jan 6, 2018

@arantius

This comment has been minimized.

Collaborator

arantius commented Jan 6, 2018

As written this causes Greasemonkey to disable itself upon first launch (because the setting is "enabled", is not present, so is not truthy). That shouldn't happen.

@arantius

This comment has been minimized.

Collaborator

arantius commented Jan 9, 2018

The above fix is packaged in version 4.2beta2:
https://addons.mozilla.org/firefox/downloads/file/833159/greasemonkey-4.2beta2-an+fx.xpi?src=devhub

Testing is always appreciated!

@arantius arantius closed this Jan 9, 2018

@arantius

This comment has been minimized.

Collaborator

arantius commented Jan 9, 2018

Actually I mean b994449 (where I typoed 2562 instead of 2652).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment