ConfigFox 1.4 update improves search among other things
ConfigFox 1.4 is the first public update of the Firefox advanced configuration manager that introduces new features and improvements across the board.
When we created Firefox's extensive list of privacy and security settings, we wanted to create a resource for all users of the web browser that would point them to preferences hidden from the main user interface.
Firefox is without doubt the browser offering the most customization options from them all, and while Mozilla removed options in recent time from the browser, that has not changed yet.
The list of preferences that we have created here on Ghacks allowed you to either pick preferences you wanted to change and change them using about:config in Firefox, or to push a user.js file to the Firefox profile directory to make all the changes in one go.
ConfigFox improved the process significantly. Instead of an all or nothing approach, or one where you'd go through the configuration manually to remove items, you'd do handle it all in the program interface.
Apart from using categories effectively to make it easier to enable or disable tweaks, it shipped with a boatload of features including search, the highlighting of new preferences, and options to update the collection from within the program interface.
ConfigFox 1.4 improves the -- already great -- program further. Windows users who don't use Firefox but a browser based on Firefox are now able to select the executable file of that browser instead to power some of the functionality of the program. Please note that the option is only provided if Firefox is not found on the system, and that it does not affect the option to modify preferences of these browsers using the program.
Search has been improved in the latest release. If you read my initial review of ConfigFox you know that it needed improvement and that's what the update delivers. Basically, it enables you to hit the PageUp or PageDown key to navigate between search results even if the search field is not highlighted anymore.
While I would like to see all search results being highlighted at once, for instance next to the scrollbar to indicate all hits, it improves search in the new version.
ConfigFox 1.4 ships with a change that some users may have issues with. The program's default.js file, the file that contains all the preferences that you can apply to Firefox, has been stripped of entries that are found in Firefox's option's interface.
According to Leandro, this has been done to avoid confusion and conflict. While I can see that this can be problematic, maybe a better option would be to inform users about these conflicts when changes are applied. Since it is possible to add your own preferences to the program,
The program ships with other changes. You may run the Firefox Profile Manager from the Tools menu directly now, run a new version check from Help, and you won't run into inconsistencies anymore when renaming items.
Closing Words
ConfigFox is a highly useful program for Firefox and browsers based on Firefox. While it is possible to make the preference changes manually as well, it makes the process comfortable and easier to handle. If you have not already, I suggest to give it a try.
Leandro,
Thank you for your reply! I understand your concern, but the only thing worse than having to warn users that unchecking an option in ConfigFox merely re-enables whatever option they may have set using Firefox’s interface (and thus exists in prefs.js), would be to have them uncheck the option in ConfigFox and have whatever option they previously set in Firefox suddenly revert to the default value (from default.js)… the latter, in my opinion, is more confusing and apt to create unanticipated side-effects. After all, the worst that happens under the former scenario (where ConfigFox doesn’t alter prefs.js) is that an option reverts to whatever the user previously configured through the Firefox interface; in the current scenario, a previously configured option may suddenly and unexpectedly revert to Firefox’s default value, undoing what the user had intentionally changed before.
I don’t think it diminishes the value of ConfigFox as a tool to have it only edit user.js. If you are able to offer ALL related options, categorize them in meaningful ways, add informative descriptions, warnings, and links, and color highlight those entries that already exist in prefs.js (and thus have been configured by the user through the standard FF interface), you will have a tool that is of great service, addressing a need that no other tool currently addresses.
Warning about an unchecked entry in ConfigFox re-enabling an existing value in prefs.js is also quite valuable, and should allay the concerns of users; putting a bold-faced warning at the top of ConfigFox that its options (stored in users.js) trump any stored in prefs.js should address those users who don’t understand why going back to the FF interface to re-enable cookies (for instance) doesn’t “stick.” Users should know that once they turn to ConfigFox for setting privacy and security options, ConfigFox should then be their source of record from that point forward. Again, that’s the value of the tool, and a good thing.
It’s a shame we have to go through all of this just to ensure our privacy and security; these really ought to be the default settings. But since they aren’t, the work of you and Pants is of great benefit to everyone. I sincerely appreciate it.
Dan
“After all, the worst that happens under the former scenario (where ConfigFox doesn’t alter prefs.js) is that an option reverts to whatever the user previously configured through the Firefox interface; in the current scenario, a previously configured option may suddenly and unexpectedly revert to Firefox’s default value, undoing what the user had intentionally changed before.”
Dan,
– If an item is removed from prefs.js, then it reverts to the default value in about:config
– If an item was previously customised in user.js to a value DIFFERENT from the default, and is then commented out or deleted, the item stays in prefs.js.
– If an item was previously customised in user.js to a value SAME as the default value, and is then commented out or deleted, the item stays in prefs.js. But it will show up in about:config as “user set”, even though it is the default.
– So in your first scenario (where configfox doesn’t alter prefs.js) – NOTHING reverts, there is no unexpected behaviour. The previous setting stays, regardless of whether it was customized or default. There is no worst case in this scenario. It’s working as advertised.
– In the second scenario (where ConfigFox removes the item from prefs.js) then the setting WILL most likely (95%?) (because most prefs differ from the default) cause a change.
And this is the crux of the issue. Leandro wants to make life easy for “laymen” and teach them that unchecking a tick box reverts the preference in firefox, even though this tool uses a user.js and breaks how that is meant to function, and breaks the laws of coding by executing code on commented out lines.
I only have two suggestions.
1. Don’t ever touch prefs, let FF do it, teach users that this is the way it works.
2. IF an option is added: [x] “allow ConfigFox to revert unchecked items to default in Firefox preferences”
then I suggest that some help/info screen be added that fully explains the situation fully, i.e how a user.js is expected to work, but for those who don;t wish to dig thru about:config, how this option may help them, and it’s consequences.
Leandro, I hope you see the “wisdom” of my words, and leave the prefs.js alone – it doesn’t break the mozilla mechanism/model as laid out on their website, it solves confusion (among everyone, beginners and experts), it allows a full set of items you since removed due to confusion, it allows standalone js editing/creation etc – it will allow us to develop a better list. WHEN this becomes an extension – then this issue is a moot point.
Thanks Dan.
I see your point. It is hard to tell all that to the layman users though.
The regular user don’t want to get into technical details. He wants to “click and happen”.
See right above your reply the suggestions I pointed out.
I have this idea:
A menu option to check/uncheck —> [ ] Do not modify prefs.js
This option would be for advanced users only.
Checking this option ConfigFox would not touch prefs.js
Then the paranoids could use ConfigFox without any worries. By having this option checked, ConfigFox would work only user.js, ignoring prefs.js completely.
Fair enough?
Great idea, Leandro: I’m always in favor of configurable options… that puts the power in the hands of the users. That said, could there also be an option to include ALL entries (even those configurable through Firefox options)… i.e., the comprehensive list that Pants developed (perhaps v 07 when it comes out) along with their descriptions? That way, advanced users could achieve the preference Pants and I seem to share: to use ConfigFox to manage ALL of our security and privacy options for Firefox while ensuring only user.js gets modified.
I’m excited about this! I look forward to seeing the next version of ConfigFox. Many thanks to both you and Pants for your efforts, and to Martin for creating the forum for this exchange. It’s amazing what can happen through collaboration. Well done!
Thanks for the feedback Dan!
Next version will ship with that option.
> “Could there also be an option to include ALL entries”
Another idea!
Pants can mantain the FULL COLLECTION version which would include ALL entries.
in this case, who wants to use that collection just change this entry in ConfigFox.ini
FROM
UpdateURL=http://master.dl.sourceforge.net/project/configfox/default.js
TO
UpdateURL=http://.js
Then all problems solved. Fits everyone.
I’m glad that after all the trouble we got to an agreement.
Good Lord. With all of this drama, estrogen, and cat-fighting, it’s no wonder that “ghacks is a shitty washed up site that begs for money”
LMAO!
The comments have been very entertaining.
I have honestly enjoyed this. It was different.
Leandro, thanks for your work. I have enough difficulty making the simplest of add-ons.
Pants, thanks to you too.
Martin, you’ve had courage all along.
Scarecrow, you’ve always had a brain.
Luke Skywalker, Darth Vader lied, the mailman is your father. Or the cable guy, we’re just not sure. Your mom was a ho.
@theMike,
“Pants comments and the fact that it’s still up”
There’s already too much censorship online with companies and countries controlling what you can and cannot see, say, post, save, etc and Martin lives in a place that does some of that so I applaud him for butting out.
:) thanks Ken.
Actually thanks to this page ConfigFox ideas are getting straight/clarified for the next version.
Thanks to Martin for allowing such a mess on his website :)
Without this “mess” we couldn’t have things straight and ideas sorted out.
”
I don’t know why a lot of that was stripped out, you’ll have to ask him.
”
——– Forwarded Message ——–
Subject: ConfigFox
Date: Wed, 7 Oct 2015 15:55:30 -0300
From: Leandro Azevedo
To: Pants
Hey Pants,
I’m planning to release a new version of ConfigFox in a month or so. Bug
fixes, new features, etc…
I hope you have some good stuff by then so we can boost it with new
config entries. I’m also trying to design a proper website for it but
the time is kind short.
Leandro
———————————
I’d like to have had an answer from you 20 days ago.
I’d like to dicuss with you the options I had in mind for the next version (1.4).
You didn’t answer the email and said you would be busy with some other things.
That’s why I stopped involving you in the ConfigFox idea.
There’s been like one extra user_pref added to my own list since version 6 was posted months ago (and your list is massively divergent from mine now). Also, the ability to modify and distribute your prefs in the default.js means these are not crucially time sensitive – I was waiting for the next actual release – the first release was 30th Sept – exactly 4 weeks ago. Other suggestions were already hinted at/mentioned in emails/ghacks threads, and I have been busy. I appreciate you keeping me in the loop and the contact, but as I said at the very very very start.via Martin, that I would offer suggestions, beta-test but that I do not wish to be part of the actual project. This is your project. I have a ton of ideas, but I also wanted to see where this was going.
Here’s one:
1. use field tags for all non-user_pref lines: stick to a small simple list, something like [cat], [sub], [group], [item], [p], [url], [tag], [icon] (icon can be a built in limited set of your choosing such as warning/troubleshooting etc – and apply to any node]. tags and urls would be comma delimited. Clearly cat + sub + group signify folder levels, item signifies a line entry (pref), whereas p. tag, url, icon all relate to the previous [cat,sub,group, item].
2. follow some format
/* configfox compliant text */
// [p]description of this user.js etc
// [cat]Privacy
// [p]description of category
// [sub]Geolocation
// [p]description of subcategory
// [group]disable GeoIP-based search results
// [p]description of the group entries
// [url]https://trac.torproject.org/projects/tor/ticket/16254, https:www.example.com/[/url]
// [tag]locale, search, fingerprinting[/tag]
// [item]
// [p]item description
// [url]etc
// user_pref(“browser.search.countryCode”, “US”);
// [item]
// user_pref(“browser.search.region”, “US”);
// [group]disable location-aware browsing
etc
This would end up something like this:
Welcome
-Privacy
–Geolocation
—disable Geo-IP based search results
—-[x] browser.search.countryCode
—-[x] browser.search.region
—disable location-aware browsing
etc
and each and every single level of the tree can have information and urls and icons and tags etc
3. Now you can display the entire “help” manual of entries and info and hyperlinks in a single page, and you can make it searchable and also filterable by tags (even by icon type). And of course you can display just the relevant info when a user is on a select node.
Whatever works for you, but something like the above keeps the rules simple – all info before the item/folder. each info type on a new line. this helps keep items in IDE’s shorter (I do not like word wrap on in IDEs :) ).
However, long story short, I’ve been waiting for the functionality before form. The UI can change later. Like I said, I have a ton of ideas. If you still want my input, I will offer it when I can.
So I guess now is not the time to mention locking preferences then .. http://kb.mozillazine.org/Locking_preferences
lockPref(“pants.shut.up”, true);
I do welcome your suggestions. Always welcome.
But some suggestions, like the tags, would call for major code changes. It would take some time to adapt. Good idea though.
I love programs like ConfigFox so this isn’t meant as a criticism, maybe it’s just my lack of knowledge as when i first tried out ConfigFox my first thought was hear lies demons, i would have researched what each setting done/changed but just didn’t have the time or wherefore to go searching Google for each setting.
Like i said this isn’t a criticism as someone with a better understanding than me probably knows what each setting does, saying that though it would be nice if each setting had some extra info, maybe a help file or links to Mozilla’s explanation of them.
Hey Corky,
Very good point there!
I removed some of original comments and options from Pants’ List because those options were confusing users. So, settings that can be set from Firefox itself were stripped, along with their comments.
The original layout of Pants’ list was ok but a little messy and confusing. In the layout rearrangement to fit ConfigFox “format” some comments may have been left behind indeed.
As new versions comes out I’ll be commenting the options so users can get a fair description of what those options do.
Pants’ comments were in some case inappropriate or too technical to put as description. I want to put descriptions that most users can read and understand, not only the expert ones. So I stripped some more :)
Some options in Pants’ List are way too extreme and could cause some websites to stop working or work unexpectedly. Those “extreme” settings can be returning to the collection in the future with an alert icon, so the user can know that option can bug some sites.
(the alerting icon is a Pants idea – very nice suggestion!)
“Some options in Pants’ List are way too extreme”
The list hosted here on ghacks (version 6) is actually the one where the items such as indexeddb, the three allow*states for history etc are all set to defaults which are much less likely to break anything, or they are commented out. And they have information and links about them to inform people.
// user_pref(“security.cert_pinning.enforcement_level”, 2);
user_pref(“security.OCSP.require”, false);
// user_pref(“plugins.enumerable_names”, “”);
user_pref(“dom.indexedDB.enabled”, true);
// user_pref(“network.http.redirection-limit”, 20);
user_pref(“browser.history.allowPopState”, false);
user_pref(“browser.history.allowPushState”, false);
user_pref(“browser.history.allowReplaceState”, false);
These are just some examples of some prefs that could break some sites (eg those allow*states break youtube’s tab history.
By removing items such as indexeddb (which is not in FF’s options), then you remove an item from a “comprehensive” list. The item is set to be a default true (no breakage), but still allows an end user to turn it off. Yes, I know users can add their own prefs – but they are not likely to, since they perceive this to be building upon the ghacks “comprehensive” list.
“it would be nice if each setting had some extra info, maybe a help file or links to Mozilla’s explanation of them.”
The original list, that Leandro used as the basis for his, had all of those. I don’t know why a lot of that was stripped out, you’ll have to ask him. The ConfigFox list is vastly different to my original – different groupings, different placement of items, different titles, less information. But end users can create their own.
”
No no no no no NO .. just NO.
ConfigFox should NOT EVER touch the prefs.js. It’s for handling user.js files.
”
You write like you were my teacher or something.
Do you know how many years of experience I have in software development field? 17 years!
Now I have to listen to you how I “should” or should not write my code?
Watch your words kiddo.
Leandro, take the emotion out of the equation – that was written almost 24 hours ago. We have since cleared the air/confusion via several emails and I have apologized numerous times including in this.thread. I have just written a totally emotionless response (to dan above) that I hope you read. My points are valid. And once again, you can design your software to do what you like, but you also need to be open to opinions. Peace out, dude :)
“No way, if you think ConfigFox is an user.js editor ONLY, then you are wrong”
Besides the extra tools such as dummy files etc – I, and I assume everyone else, thought that’s exactly what it was, with a few extra nice touches such as locating profiles etc. It’s only now come to light (for me anyway), that it is bypassing expected user.js behaviour – never in my wildest dreams would I have thought editing a live (that is in a profile) user.js would execute commented out lines. And that it the issue, which causes more issues.
It’s your software. It’s your list. It’s your choice. Just be open to opinions (you have put it out there in public, so be prepared for constructive criticism (right or wrong), and make the information on what the tool does very clear, That’s all anyone can ask, that’s all I ask.
Personally, I don’t need configfox (and no, lol, i don’t use notepad). But I am more than willing to use it if it meets my needs, and I am definitely more than willing to provide a ghacks version that is compliant, but not until it has at least an option to leave prefs.js alone. And I am always willing to provide information on new prefs and settings and feedback on the tool itself. Anything for the community and promoting privacy and security.
I think dan says it best
“that approach may have the side-effect of actually enabling a user’s misunderstanding of how things work between these two files”
The approach of bypassing how firefox works with user.js and prefs.js 1) creates unexpected consequences for those who do know how they work and 2) teaches those who don’t know, the wrong information. There are no winners using this method.
Experienced users expect changes in the user.js to only take effect on a restart
Experienced users never expect commented out prefs to execute actions
Inexperienced users need to learn this – otherwise, confusion. They need to realise that if they comment out a preference in user.js, then just as it’s always worked before, if they want to reset the preference, they have to do it via about:config. I understand you want to make this easy for newbies/laymen and those not up to speed with FF, but I don;t think you should fundamentally change how it works
When and if ConfigFox becomes an extension that can manipulate all settings from within FF (and export to a user.js), then you won’t have this issue.
By not touching the prefs.js at all, not even allow an option for it, then you can stop the confusion and allow a full and complete tool for, as dans says, “for any user (beginning through advanced).”. By also not touching prefs, you can allow creating and browsing for/editing any user.js file (I do like the auto finding of profiles though – it’s these small things that make good tools great). I don’t think I can really explain it any further. Prefs.js simply should be left alone and never touched except by FF.
Ok, ok. Peace on that.
Tell me, let’s say I’d listen to you and “not touch prefs.js”. :)
What do you suggest? Just an user.js editor? No way, if you think ConfigFox is an user.js editor ONLY, then you are wrong. If that was the case then ConfigFox would be useful for you only, not to anybody else. Because very few people know what happens with prefs.js X user.js. Then users would be using ConfigFox thinking they are customizing Firefox by checking/unckecking option which would not be true.
If you have an alternative I’m listening.
”
I was asking if the ConfigFox executable DIRECTLY edits the prefs.js. I didn’t mean if it did it indirectly via the user.js being used by FF on startup. If the answer is yes, then I cannot support this. This is unexpected behaviour.
”
I already answered, but just in case. ———–> YES <————
ConfigFox will "edit" prefs.js to remove ONLY entries you unchecked.
You don't like. Sorry. I don't need your approval.
I can assure everyone that ConfigFox does not mess with anything.
The code is there. Open Source!
Hi Leandro,
What Pants is saying is that it will actually be *more* straightforward if ConfigFox *only* modifies user.js… that keeps it nice and clean. Users simply need to know that commented out user.js entries will not affect any corresponding entries in prefs.js: a commented out entry in user.js simply means “use whatever is set in prefs.js, if any.” That is a cleaner approach.
I think what happened is that some users didn’t fully understand the relationship between user.js and prefs.js and thus got confused when, say, cookie preferences set in FF options got overridden by something set in user.js… which led you to make the change where only non-FF options get set in ConfigFox. But another solution here is to inform the user that this is how user.js works. It may be better for users to understand this relationship than to go to the extra work in ConfigFox of trying to prevent any conflicts: that approach may have the side-effect of actually enabling a user’s misunderstanding of how things work between these two files.
I really do appreciate the work you’ve put into this, and find the tool very promising; I wouldn’t bother commenting otherwise. It’s so close to being truly useful for even advanced users; I know Pants speaks bluntly, but his points are valid: if ConfigFox includes the comprehensive set of entries (regardless of what can be set in FF or PM or any browser), groups them into categories, has informative descriptions of what each does (and warnings where appropriate), and only modifies user.js, it will be a far more useful tool for any user (beginning through advanced). Just my opinion, and no disrespect intended for your considerable efforts!
Hey dan,
Thanks for your words!
Let’s suppose in the next version I leave prefs.js alone.
How can I explain to the majority of layman users that although the option is unchecked, the option may still be into effect in his/her profile?
Maybe a message like this when the user uncheck a preference:
“You have uncheck a preference. If that preference is still in prefs.js you may want to manually remove it, otherwise it may still be into effect.”
How uggly! Users would find ConfigFox way too complicated.
I don’t see the harm “editing” prefs.js
The ONLY line removed (AND ONLY THAT) is the one the user have unchecked.
And that one line can be put back with ONE click.
ConfigFox is two projects in one:
– Develop the program itself.
– Maintain the collection.
I could use a volunteer that would help to mantain a collection (default.js).
But before that we have to straight out the issue with prefs.js
Thanks dan, you say it so much better than me. Let me first say that I too intend no disrespect – we’re all passionate here about privacy and security. Take the emotion out of the equation (I have none except enthusiasm). All my comments are meant as questions or suggestions or debate (apologies for the bluntness at times). But here is what I will say, and this is due to a misunderstanding of how ConfigFox works (and it has only just become clear to me that this is what it does) – and it should be made clear by the developer. If this is how the developer wants it to work, that is his prerogative, but it should be made clear.
The Moziila model:
– INTERNALLY (via extensions, about:config, options), Firefox changes or resets preferences. Customized settings are stored in prefs.js. A reset to default preference is removed from prefs.js on a Firefox restart. Firefox itself does not edit user.js files – it only reads them. Firefox edits the prefs.js.
– EXTERNALLY a user may edit/create a user.js file of user_prefs which Firefox will then read and write to the prefs.js file on startup. The user.js reads any user_prefs that are NOT commented out. Any code that is commented out is IGNORED. User.js files do NOT remove user_prefs from prefs.js. That is not how it was designed to work. User.js files do not directly edit prefs.js files – firefox itself does that.
– in code … commented lines in code are for documentation. They are also used as placeholders to suspend lines from execution. Firefox correctly ignores commented out lines and takes no action.
– This is the Mozilla model where there is a degree of separation between internally and externally manipulation preferences. Firefox handles prefs.js, end users write user.js, but firefox itself handles the changes to the prefs.js. This is exactly how is was designed to work. ONLY firefox edits the prefs.js.
The ConfigFox model
– Is an external utility that tries to act as an internal firefox mechanism (such as an extension)
– changes the behaviour of the user.js by directly editing the prefs.js instead of just the user.js and letting Firefox handle the changes on a restart. This is not such an issue if it is only editing or adding an option (that would happen anyway). The real problem is when it removes a preference. User.js files do NOT remove preferences – never has.
– in code … does not ignore commented options and instead takes the opposite action to delete from prefs.js. This is in direct contrast to what Mozilla does.
To me, ConfigFox creates unexpected behaviour and breaks the Mozilla model. It breaks the expected behaviour of the user.js. This explains a number of things – such as the developer’s choice to remove items that are already in FF’s options interface, as it creates confusion when none should exist. It also explains why ConfigFox doesn’t let you just create and edit standalone js files, as it is currently coded to also directly edit a prefs.js.
This is the only issue I have with ConfigFox (which I do not use currently for any user.js work).
I have dozens of settings in my user.js that are commented out – these are for documentation reasons or items I wish to address later. I may play around with them in about:config for testing. I would not expect any commented sections in my user.js to EXECUTE the resetting to default of anything – this goes against everything I know in over 20 years of working in IT (and yes that includes substantial years spent in software development).
I think ConfigFox is a wonderful tool, it has awesome potential. But to me the model is broken, sorry, and just causes confusion. All the best Leandro. Please just make it extremely clear that ConfigFox removes preferences and resets them to default if commented out.
ConfigFox doesn’t add anything to prefs.js. Firefox does!
When you start Firefox it literally copies (and overwrites) all your uncommented entries from user.js to prefs.js
And those copied entries will stay there “forever” even if you delete your user.js.
Do you doubt?
Try it! You’ll see.
Idea – you could incorporate [tag][/tag] fields .. such as
[tag]Firefox Options, Palemoon, Common Troubleshooting[/tag] (i.e enable parsing multiple tags per line item) and then you can allow things like
View>Tags>Firefox Options or View>Tags>Palemoon (or better yet enable a treeview by tags)
Also, if you use [p][/p] and [url[/url] etc to hold ALL information, you can not only display this per item as needed, but also display a single sheet with all titles/info/hyperlinks – searchable too
I also kinda really want the user interface to have more panels – the left panel would hold “info” All, categories, tags (populated by parsing [tag]), search (results) new (green?), custom (purple) etc. When selecting “info” this would display the commented stuff about the user.js. Otherwise you could select all, or a section and so on. If you search it jumps to the search section so you see everything in one hit. The info panel would collate and display all the corresponding stuff in any given point – eg if on a tag for palemoon – the info panel would display all the [p] and [url] etc for all llien items tagged palemoon. This approach allows for a much more informational and easier to use tool IMO. Most of us using this tool are on widescreens – build some width into this thing – expand to more panels, enlarge and enhance the information section – build in tagging – then I could easily whip up the bees knees – the Pants Ultimate ConfigFox js
———————————————————————–
—Info——- |
ALL | -Subject | Info panel
Startup |– item |
Auto-Update |– item |
Privacy |
—
Search
—
New Items
Your Items
—
—tags—– |
Palemoon |
Anyway, it’s not my project. But as it stands I can’t use this to open and edit standalone js files – it only wants to f**k with my profile one :) – i want to just browse/open/edit/save any configfox compliant js file or create one from scratch and save it without having to detect or use a profile folder. I also just haven’t had the time to use it. I’ve looked at version 1 for about 10 minutes, that’s it. I also would want the ability to point to a different default.js (eg Pants.js) and for updates to not overwrite it – only to update the default.js.
Dude, I ackowledge you for gathering the list. I really appreciate that.
But I don’t like your bad mood. If you don’t like ConfigFox just don’t use it.
I spent more than 80 hours writing it from the scrap. All for free and clean.
If you think ConfigFox “f***” your profile than just go back editing manually and forget about ConfigFox.
I didn’t write ConfigFox for 10 security-paranoid-users. I’m writing it to the whole community. Free, Open source, nice and clean.
I agree there are some things must be done yet. But your attitude dusgust me!
Yeah right, I wrote ConfigFox to “f***” your profile. Leave it alone and go back editing with notepad.
You should learn more about user.js and prefs.js before get that critical.
” it only wants to f**k with my profile one :)”
Note the smiley … and that’s slang for “mess with”, “tinker with”, as stated in the context of the sentence.
Rephrased:
“But as it stands I can’t use this to open and edit standalone js files – it only wants to tinker with my profile one :)”
Thanks for the review Martin!
It would be hard to tell appart user’s prefs from Firefox’ prefs. I would have to dedicate some extra time tracking Firefox changes.
I put on this new concept of highlighting in purple items that ConfigFox doesn’t have in its collection for two reasons:
– so the user can control which settings are of his own.
– so the user can be aware of settings that were removed from ConfigFox (eg.: deprecated features due to new Firefox releases).
Here is one thing I can do if it is of any help. In menu “View > Highlight non-collection entries”. So the user can check/uncheck that option.
The other issue, the new policy of not collecting (default.js) items that can be set from Firefox itself.
I saw it coming, some users, specially the advanced ones :) would like ConfigFox collection to be comprehensive regardless of Firefox.
There are other kind of users that got confused and prefered the opposite.
For example, cookies preferences. Why I removed it from the collection? Because it can be set it from Firefox.
If ConfigFox have that entry in its collection, regardless of what the user set in Firefox preferences, ConfigFox would run over that.
For example: (version 1.0)
// user_pref(“network.cookie.cookieBehavior”, “”);
If ConfigFox read this item unchecked (commented) in user.js it would remove that from prefs.js regardless if the user have set it from Firefox or not.
In other words, ConfigFox could not tell who wrote user_pref(“network.cookie.cookieBehavior”, “”); in prefs.js (Firefox or ConfigFox?) So ConfigFox would have that preference removed because it is unchecked in user.js.
But, To keep everyone happy, one can add/remove/edit any entry in the collection or user.js. Hence the purple highlight.
This new tool called “Dummy files” http://configfox.sourceforge.net/images/s08.png also gives a boost to privacy and performance.
For example: (version 1.0)
// user_pref(“network.cookie.cookieBehavior”, “”);
If ConfigFox read this item unchecked (commented) in user.js it would remove that from prefs.js regardless if the user have set it from Firefox or not.
^^^ So are you telling me that you REMOVE items from prefs.js? I was of the belief that this tool only creates and edits user.js files and the actual changes in prefs.js is handled by Firefox itself on startup. You shouldn’t be directly messing around in the prefs.js and you certainly shouldn’t be removing any.
Just please confim that ConfigFox does not directly edit the prefs.js file in any way – thanks.
——–
“Firefox and ConfigFox are both changing prefs.js. How can you tell if a entry there comes from one or another?
See the confusion?”
^^^ There is no confusion. It’s extremely simple. User.js overrides everything else. Those people who can’t follow that are idiots and you shouldn’t be pandering to idiots and dumbing it down.
“I had some feedback from users saying that some options they had set from Firefox didn’t stick.”
^^^ Then they need to realize that the user.js is overriding it and make the change in the user.js. Don’t pander to idiots.
“It would be hard to tell appart user’s prefs from Firefox’ prefs. I would have to dedicate some extra time tracking Firefox changes.”
^^^ Indeed, you just said it yourself. Now you’ve set yourself up for more work monitoring what is and isn’t in the FF interface, let alone PM and other forks etc. Don’t pander to idiots.
[quote]
So, ConfigFox will ONLY access prefs.js in order to remove an entry that becomes commented (unchecked). Otherwise, it doesn’t matter if you comment a pref in user.js it will still remain in prefs.js.
Thus, YES. if you uncheck a preference:
user.js ——–> the preference goes commented: // user_pref(“extensions.update.enabled”, false);
prefs.js ——–> the preference line is removed.
[/quote]
No no no no no NO .. just NO.
ConfigFox should NOT EVER touch the prefs.js. It’s for handling user.js files.
If I uncheck(uncomment) a user_pref – I do not want you to then delete it – I simply no longer want the user.js to handle it. I don’t want it removed from prefs.js thereby causing it to revert to default.
Let FF itself do want it is MEANT to do – only edit/add items – not remove them.
The process is about:config is used to remove (reset)/add (custom setting) items to prefs.js. User.js overrides (it does not remove) items in prefs.js. You are circumventing the process and will cause problems. User.js is implemented on a FF start. ConfigFox should follow the same procedure and state “All changes take effect on the next FF restart” – as explained by Mozilla themselves.
Just in case you didn’t understand my question – I was asking if the ConfigFox executable DIRECTLY edits the prefs.js. I didn’t mean if it did it indirectly via the user.js being used by FF on startup. If the answer is yes, then I cannot support this. This is unexpected behaviour.
This probably explains why I had to restore a copy of my portable FF after playing with ConfigFox v1.0 for 10 minutes. I renamed my user.js to user.bak, loaded ConfigFox, allowed it to create a new user.js, played around with ticking and unticking options, and then closed it. Restored my original user.js – all while FF was open. By my understanding, nothing would have actually happened, but now I realize my prefs file was being tortured in the process. Although, on a FF restart it should have all been reset. Who knows – there were some extra new items in that default.js.
*sigh*
See for yourself, forget ConfigFox for now.
1. edit your user.js and add an entry to it:
user_pref(“my.custom.setting”, true);
2. start Firefox. then close it.
3. check your prefs.js and see that user_pref(“my.custom.setting”, true) is there!
4. remove or comment that entry on USER.JS:
// user_pref(“my.custom.setting”, true);
5. save your user.js
6. start Firefox. then close it.
Now, if you check PREFS.JS you will see that user_pref(“my.custom.setting”, true) STILL THERE;
Holly molly!
True: Firefox override any setting in prefs.js with the one in user.js
———–> FALSE: if I comment a line in user.js then Firefox will also comment/remove that line from prefs.js
I’m trying to answer but the website is not showing it:
From the ConfigFox website:
Say you manually added a new preferernce to your user.js:
user_pref(“extensions.update.enabled”, false);
When Firefox is launched it will copy that entry to prefs.js.
Later, if you change your mind and want to remove that preference, you would have to edit both user.js and prefs.js and remove that entry from both files. Editing via about:config and reseting extensions.update.enabled to default would not work since that entry is still in user.js
ConfigFox will do all that work for you making sure only checked entries get effective. So, although you can keep a backup of user.js and prefs.js it is not necessary.
————————–
So, ConfigFox will ONLY access prefs.js in order to remove an entry that becomes commented (unchecked). Otherwise, it doesn’t matter if you comment a pref in user.js it will still remain in prefs.js.
Thus, YES. if you uncheck a preference:
user.js ——–> the preference goes commented: // user_pref(“extensions.update.enabled”, false);
prefs.js ——–> the preference line is removed.
From the ConfigFox website:
Say you manually added a new preferernce to your user.js:
user_pref(“extensions.update.enabled”, false);
When Firefox is launched it will copy that entry to prefs.js.
Later, if you change your mind and want to remove that preference, you would have to edit both user.js and prefs.js and remove that entry from both files. Editing via about:config and reseting extensions.update.enabled to default would not work since that entry is still in user.js
ConfigFox will do all that work for you making sure only checked entries get effective. So, although you can keep a backup of user.js and prefs.js it is not necessary.
————————–
So, ConfigFox will ONLY access prefs.js in order to remove an entry that becomes commented (unchecked). Otherwise, it doesn’t matter if you comment a pref in user.js it will still remain in prefs.js.
Thus, YES. if you uncheck a preference:
user.js ——–> the preference goes commented: // user_pref(“extensions.update.enabled”, false);
prefs.js ——–> the preference line is removed.
Personally – I can handle my own default.js, but this obsession of dividing what FF allows via an options interface vs “hidden” prefs is ridiculous. The purpose of a user.js is for a central point/repository of settings for enforcement and portability. It’s also about security/privacy/etc – and by removing some of these preferences, you are not providing a complete list – so it’s misleading in that regard.
I will be sending Martin my latest user.js (yeah, lets call it version 7) which will be configfox compliant. It will be based on my original categories. Example “signon.autofillForms” makes sense (to me) to be lumped with items that are stored such as locations/search/forms+history/suggestions (these are all logically interactive with one another) – but you moved it down to a “Leaks, fingerprinting, security, dev tools”. Everything here is about privacy/security/leaks. It makes no sense. And without going through everything, a lot of comments seem to be missing – stuff which explains what that preference does and what it can affect. I went to a lot of trouble to explain things – such as turning off auto updates, and now it’s all gone in the default. I strongly believe that the display of info about a section, sub-section, or entry needs to be more prominent – like a side panel, that as you mouse/move/select up/down ANY line in the main window, the info is displayed prominently – using a bigger space allows for more detailed info, and you could parse for any urls and make them hyper
I still want a compatibility/troubleshooting/warning flag to mark entries. Namely prefs that can break sites – just use some trigger for parsing (I have suggested “/* warning” ) such as indexeddb, the three pushstates for history, and at least another couple of serious ones. Without those, a lot of people will implement this and then scream when youtube or gmail or something breaks. I originally thought color was a way to do this, but now I think an icon is better so it doesn’t interfere with your existing scheme
SSL / OCSP / CERTS / ENCRYPTION
— [red warning icon or orange troubleshooting icon] require certificate revocation check through OCSP protocol
—– security.OCSP.require
Something like that
PS: If you have a dedicated prominent section to properly display paragraphs etc of information
/* Config File generated by ConfigFox */
/* [p]blah blah[/p] [p]paragraph two[/p] */
/* [link]http etc[/link] [link]http link 2[/link] */ (you could parse all links under “References” in a bulleted format)
// Auto Updates
/* [p]It is still important to do updates for security reasons. If you don’t auto update, make sure you do manually[/p] */
// user_pref(“plugins.update.notifyUser”, false); // disable update plugin notifications
/* warning
/* [p]This will break mozilla’s built in plugin update check, which only checks a few plugins anyway – these plugin updates can be handled by the plugins themselves – Java, Adobe Flash etc system auto update etc etc etc blah blah blah[/p] */
etc
didn’t mean to ramble, but there needs to be a better mechanism for a lot more information to be elegantly displayed
You have some good suggestions there Pants. I’ve noted them to a to-do list. I can’t promise all for the next version though as it demands some time. I have other projects I’m working on.
Thanks
The purpose of ConfigFox is that users can select WHICH preferences they want to apply.
If a user wants the WHOLE Pants’ collection to get applied without exceptions then ConfigFox is useless. In that case just copy that full collection to user.js and that’s it.
The idea is to provide advanced options that Firefox itself does not offer to the users in its regular “preferences”.
Adding options that Firefox already offers itself will confuse the users.
I had some feedback from users saying that some options they had set from Firefox didn’t stick.
Firefox and ConfigFox are both changing prefs.js. How can you tell if a entry there comes from one or another?
See the confusion?
For users who prefer the old behavior and want the whole collection and not use the purple highlight:
> Replace default.js in ConfigFox folder with your full collection (from version 1.0).
There you go! No purple items. Full collection!
But then be aware: if you click File > Update Collection default.js will be replaced with the ConfigFox standard’s (with new entries, if any).
So I just tested it and it tells me I don’t have a user.js – this is true.
But all my settings (and the ones you change via about:config) are in the prefs.js.
So how do those two files differ and if a value is in both, what setting would overwrite the other?
EDIT:
Nevermind.
http://kb.mozillazine.org/User.js_file
—
But it would be good, if your program reads the setting from prefs.js. I already set a lot of stuff manually and it would be nice to see it and get those values.
It reads the existing user.js, if there is none, then it will read the default.js in the ConfigFox directory, which contains all the settings and the best settings for each pref so all you need do it tick it. It’s pointless to read from the prefs.js as essentially everything in there that is in the default.js is by default the opposite of what is trying to be achieved. Read that last sentence again, slowly.
Just do the migration to a user.js – this makes it enforceable, portable, and a separate location of concise/specific changes. That last part just highlights the pain in the ass it is following/checking/maintaining all your custom changes in about:config.
Pants just proved what howtogeek has always said. By reading Pants comments and the fact that it’s still up, ghacks is a shitty washed up site that begs for money. There was a reason it was at the bottom of my bookmarks list, and now it’s removed.
“my prefs.js is 738 lines”
Don’t confuse all the addon preferences with FF’s ones. My prefs.js is 716 lines with 706 user_prefs – but a lot of that is preferences used by extensions or machine/browser specific settings eg
user_pref(“noscript.version”, “2.6.9.39”);
user_pref(“noscript.visibleUIChecked”, true);
“my prefs.js is 738 lines” – FFS, we’re not talking about prefs.js – we’re talking about user.js. Lines is irrelevant – it’s user_pref entries. My user.js is 544 lines longs with 265 user_prefs. I mentioned my count because it was/is the original js that started this whole thing and I’m highlighting the descrepancy for other readers.
“The program should just take the existing values from the prefs.js and write them into the user.js”
– If no user.js is found then the default.js should be used – as the default.js can be updated and is maintained on the internet and is a “best practice” – it’s the central point (YOUR firefox profile is not). The purpose of a user.js is to write to the prefs.js – not the other way round.
“Why should I do work, that a computer can do?”
– so a computer did all your “customized” about:config entries? If you set up a new firefox from scratch (let’s say your profile is corrupted or your laptop was stolen and you had no backup, or you setup a fork and can;t mix profiles without issues or whatever) – so you’ll do all that customization again? Everything you have done to this point was customized (that is by you), as you read about tweaks and hidden settings and so on. Just bite the f***ing bullet and grow some balls and migrate all this s**t to a user.js and stop bitching and moaning like a schoolgirl. If you want your own user.js, you’re going to have to check it all anyway.
> Any new custom preference in future can be added to your user.js – that is – change in about:config if you want to, to see if the value exists, test it or whatever AND add it to the user.js for future proofing.
Why should I do work, that a computer can do?
The program should just take the existing values from the prefs.js and write them into the user.js. That’s all I’m asking for.
> umm .. it’s more like 210 prefs (mine is more like 265)
Good for you, my prefs.js is 738 lines long. Now I have to check them for addon preferences and FF preferences (they are mixed, I already took a look) and manually copy the lines I need – see above.
Ben .. what part of portable don’t you understand. The user.js file can be copied/put into any profile folder. It’s a container for preferences you want to over-ride. Any new custom preference in future can be added to your user.js – that is – change in about:config if you want to, to see if the value exists, test it or whatever AND add it to the user.js for future proofing
If you don’t understand the concept of a user.js (which OVERWRITES those preferences in prefs.js on a FF start), then I don’t know what to tell you
“So I (everyone) can now do all the sorting and copying through a >700 lines user.js manually”
^^ umm .. it’s more like 210 prefs (mine is more like 265). And those provided by Leandro are a far better star point than doing it from scratch. Anyone who wants to make use of a user.js is going to have to do it somehow – and manually checking, reading and deciding on each pref (or group) is fully advisable. If you don’t understand that a tool like ConfigFox makes it easier, then .. again .. I don’t know what to tell you (well, I do, but not here!)
> Just do the migration to a user.js – this makes it enforceable, portable, and a separate location of concise/specific changes.
Yes, but normally you change stuff in about:config and this will be written to prefs.js. So this is the way things are on nearly every PCs where settings were changed.
So I (everyone) can now do all the sorting and copying through a >700 lines user.js manually, or the program that should make stuff easier could do all this in <1 ms. I like outsourcing unnecessary work to the computer :)
Ben, months ago I also did my custom settings like that, using prefs.js. Then I got to know that using user.js instead is a better choice for this exacly your question: you can separate your custom settings from Firefox’ prefs.js.
Back then what I did was quickly go through prefs.js and copy my custom settings to user.js.
Thanks Leandro and any others who contributed to this. Very useful.
As I see it for now Pants’ work that I discovered here at https://www.ghacks.net/2015/08/18/a-comprehensive-list-of-firefox-privacy-and-security-settings/ allowed me,
1- to discover new privacy-security settings available via Firefox’s about:config ;
2- to assemble these new settings together with those I already had and to clean up, organize all these settings within topics clearly identified in my user.js file. More data there is more it needs to be neatly referred.
ConfigFox is great for anyone starting, discovering all settings available and avoids the hassle of building their user.js file anarchically. Personally I prefer to anchor myself to a work which calls my attention on each and every setting I enable or disable, knowing exactly what is performed in every case. Now that these settings have been categorized (thanks again to Pants approach for the container (its organization) and his contribution to the data, if/when new settings arise my user.js file will be able to set them in the adequate topic. I wish not to be in whatever way limited by the boundaries of an external app.
Very useful utility. Many thanks to Leandro for continued work on this. I do agree with Martin and Pants that it would be more convenient to have all preferences in one place here and perhaps just highlight or warn of prefs that are otherwise available through FF options (I don’t use standard FF, anyway, but Cyberfox x64 and Pale Moon x64, so options available through the browser interface differ).
“has been stripped of entries that are found in Firefox’s option’s interface”
Wot? Part of the reason for a user.js is portability, another is enforcement – if the option is available via FF’s own options interface, that is totally irrelevant