Best way to keep user.js up to date, when you also have modifications?

[nodiscc]

Also discussed in #502, #482

Current way, using git

• create a new branch (eg. git checkout -b mymodifications)
• add your changes, commit (eg `git add user.js; git commit -m "change setting xyz")
• on a regular basis update the master branch from pyllyukko/user.js (git checkout master; git pull), and merge the updates to your custom branch (git checkout mymodifications; git merge master)

But this requires some knowledge of git, and the history tends to get quite unreadable over time (unless you also know how to use git rebase). Another disadvantage is that your custom branch needs manual maintenance/regular merging and sometimes conflict resolution.

Proposed solution

To make maintenance of custom configurations easier (or relaxed/altered versions like the relaxed branch of this repo), we could concatenate a custom.js file to the base user.js (easily automatable using the Makefile and cat). For example:

---

Customizing user.js

To make updates easier through a simple git pull or download of the newest file, it is not recommended to write your changes directly to user.js. Instead, create custom.js:

// example
// re-enable clipboard manipulation features, we want to be able to copy-paste from XYZ application
user_pref("dom.event.clipboardevents.enabled",			true);
// re-enable webrtc/video conferencing features, we want to be able to use XYZ conference
user_pref("media.peerconnection.enabled",			true);
user_pref("media.navigator.enabled",				true);
user_pref("media.navigator.video.enabled",			true);
user_pref("media.getusermedia.screensharing.enabled",		true);
user_pref("media.getusermedia.audiocapture.enabled",		true);
// Disable permanent private browsing, we want to keep history and caches
user_pref("browser.privatebrowsing.autostart",			true);
...

• run make from the user.js directory
• A file named final_user.js is created containing the base settings + your overrides.
• Copy final_user.js to user.js in your profile directory
  • (or the final file name could be user.js to make it simpler, but then we have to rename the base file)

If a preference appears both in the base file, and your custom file, your custom value will take precedence when loaded by Firefox.

If you don't have make available, manually concatenate user.js and custom.js in a text editor, and save the result to as user.js in your profile directory.

---

Advantages

• There is no risk of conflict between your customizations and the upstream pyllyukko/user.js/user.js
• Deviations from the strict/hardened baseline are clearly indicated in a separate file
• We can move back the relaxed branch changes to an example custom file in the main branch
• People who want to keep using git to maintain customizations in the old fashion can still do it. And/or commit their custom.js
• Similar to how prefs loading logic works in Firefox.

Disadvantages

• none?

[Kakadu]

@nodiscc We can make a stronger change that splits user.js into categories and allows to override settings in per-category manner. The final user.js will be constructed from partial settings and custom 'override' scripts via Makefile. I made it for myself, diff of Makefile looks like this:

diff --git a/Makefile b/Makefile
index ec68613..05918bc 100644
--- a/Makefile
+++ b/Makefile
@@ -118,3 +118,42 @@ toc:
        anchor=$$(echo "$$line" | tr '[:upper:]' '[:lower:]' | sed 's/ /-/g' | sed 's/\?//g'); \
        echo "* [$$line](#$$anchor)"; \
        done
+
+.PHONY: user.js
+USER2_FILES=
+define PART_RULES
+.PHONY: u.$(1)
+u.$(1):
+       $$(eval USER2_FILES += $$@.js)
+user.js: u.$(1)
+endef
+PARTS=
+#PARTS=header html5 misc extensions antifeatures autoconn caching  ui cryptography cypher_suites css crandel
+PARTS+=header
+PARTS+=html5
+PARTS+=misc
+PARTS+=misc.override
+PARTS+=extensions
+PARTS+=antifeatures
+PARTS+=autoconn
+#PARTS+=caching
+PARTS+=ui
+PARTS+=ui.override
+PARTS+=cryptography
+PARTS+=cypher_suites
+PARTS+=css
+PARTS+=crandel
+
+$(foreach i,$(PARTS),$(eval $(call PART_RULES,$(i)) ) )
+#$(info $(USER2_FILES))
+
+user.js:
+       echo "" > $@
+       for number in $(USER2_FILES); do \
+               if test -f $$number; then \
+                       cat $$number >> $@; \
+                       echo "" >> $@; \
+               else \
+                       printf "Copying of $$number \x1b[1;31mskipped\x1b[0m\n"; \
+               fi \
+       done

[nodiscc]

splits user.js into categories

It will not work as some settings could fit in multiple categories. Keep it simple.

@pyllyukko would you accept a patch adding what I described?

[Kakadu]

It will not work as some settings could fit in multiple categories. Keep it simple.

I don't see a problem. It can easily support master setting and relaxed settings on top of them.

[pyllyukko]

@pyllyukko would you accept a patch adding what I described?

Sounds good. This is also unintrusive in such a way, that if you don't have/want any customizations you can keep using it as usual and nothing breaks. So it would be an additional helper for those who needed it (any maybe relaxed if we do it the same way).

The custom.js (or whatever it will be called) should also be added to gitignore.

[nodiscc]

I have been experimenting with the proposed custom.js system, a limitation is that it does not allow you to disable/remove prefs that were set in the main user.js. For example I use this in my current config:

// PREF: Disable Service Workers (disabled)
//user_pref("dom.serviceWorkers.enabled",				false); 

It does not override the uncommented, user_pref("dom.serviceWorkers.enabled", false); value in the original user.js when loaded into Firefox.

I don't want to set it explicitly to true, just use Firefox defaults for this pref.

I will keep looking

[nodiscc]

I am no longer working on this.

But this requires some knowledge of git, and the history tends to get quite unreadable over time (unless you also know how to use git rebase). Another disadvantage is that your custom branch needs manual maintenance/regular merging and sometimes conflict resolution.

I no longer see this as a problem. I have been maintaining https://github.com/nodiscc/user.js for many years with some modifications [1] on top of pllyukko/user.js, using git merge from time to time to merge upstream changes to my fork (I also maintain a Debian package for it at https://nodiscc.gitlab.io/toolbox/).