Closed Bug 388268 Opened 17 years ago Closed 6 years ago

Changes to preferences made by extensions are still in effect in safe mode

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: liam.kirsh, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

When I visit a website with ads, some are still removed with Adblock. Also, NoScript will block some scripts. I think it is because the settings in about:config aren't disabled.

(Some ability in extensions are still kept, even when the extensions are disabled.)

Reproducible: Always

Steps to Reproduce:
1. Download Adblock (w/ Adblock Filterset.G Updater) or NoScript
2. Visit a website with ads (for Adblock) or scripts (for NoScript)
Actual Results:  
Scripts (for NoScript) or ads in Adblock's database are disabled.

Expected Results:  
It should have allowed the scripts/ads.

I don't see a way to check if it has to do with about:config settings or if it is something else.
Maybe you chose by accident "Block images from.." in the context-menu?
Component: Extension Compatibility → Extension/Theme Manager
QA Contact: extension.compatibility → extension.manager
Certainly noscript uses the built in caps system to restrict javascript code execution. Unless noscript removes these settings itself when it is disabled it will still be in effect in safe mode.

NoScript does reset its CAPS preferences every time Firefox exits.
Doing so, it tries to guarantees a "clean" safe mode, unless Firefox had no chance for a clean exit (e.g. after a crash).

I've just verified that NoScript happily cleans up after itself so I guess we need to figure out exactly what you are seeing here.

Can you exit Firefox, then go you your profile folder (http://kb.mozillazine.org/Profile_folder_-_Firefox) and open prefs.js in a text editor (note that checking this in about:config will not work).

There should not be a line saying:
user_pref("capability.policy.default.javascript.enabled", "noAccess");

There also shouldn't be a line saying:
user_pref("capability.policy.policynames", "maonoscript");

If those lines are gone then open Firefox in safe mode and see whether NoScript still appears to be taking effect. In particular try to check a site that normally wouldnt run scripts isn't and that a site that normally would is. lso make sure that you see the safe mode dialog when you start.
Why is NoScript setting userprefs? If it needs to dynamically set prefs but shouldn't persist them, it should get the default prefbranch and set prefs there; this will prevent any chance of persistence.
(In reply to comment #5)
> Why is NoScript setting userprefs? If it needs to dynamically set prefs but
> shouldn't persist them, it should get the default prefbranch and set prefs
> there; this will prevent any chance of persistence.
> 

NoScript does something like this:

var caps = preferenceService.getBranch("capability.policy.");
caps.setCharPref("default.javascript.enabled", "noAccess");

It does other stuff under the caps branch (e.g. setting and configuring its own policy).
Do you mean cutting the branch deeper would prevent the changes from being persisted by any change (for instance if preferenceServices.savePrefFile(null) is called somewhere else)?
Yes... try the following code:

var caps = preferenceService.getDefaultBranch("capability.policy");
caps.setCharPref("default.javascript.enabled", "noAccess");

This of course assumes that the user does not have a userpref set for this value. If there is a userpref, it will override the default prefs.
Wow, that's a lot of replies for one day.

Do you want me to follow the instructions in comment 7, comment 4, or both?
Component: Extension/Theme Manager → Extension Compatibility
Comment 7 is for Giorgio. I'd still like you to perform the steps in comment 4, I'm interested in verifying whether what you are seeing is caused by left over preferences (which is somewhat a known issue) or something else that I'm not aware of.

I was having trouble with profiles last year (I created one called "Test" and then the other one got really messed up for some reason), and so I'm not sure what profile I'm using. (Also, for some reason my profile manager is not opening? Maybe I should make a new bug report for that?)

I think I'm using Test, so I'll post my results for that in the next comment.
I didn't see either of the lines you said, but it still blocks scripts.
With Firefox running look in your profile directory for a file named parent.lock. If this file isn't present then that isn't your profile directory.

After finding the directory with parent.lock in it exit Firefox. If the parent.lock file is still present then Firefox hasn't exited. I bring this up since this will prevent the profile manager from displaying and will also prevent noscript from removing the prefs it uses.

Please comment back with your findings from following these steps.
Summary: add-ons are not completely disabled in safe mode → Settings from some extensions are still in effect in safe mode
Oh, okay. I was looking in the wrong profile when I followed the instructions in comment 4. I'll post the results of comment 12 and comment 4 in the next comment.
Comment 12: parent.lock disappeared when Firefox closed. Comment 4 I forgot to do, checking now...
Comment 4: Both do exist.
Ok so this does appear to be the issue of preferences left laying around, this is strongly tied with bug 258301
I'm all for switching NoScript to the getDefaultBranch() trick suggested by bsmedberg for CAPS settings. BTW, its usage to manage "volatile" preferences may deserve better documentation.

On the other hand, in this very case the (temporary?) problem seems to come from "profile-before-change" observers (like the NoScript service, which would run its "resetJSCaps" method) not being notified, probably because of an abnormal Firefox exit.
Component: Extension Compatibility → Extension/Theme Manager
(In reply to comment #17)
>...
> On the other hand, in this very case the (temporary?) problem seems to come
> from "profile-before-change" observers (like the NoScript service, which would
> run its "resetJSCaps" method) not being notified, probably because of an
> abnormal Firefox exit.
A likely suspect is bug 333907 which makes us not quit cleanly on Windows OS shutdown and of course any app crash would prevent the removal as well.
(In reply to comment #16)
> Ok so this does appear to be the issue of preferences left laying around, this
> is strongly tied with bug 258301
Somewhat tied to... since the extension was just disabled and not uninstalled it wouldn't have helped.
(In reply to comment #19)
> (In reply to comment #16)
> > Ok so this does appear to be the issue of preferences left laying around, this
> > is strongly tied with bug 258301
> Somewhat tied to... since the extension was just disabled and not uninstalled
> it wouldn't have helped.

Right, but presumably if we came up with some way of clearing out an extension's prefs on uninstall we could use the same mechanism when in safe mode.

(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #16)
> > > Ok so this does appear to be the issue of preferences left laying around, this
> > > is strongly tied with bug 258301
> > Somewhat tied to... since the extension was just disabled and not uninstalled
> > it wouldn't have helped.
> 
> Right, but presumably if we came up with some way of clearing out an
> extension's prefs on uninstall we could use the same mechanism when in safe
> mode.
I would be hesitant to do this with prefs that are app prefs vs. extension prefs which is the case here. For this instance using getDefaultBranch would be a better solution as I see it.
A NoScript development build implementing bs' suggestion is available:

http://noscript.net/getit#devel
I also have the same problem with Adblock.

This problem has been a nuisance lately because some forums and functionality in websites don't work, and there is no way to allow them without going to normal mode. (I am using safe mode lately because I haven't been needing extensions and safe mode is faster.)
I just found an easy way to show an example of the problem (in case anyone hasn't been able to reproduce it): 

1. Make sure mozilla.org is not in NoScript's whitelist.
2. Close Firefox, and open it in safe mode.
3. Open this bug report, and go to the top of the page where it says "Depends on: (edit)" or "Blocks: (edit)".
4. Click on either of the "edit" buttons, which use javascript.
Liam, there are several conditions where noscript won't be able to remove the prefs it sets. To fix that you might try the noscript development build as mentioned by Giorgio in comment #22 which uses a method for setting the prefs that should not persist after exiting cleanly, if the app crashes, etc. I'm not sure if Giorgio added code to his extension to cleanup the prefs when in the condition you find yourself so it may take a couple of extra steps. As for adblock, which version are you using?

Giorgio, did you add code in the dev version of noscript to remove the prefs if they persisted due to a crash (e.g. OS shutdown, etc.)?
Rob, the development version I mentioned in comment #22 was built and tested purposely to handle crashes and other abnormal exit situation.
Specifically, it uses default pref branches for its application-level CAPS modifications (i.e. the default.javascript.enabled policy and the policynames list), saving elsewhere and clearing any user value should be found there on startup. 

This way, if the browser exits prematurely with no chance of notifying observers, the JavaScript-blocking preferences are automatically reset to browser's defaults (as expected in safe mode).

On normal exit/profile change or on extension removal/disablement through Extension Manager, the previous user values, if any, are restored.
Giorgio, I realize that... what I am concerned with in Liam's case is the scenario where noscript is disabled in the add-ons mgr., the app crashes (e.g. OS shutdown or whatever), noscript wasn't given a chance to remove the prefs in the user's prefs.js, noscript is disabled when the app is next started, and the prefs are still in the prefs.js. Will the development version remove these prefs from prefs.js in this scenario or does it only work with getDefaultBranch without removing prefs left behind by a previous version of noscript?
Ahhh... here is the answer. ;)
(In reply to comment #26)
>... clearing any user value should be found there on
> startup. 


I recall several years ago seeing samples and explanations of using getDefaultBranch in this manner but that was likely for SeaMonkey... a quick search didn't come up with anything. :(
Possibly we need to start pushing out to the community the use of the default branch for this sort of thing. I guess some docs on devmo wouldn't go amiss.
In comment 23 and  comment 24 I wasn't saying the extension update didn't work. I haven't tested it yet.

I am using Adblock version 0.5.3.043.
Okay, the update for NoScript worked. Now the only problem is Adblock.
Using both Firefox 2.0.0.6 and Minefield 20070828, AdBlock works as expected.  In normal mode, it blocks the ads I have specified.  In safemode, the ads are displayed.

Reporter, please try updating to 2.0.0.6 and make sure that you are running the latest version of AdBlock.

Let us know if this fixes your problem.

Thank you.
I have Firefox 2.0.0.6 and Adblock 0.5.3.043. An example of where it blocks ads is the website I just added to the URL field. If you click on the designated button, it shows some ads that are blocked out or just say "Click here".
URL: http://www.thehungersite.com/clickToG...
The latest version of adblock reported by addons.mozilla.org is 0.7.5.1.  Please try using the latest version of the AdBlock.

It can be downloaded from this URL:
https://addons.mozilla.org/en-US/firefox/addon/1865
Summary: Settings from some extensions are still in effect in safe mode → Changed to preferences made by extensions are still in effect in safe mode
(In reply to comment #30)
> Possibly we need to start pushing out to the community the use of the default
> branch for this sort of thing. I guess some docs on devmo wouldn't go amiss.
> 
Please file bugs in the MDC component about this sort of things!
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
If the bug is fixed, it should also remove the entries when starting in safe mode.
Hmmm...would this be considered a duplicate, or does it depend on that bug?
Not a duplicate, safe mode and uninstall are different circumstances
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Product: Firefox → Toolkit
URL: http://www.thehungersite.com/clickToG...
Status: UNCONFIRMED → NEW
Ever confirmed: true
We need to document that if extensions are modifying hidden firefox preferences then they should do so using the default branch on every startup. That way the preferences go back to their normal values in safe mode and when the extension is uninstalled. That is all that we can do here I think.
Keywords: dev-doc-needed
Um, there hasn't been any activity on this bug in almost a year. Has the documentation been updated?
Blocks: safe-mode
Summary: Changed to preferences made by extensions are still in effect in safe mode → Changes to preferences made by extensions are still in effect in safe mode
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 16 years ago → 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.