The storage is more limited for synced extension data than for unsynced data.
IMO this is quite unfortunate, and is mostly a consequence of the implementation of extension storage sync being done separately from the rest of sync (which in retrospect was a mistake, but at the time that wasn't clear). Also, the limits are copy-pasted directly from the limits chrome places on sync, so it's possible there are compatibility concerns as well.
For config (assuming you mean prefs in about:config), you can add your own prefs to be synced with about:config. If you add a new boolean pref with a value of true using the pattern `services.sync.prefs.sync.<pref you want to sync here>` it will be synced. e.g. to sync `browser.foo.bar` you'd create `services.sync.prefs.sync.browser.foo.bar`.
Disclaimer: I work on Firefox sync.
[0]: In the future this may be more complex, and you may need to flip an additional pref to get this behavior for non-default prefs.
> For config (assuming you mean prefs in about:config)
And userChrome/Content.css... looks like I’ll need to dropbox those.
Editing css was essential to make the switch from Vivaldi to FF - yesterday! Getting TreestyleTab et al. to feel like Vivaldi with vertical tabs required some fiddling: sidebar without menu, hidden top tabs, darker text color, etc.
In any case, it’s my new daily driver and I'm quite satisfied so far. Even set DDG as the default while at it.
Hmm, I don't think many have requested we sync user{Chrome,Content}.css. It's possible we'd accept a patch to sync them (I'd be for it, at least), but it's not trivial since we don't already have file syncing code.
Syncing them with dropbox and symlinking does sound to me to be the most reasonable.
I just assumed that this behavior would apply to everything once I turned sync on, and then was disappointed when it didn’t work. I had no idea it was an optional feature.
I guess it doesn’t fit the key-value paradigm, but this feature would be a lot more discoverable if there was a “sync?” Attribute next to each about:config item.
Being a global persisted key value store, about:config has a lot of things stored in it that.... do not necessarily make sense syncing, hence it being opt-in. Sync is guilty of this too, and will store things like your last sync time in about config, for example. Clearly not meaningful to sync directly.
A checkbox like you describe was actually discussed in the past, but at this point it’s unlikely. The current design of letting any synced machine change any pref on any remote machine (effectively) has dubious security implications, and has gained an additional hoop you must jump through in nightly.
For about:config, I put all my rules in a user.js file. Make that file in a synced folder (Dropbox, Nextcloud, Syncthing, etc.), go to your FF profile folder, and in there make a symlink to the actual synced user.js.
> For about:config, I put all my rules in a user.js file. Make that file in a synced folder (Dropbox, Nextcloud, Syncthing, etc.), go to your FF profile folder, and in there make a symlink to the actual synced user.js.
That's exactly what I did, except I just forked the ghacks-user.js user.js file with the changes I needed
I then made a desktop branch, and an android branch.
The main reason I'll never use Chrome is because on Android that means no extensions whatsoever, meaning I'd have to give up uBlock and uMatrix. It's also why I wouldn't buy an iPhone (Firefox on iOS isn't allowed to have extensions).
On my desktop I have it hooked in with my bootstrap script. I use Yadm https://yadm.io/
#!/usr/bin/env bash
firefox() {
local -n branches=$1
local b p d="$XDG_CONFIG_HOME"/firefox/ghacks-user.js
for p in "${!branches[@]}"
do
b=${branches["$p"]}
printf 'Configuring "%s" on "%s"\n' "$p" "$b"
ln -sf "$XDG_CONFIG_HOME"/firefox/chrome/userChrome.css ~/.mozilla/firefox/"$p"/chrome/userChrome.css
git --git-dir="$d/.git" --work-tree="$d" checkout "$b" &&
cp "$d/user.js" ~/.mozilla/firefox/"$p"/user.js
done
}
The function takes in an array:
firefox_data_path="mozilla/firefox.json"
declare -A fx_profiles
while read -r profile; read -r branch; do
fx_profiles[$profile]=$branch
done < <(jq -r '.[] | .profile, .branch' "$template_data_path/$firefox_data_path")
firefox fx_profiles
Which simply reads in a bunch of profiles and what branch they are supposed to be from a json file:
