I have an idea ... although I don't know if it matters. This section is at the end so it doesn't get in the way (except overrides), and file size doesn't matter
But, deprecated items from FF60 and below, the lines total 376. We could
It's just an idea. I'm not really fussed about it. I'm 54% keeping it as it, and 44% doing it (but it must a decent whopping reduction, not some piddling 30 or 40 lines), and 2% meh
e.g.
/*
FF42 and older
[897811] pageThumbs.enabled (FF25+)
[960426] dom.network.enabled (FF31+)
[1091016] network.websocket.enabled (FF35+)
[1042135#c101] privacy.donottrackheader.value (FF36+)
[1107683] camera.control.autofocus_moving_callback.enabled (FF37+)
[1109475] browser.safebrowsing.reportErrorURL
browser.safebrowsing.reportGenericURL
browser.safebrowsing.reportMalwareErrorURL
browser.safebrowsing.reportMalwareURL
browser.safebrowsing.reportURL
[1132357] network.http.spdy.enabled.http2draft (FF41+)
[1169945] plugins.enumerable_names (FF+41)
[1102184] privacy.clearOnShutdown.passwords (FF42+)
[1160017] full-screen-api.approval-required (FF42+)
FF43
[1107372] browser.safebrowsing.gethashURL // repl. browser.safebrowsing.provider.google.gethashURL
browser.safebrowsing.updateURL // repl. browser.safebrowsing.provider.google.updateURL
*/
After 42 we don't need the (FFx) bit for each line. That's 123 prefs + 19 lines for versions = 142 lines. We can also add comments at the end of each pref if its really handy and saves researchers time, such as // replaced by x (above for example only, I don't think these SB prefs warrant it). Excluding changes to the section header, that would shave off 234 lines.
I use my user.js as my first "go to", for looking up to see if anything someone suggests is already deprecated, for bugzillas, for references, which FF version was it deprecated, what it got replaced with. I think the above format keeps all the info "we" need, and everything we're discarding is not that important (IMO).
References are virtually immaterial if it's been deprecated. Descriptions probably don't matter (because no one can use em). And numbers can go to hell. And if someone, somewhere ever really wanted to get some of that, there's an archived copy in the sticky.
One drawback would be Compare-UserJS wouldn't pick them up
Edit: but that might not be a bad thing
Well, not only am I lazy, but I'm impatience (and anal) .. and OCD (gotta keep those open issues to 25 and under).
2 days and not a single comment. I'm not fussed. Having all our hard work and info fully intact in the user.js makes me happy. Don't give a toss about file size (there are no performance issues) or number of lines (it's at the end before your overrides, it's not getting in the way FFS).
Feel free to comment if you want or re-open this ticket if you have any exciting developments
2 days and not a single comment.
I am sure we all follow development of one of your masterpieces.
I just don't see to be competent and able to do some better and commenting would just mean an unnecessary distraction to you.
I am really happy for your project and big thank to you, big E and all other valuable contributors.
Cheers :heart: :kiss:
^^ No worries. By all means comment, it's not a distraction
Something like this is not technical, just a usability thing. But in hindsight I probably didn't think it through (which is why I need feedback). I have some core principles here
I don't expect you all to know what's going on in my head, but just typing things out and opening issues often helps me clarify things.
Anyway, all in all, now that I've actually thought about it ... it wasn't such a good idea
[SECTION 9999] is well organized and very informative. It's at the end of the file, so it doesn't do any harm. Please don't remove / trim it! Even if you do it, I have a backup copy :)