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

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Liam K.]

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.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Maybe you chose by accident "Block images from.." in the context-menu? 

Comment 2

[Dave Townsend [:mossop]]

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.

Comment 3

[Giorgio Maone [:ma1]]

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).

Comment 4

[Dave Townsend [:mossop]]

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.

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Giorgio Maone [:ma1]]

(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)?

Comment 7

[Benjamin Smedberg]

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.

Comment 8

[Liam K.]

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?

Comment 9

[Dave Townsend [:mossop]]

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.

Comment 10

[Liam K.]

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.

Comment 11

[Liam K.]

I didn't see either of the lines you said, but it still blocks scripts.

Comment 12

[Robert Strong (they/them - no direct email)]

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.

Comment 13

[Liam K.]

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 14

[Liam K.]

Comment 12: parent.lock disappeared when Firefox closed. Comment 4 I forgot to do, checking now...

Comment 15

[Liam K.]

Comment 4: Both do exist.

Comment 16

[Dave Townsend [:mossop]]

Ok so this does appear to be the issue of preferences left laying around, this is strongly tied with bug 258301

Comment 17

[Giorgio Maone [:ma1]]

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.

Comment 18

[Robert Strong (they/them - no direct email)]

(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.

Comment 19

[Robert Strong (they/them - no direct email)]

(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.

Comment 20

[Dave Townsend [:mossop]]

(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.

Comment 21

[Robert Strong (they/them - no direct email)]

(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.

Comment 22

[Giorgio Maone [:ma1]]

A NoScript development build implementing bs' suggestion is available:

http://noscript.net/getit#devel

Comment 23

[Liam K.]

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.)

Comment 24

[Liam K.]

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.

Comment 25

[Robert Strong (they/them - no direct email)]

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.)?

Comment 26

[Giorgio Maone [:ma1]]

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.

Comment 27

[Robert Strong (they/them - no direct email)]

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?

Comment 28

[Robert Strong (they/them - no direct email)]

Ahhh... here is the answer. ;)
(In reply to comment #26)
>... clearing any user value should be found there on
> startup. 

Comment 29

[Robert Strong (they/them - no direct email)]

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. :(

Comment 30

[Dave Townsend [:mossop]]

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.

Comment 31

[Liam K.]

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.

Comment 32

[Liam K.]

Okay, the update for NoScript worked. Now the only problem is Adblock.

Comment 33

[u279076]

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.

Comment 34

[Liam K.]

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". 

Comment 35

[u279076]

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

Comment 36

[Nickolay_Ponomarev]

(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!

Comment 38

[Liam K.]

If the bug is fixed, it should also remove the entries when starting in safe mode.

Comment 39

[Liam K.]

Hmmm...would this be considered a duplicate, or does it depend on that bug?

Comment 40

[Dave Townsend [:mossop]]

Not a duplicate, safe mode and uninstall are different circumstances

Comment 41

[Dave Townsend [:mossop]]

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.

Comment 42

[Liam K.]

Um, there hasn't been any activity on this bug in almost a year. Has the documentation been updated?

Comment 43

[BMO Automation]

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.