MrOtherGuy

True, and I agree - for this feature to be effective the site-specific rules need to be maintained properly.

All I'm saying is that it leaving some query parameters unremoved is not indicative of the feature not working. If you want to add more query parameters to the removed list then feel free to open a bug about it.

That feature removes parameters that are known to be used for tracking. It does not remove all query parameters willy-nilly. For example on youtube it should remove si, feature and kw parameters as well as a set of parameters on a list that applies to all websites. However, pp parameter is not in that to-be-removed list.

As an example v parameter is for video id on youtube, it would be kinda silly if that was removed, so the feature kinda has to do some site specific action.

Reader mode can show images as well though. I mean, it isn't always successful in doing so - probably because there's about a million different ways a random website could show an image - but reader mode can show images that it thinks are part of the actual content.

I'm not seeing any such issue with Nightly on my Fedora system.

Indeed. Also, the auto-open PiP is super nice feature I've been using a lot.

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);

1. Start Firefox
2. Observe that the pref is indeed true
3. Go to Setting > General, observe that Confirm before closing multiple tabs is checked
4. Uncheck the option
5. In about:config observe that browser.tabs.warnOnClose is now false
6. Restart Firefox
7. Observe that the pref is again set to true

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.