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…
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 falsetrue
The 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.
Absolutely not. If anything, public officials would be the one group whose messaging I would understand being scanned so that the people can sort of keep them on check. But again, implementing such possibility that would still weaken security of everyone else as well so of course it should not actually be done.
You just have the link texts in a text editor one at each line, then select all and drag the selection to tabs toolbar.
But yeah, it does become an issue if you try it with thousands of tabs… It should work, but probably chokes quite a bit.
I guess that kinda depends on what you mean by “upload”. If you simply mean if user can point the extension to load some local file eg. via <input type="file">
then sure, that works just fine.
It sounds like the issue you mention regarding uBO Lite is not about if it can read a local file, but rather that it can’t use that data to update the active filter lists - perhaps because it already has too many dynamically inserted filter rules, but that’s just a guess.
Right, but then you shouldn’t be shocked to find out that a feature was removed because nobody seemed to be using it.
IIRC the old tab groups feature was eventually removed because telemetry showed that only very few people used it…
I mean, do whatever works for you, but that sounds kinda unnecessary when you can just use an already existing feature - tabs.
Not at all the same thing. For one, you can open a history entry and then navigate back from that to the page you came from to that page - which there may be several. Tabs preserve per-tab history which makes it superior in many ways to both history and bookmarks.
My first guess would be that this is caused by the website implementing its own navigation/history behavior using History API. That can easily mess things up, or at least not behave like you might want.
Okay, since it doesn’t like it’s your main computer or anything, you might be interested to try taskbar profile grouping. Go to about:config and while there create a new boolean pref named taskbar.grouping.useprofile
and set it to true
. Doing that the two profiles should have their own group in taskbar. It’s a very crude feature though, since for example the right-click jump list items are not separate and you can’t set different icons for them (unless you do that via Windows somehow), but it sort of works.
Fair. For something like that containers don’t work, and indeed profiles are probably the way to go. I sure wouldn’t mind if about:profiles had a button to create new icon for that specific profile which then would also be in its own taskbar group, but I doubt I would want it as default for new profiles.
At any rate, having multiple profiles per same install on same Windows user poses some issues. Like what profile are links in other applications supposed to open in?
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.