User.js: discussion: trim section 9999.. (save over 200 lines) click here to learn more

Created on 2 Dec 2018  路  5Comments  路  Source: arkenfox/user.js

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

  • paste that into our deprecated sticky
  • keep the prefs in the user.js (because as a single document with all prefs it is extremely handy), but trim the hell out of it

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.

All 5 comments

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

  • everything in the one (offline) file, a single source. While the above probably fits that, some information is removed (even if that info will most likely not be needed
  • usability - does it make the user.js easier to use. No, all the useful stuff is at the top (or bottom for overrides). No, reducing a 2200+ line file by 200+ lines makes no diff, it's still long and users have to search and scroll). No, it doesn't reduce any setup or reading, because users can ignore the deprecated section. Yes perhaps to visually parsing all the deprecated prefs (which most end users don't need bother with).
  • compatibility - e.g Compare-UserJS wouldn't pick them up, and this is important info for a diff to include - not just when people dump shit on me, but end-users comparing their own - at least it would alert them to the fact we have it and perhaps investigate (especially if it's active state or value differs).

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ArchangeGabriel picture ArchangeGabriel  路  7Comments

kaliostro2 picture kaliostro2  路  7Comments

Thorin-Oakenpants picture Thorin-Oakenpants  路  5Comments

grauenwolfe picture grauenwolfe  路  7Comments

earthlng picture earthlng  路  6Comments