User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:184.108.40.206) Gecko/20070515 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:18.104.22.168) Gecko/20070515 Firefox/22.214.171.124 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
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).
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.
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
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 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.)
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.)?
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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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".
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
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 258301
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 → ---
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.
Um, there hasn't been any activity on this bug in almost a year. Has the documentation been updated?
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
Last Resolved: 10 years ago → 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.