discussion: move section 5000 (personal) to a separate js file

[Thorin-Oakenpants]

snip

[2glops]

It sounds logical to move all personal settings away from user.js.
My "overrides.js" already contains such prefs.

[overdodactyl]

Sounds like a reasonable idea to me.

We could account for this in the updater scripts as well if desired. (if user-personal.js file exists, create a backup, download the new one, append to user.js)...this would keep the automation of updating things provided here, while keeping user-overrides.js for changes not "endorsed" in your repo

Edit: probably don't even need to back up as this would be included in the user.js backup

[overdodactyl]

^^ That method would require the user to initially have downloaded the user-personal.js file. The other option would be to provide a prompt each time asking, but from a personal standpoint, I would rather not see an additional prompt every time the script is run and manually download user-personal.js initially

[overdodactyl]

Obviously up to you, but I would consider a couple line if statement much simpler than reviewing changlelogs and manually adding, removing or adjusting preferences - or at the very least, less tedious, time consuming and error prone - which was part of what the updater script were aimed to eliminate. If you're going to maintain a separate .js file in this repo, why not leverage the already available scripts to make it easy to use and keep up with?

[overdodactyl]

I'd be more than happy to update .sh file. I know clasutro's grew to be a little more complicated, so perhaps it's not as easy of an addition (haven't looked at it super recently)...so perhaps we should wait to see what he says about it before roping him into more work haha

[overdodactyl]

If you choose to go this route, I've made the necessary changes to updater.sh. Just would need the file name and url and I can submit a PR :)

No hard feelings if you don't want this included though Pants...I'll just keep the script for my personal use haha

[grauenwolfe]

Here's my take on it. Yes, it's clearly labelled as PERSONAL SETTINGS and should be understood as such. It's essentially impossible to cover all bases when dealing with ignorance / laziness on the part of other people using something whether it's the ghacksuser.js or whatever else it may be.

Being that it is clearly labelled as PERSONAL, it's never bothered me but I don't think it's necessary and have always ignored it's entires.

The effort is greatly appreciated but my final verdict is to get rid of it, at least from the user.js.

[earthlng]

I don't like the idea tbh. If this is mainly about ui.submenuDelay I'd rather just make that inactive.
IMO 5000 is a neat little appendix to enhance the general "Firefox experience". As @grauenwolfe said, nobody is bothered by having that little bit extra at the very end of the file. But I think if you would get rid of it entirely you would start to notice a lot of little annoyances in Firefox. For example I saw a comment on reddit once where someone said he wished he had known about browser.urlbar.clickSelectsAll years ago. Similarly IMHO general.warnOnAboutConfig absolutely belongs in any extended user.js.
And then there's also the issue that some users are already overwhelmed with just having to deal with 1 file.
So IMO either we deem them not interesting enough and remove them entirely or we keep it as it is.
We can reorganize it a bit which is something I wanted to do for some time now but never brought it up. For example move warnOnAboutConfig to 0000, 5002 fits better right next to 2418 (where we could also add ("full-screen-api.transition-duration.enter", "0 0"), and maybe most importantly group all the Tabs Behaviour stuff nicely together. That's actually one of the few remaining parts that I never got around to adjust to this user.js and still kept the old [removed] format because I just like it better that way:

//// === TABS === ////

user_pref("browser.link.open_newwindow", 3);                    // [integer] controls when a new window/tab should be opened - 1=open links that open in a new window in the current tab, 2=open links that open in a new window in a new window, 3=open links that open in a new window in a new tab in the current window
user_pref("browser.link.open_newwindow.restriction", 0);        // [integer] controls when a new window/tab should be opened - 0=divert all links according to browser.link.open_newwindow, 1=do not divert any links, 2=divert all links according to browser.link.open_newwindow, unless the new window specifies how it should be displayed
user_pref("browser.link.open_newwindow.override.external", 3);  // [integer] open links from external programs in: -1=default, 1=the current tab, 2=a new window, 3=a new tab

user_pref("browser.tabs.closeWindowWithLastTab", true);         // [boolean] whether to exit FF when closing last tab
user_pref("browser.tabs.insertRelatedAfterCurrent", true); // open links in a new tab immediately to the right of parent tab, not far right
user_pref("browser.tabs.loadDivertedInBackground", false);      // [boolean] cause links opened from external programs to open in a new background tab
user_pref("browser.tabs.loadInBackground", true);               // [boolean] focus new tabs instead of loading them in the background
user_pref("browser.tabs.selectOwnerOnClose", true);             // [boolean] focus the parent tab when a child tab is closed
user_pref("browser.tabs.warnOnClose", false);                   // [boolean] disable warning when closing multiple tabs
user_pref("browser.tabs.warnOnCloseOtherTabs", true);          // [boolean] disable warning when closing other tabs
user_pref("browser.tabs.warnOnOpen", true);                    // [boolean] disable warning when opening too many tabs

EDIT: Oh yeah I forgot to say: FUCK CHEF-KOCH !!!

[smithfred]

But I think if you would get rid of it entirely you would start to notice a lot of little annoyances in Firefox. For example I saw a comment on reddit once where someone said he wished he had known about browser.urlbar.clickSelectsAll years ago.

This is an argument for having them documented somewhere on the project, yes - whether in the user.js file, or elsewhere if there is a performance impact.

What it doesn't really justify though is having the settings active. While 95% of them are actually settings I'd already customised the same way (so having them active benefits me), I think it makes more sense to have them inactive, and keep the active settings focused on privacy/security.

[claustromaniac]

/*** 5000: PERSONAL SETTINGS [SETUP]
Settings that are handy to migrate and/or are not in the Options interface. Users
can put their own non-security/privacy/fingerprinting/tracking stuff here ***/

By the given definition, I think the items in section 5000 are of the sort the user-overrides.js is there for nowadays.

We're facing, broadly, two usage scenarios: the user manually downloads and edits user.js directly, or the user uses the updater scripts. Talking strictly about convenience, for the first sort of user having all the settings in a single file would be better, even if that section was inactive by default. For the second sort of user, it should be OK either way because if we modify the scripts so they can manage both files, all settings will end up in user.js anyway.

If we wanted to prioritise convenience, we should leave those items in the same file, but maybe we should still reorder them and rename the section. If we wanted the project to focus more on its main scope instead (privacy and security), we should move those items to a separate file. Then, there is the middle ground that @smithfred bitched about suggested originally: leaving the section in that file, but making it inactive by default.

If you ask me, I see them all as valid routes. I would personally prefer that the section was moved to a separate user-misc.js file, or something like that, but I don't think of it as being a generally better idea than any of the other options.

[nostromov]

What I don't get is how come that general.warnOnAboutConfig has been moved from the /*** 5000: PERSONAL SETTINGS [SETUP] section, where all of the other settings remain (for the time being?) and given its own (top) section: /* 0000: disable about:config warning ***/

Edit: Ok, I mean - I get it, in preparation (of the upcoming changes) or something; but, without anything being clearly decided (yet?!), it makes a bit of a mess when manually editing the new file(s); like with diff-compare, or whatever. :)

^^ Which I'm doing, with Notepad++, since I've not yet figured out how to do the whole script-GitHub thing (for some reason, it's (always) giving me (some) trouble on Windows, blah.)

Edit: Really, wouldn't mind some help with this!! kgbme[at]jabber[dot]org is my XMPP

P.S.
This guy, CHEF-KOCH, when is he -just- going to start giving credit to other people - where he has been using their work... It's such a simple thing to do, right?

[smithfred]

all the naysayers about having "personal" stuff in the user.js [...] can go and get f**ked.

This is not good project management.

(like CHEF-KOCH The Plagiarizer)

Logical fallacy to imply that that person's opinion is relevant either way.

It depends what ghacks-user.js is. Is it a project of "random crap that Thorin-Oakenpants likes, includes privacy stuff"? (Your prerogative if it is). Or is it "this will secure and increase the privacy of Firefox, and is intended for public consumption and contribution"?

[smithfred]

I'm going to contend that a better approach would be to modularise this (with a "build" script if necessary).

e.g. "build --shouldersurfing --localaccess --tracking-paranoid --hacking-medium --ux"

Then make the project e.g.:

user-shouldersurfing-minimal.js
user-shouldersurfing-medium.js
user-shouldersurfing-paranoid.js
user-tracking-...

etc.

And you can still include a user.js file, that's just the result of 'build --kitchensink' or whatever, so the build script isn't necessary if someone wants to keep the defaults.

The build script can be trivial (so it's easily user-auditable) too.

[smithfred]

Well the appearance stuff at least can be spun out and then if there are other similarly clearly delineated groups the same could be applied.

As per the prev. comment the separate files could be pre-combined into a default user.js for continued "get and forget" use.

Is there anything that ties the personal section to the rest of the file? Is it actually part of the hot mess?

Otherwise, you have two distinct parts:

All other sections: tangled hot mess: security/privacy focus
Personal section: logically separate, subjective UX taste

It makes more sense to me to keep it all in the one file: easier for end users (lowest common denominators and all that)

The file pretty much requires the user knows what they're doing, since it fundamentally changes the basics/semantics of Firefox browsing in ways that will burn the user if they don't read anything and just blindly chuck it in their profile - e.g. clearing history entirely on exit.

[claustromaniac]

...

If I were to script something like that I think I would add tags to every item instead of putting them in separate files. The script could then decide what to ditch and what to keep based on those tags and user preference.

It would be far from trivial, though. I'm not known for writing audit-friendly code. @earthlng knows this first-hand.

Well, actually, I'm not really known for anything at all.

...

Just ignore this comment.

[smithfred]

That is such a disgusting sentence, but I get your drift, phrasing it that way to emphasize your point.

Yep, hyperbole for effect. I wouldn't go so far as to call it "disgusting" ;)

No. None of it is directly concerned with the "mission statement" in the readme.md

OK, what it comes down to for me is, if a project has a clear focus, and defined intentions/goals, which are applied reasonably consistently, then it makes contributing to the project appealing.

OTOH, if it looks like there are things like a lack of focus, inconsistent adherence to stated project mission/scope, or dictatorial decision-making, contribution becomes less appealing.

To be clear, it's entirely up to a project owner how they want to run their project and I mean that sincerely - you don't owe anything to anyone and have obviously already contributed a great deal to Firefox users with this.

The difference that different approaches to managing things make to how much outside contribution may also be negligible and/or not matter for you, which is also fine. But it's worth being aware of it at least.

I'd look at it as, "how can we make a secure and privacy-respecting browsing experience as easy and robust as possible", and "how can the community desire for this be organised/focused to push Mozilla to prioritise this goal upstream".

A consistent, focused, well-managed project would have a lot more weight in trying to get upstream to make useful changes to compliment (or obsolete) this work.