I don’t think Firefox Color can do that. At best you could test and set colors using Color, and then export the settings for both as a theme .zip or .xpi files, and then combine the two to a single manifest.json file. Inside the manifest, a "theme" key would be color properties for “normal” theme and "dark_theme" would be for dark-theme. After that you would submit the theme package to get it signed after which it can be installed as a real theme.
You can modify prefs at runtime and have them persist - except those prefs that are also declared in user.js. The problem arises when folks apply whole list of prefs via user.js from one repository or another, which could be hundreds, without acknowledging what prefs they set and without checking what those prefs do. If they then have some reason to change any one of those prefs - their change won’t persist if that particular pref is in user.js
A thing you could do is to just start Firefox once with a user.js file, and then remove that file. On that single startup Firefox sets prefs according to user.js, and all those changes persist to prefs.js when Firefox is shutdown. You are then able to also persist changes to all prefs because by removing user.js Firefox won’t try to override the your session saved prefs with user.js at startup.
Yes. Firefox doesn’t create user.js file itself - if you want one then you need to create it yourself either manually or with some tool. Also, I’ve seen some “security” software create user.js file without notifying the user about it…
What I’m trying to point out here, is that prefs declared in user.js (whether they are put there using scripting or otherwise) cannot be persistently modified at runtime from within Firefox. That may or may not be a huge problem, but something to be aware of.
Sure. For simplified example have only the following in your user.js file:
user_pref("browser.tabs.warnOnClose",true);
Confirm before closing multiple tabs is checkedbrowser.tabs.warnOnClose is now falsetrueThe reason is also very simple. Firefox will never write anything to user.js - thus any changes you do at runtime will only be stored to prefs.js. However, user.js always overrides prefs.js at startup.
Yes, but that is not what I’m talking about. What I mean is that when Firefox is running and you go to change some setting in say, Settings page, then the new value for that preference is stored into prefs.js (at latest on Firefox shutdown, it might remain only in-memory for some time I’m not sure). Anyway, the new value persists only for that browser session, because on next startup whatever value was set by user.js will override it.
I don’t think that could work. Not unless we are talking about different things, or unless you run their updater script everytime before starting Firefox.
In addition, if you use user.js then you essentially cannot change those settings at runtime (via about:config or otherwise), because your user.js will override the settings on next startup. Maybe that’s desired for some, but good to keep in mind nonetheless.
Yeah… It’s a bit hard to balance things like this though, I’ve seen lot’s of folks complain about how their Firefox is apparently “broken” because it now suddenly has this empty margin around web-content seemingly wasting space for no reason - and then it turns out that they have deliberately turned this very feature on. And that is even if the feature is completely hidden - I wonder how many more complaints there would be if options like this are made more accessible.
The letterboxing feature has been in Firefox since 2019 - starting from Firefox 67 I think. The preference for it might have been hidden though so maybe it’s just relatively unknown feature - I don’t know if or how visible LibreWolf makes makes it for the user. But regardless, any modern Firefox variant probably has that capability.
Sounds like you are talking about Firefox’s letterboxing feature which you can enable/disable independently from full fingerprinting resistance.
I’m not sure if resistFingerprinting does anything to stop websites from uploading whatever data they can get though, I don’t think it does that. And I don’t think it could really do that in the first place since the website could just obfuscate the data and browser wouldn’t know what is sent.
You’ll be styling another element, that’s really all it is.
Normally Firefox applies various styling rules to the element with id urlbar-background - so it makes sense to also apply your custom style rules and overrides to it. If you apply your background-color or border or other rules to some other element such as #urlbar-input-container then the original styling of #urlbar-background still applies as well.
This would then cause issue like you would see in your first image, exactly like you guessed; the outline of #urlbar-background is seen behind the background-color of #urlbar-input-container because the two boxes don’t have exactly the same shape and thus you are not fully covering the urlbar-background.
If you aren’t doing anything else to urlbar then I’d recommend styling #urlbar-background instead of #urlbar-input-container - like this:
#urlbar-background {
border: none !important;
border-radius: 5px !important;
background: light-dark(#ffffffff, #1b1e20ff) !important;
outline: none !important;
}
That’s not necessarily a good solution either, because a service could figure out that the source of random fingerprint data likely comes from the same user. Especially if your ip is not changing. It might perhaps be effective if a substantial amount of people were doing it though.
But to generate such random fingerprint is difficult because it consists of many parts and services don’t all build fingerprints the aame way. You could easily randomize e.g. canvas data, but the issue is that if you only randomize one data point then that one random data point pretty uniquely identifies you if your other datapoints are stable. So to be effective you would really need to randomize several different datapoints and that may not be such an easy task since websites could build them in all sorts of ways.
You can change it like this with userContent.css:
@-moz-document url("about:newtab"), url("about:home"){
:root{
--newtab-primary-action-background: #f00 !important;
}
}
That way you can specify a color for them, but setting the value to AccentColor may or may not resolve to the actual system accent color.
Yeah, regular http cache is indeed a thing. However it’s more complicated because the web server can tell the browser how the returned content should be cached - if at all. So if, say, reddit servers ask the browser to not cache particular resource (for whatever reason) then it won’t be cached. I mean, the browser is free to do as it pleases, but I think in general browsers would do as the server asked and indeed not cache it.
Is your style up-to-date? This sort of sounds like issue #359 but that should have been fixed 2 months ago.
Well the feature development is certainly progressing - here is the tracking bug for it.
You can nowadays just test it in normal nightly without special build - it’s extremely incomplete, but you can test it if you wish. It’s tied to revorked sidebar which you need to enable in about:config.
I suspect that the cause is from bug 1897477 - whereas previously your script overrode the original command ctrl+f event callback, with this change both callbacks happen. So when findbar is already shown, your script will hide it, but then the original Firefox function shows it again.
You can probably change the last part to be like this instead (I don’t really get what the middle part is supposed to do, but meh):
(function() { document.getElementById("cmd_find").addEventListener("command",(ev) => { ucjsToggleFindBar(); ev.stopPropagation(); }, { capture: true }) })();