951420 - Separate printer prefs into their own about:support section

Status: RESOLVED DUPLICATE of bug 1286428

(Toolkit :: General, defect)

Description

[Daniel Holbert [:dholbert]]

As vulcain points out in his comments on bug 767857, printer settings can grow to take up a sizeable fraction of the "Important Modified Preferences" section on about:support.

I think it'd be worth splitting the "print." about:config subtree into its own section of about:support. That way, users asking for help for a non-print-related issue can post their "Important Modified Preferences" section on forums/bugs/etc. without including pages and pages[1] of unimportant[2] printing prefs.

[1] I say "pages and pages" because we store a whole subtree of printer preferences for each printer you've ever printed on, and those add up if you've printed on lots of printers.

[2] I say "unimportant" because these prefs are clearly only relevant if you're actually printing.  (In cases where a user is actually experiencing a problem with printing, developers/helpers can still ask them to copypaste the "Printing" section of about:support; but otherwise, these prefs aren't going to be relevant to diagnosing issues.)

Comment 1

[Dave Garrett]

It might be a better idea to just not cache everything about every printer Firefox knows about in the prefs. Just stick it all in a JSON file in the profile folder instead. Better to reduce the prefs.js bloat instead of just hiding it.

Comment 2

[Daniel Holbert [:dholbert]]

That sounds like just a different way of hiding it. :) (and would be a deviation from our standard way of storing/reading/saving configuration. Might as well stay consistent, unless there's a compelling reason to use a different preferences backend.)

(And in comment 0, I'm not really suggesting "hiding" it so much as just splitting it out into its own section, in about:support (as we already do for some component-specific configuration options).)

Comment 3

[Dave Garrett]

The Addon Manager caches metadata in its own JSON file (formerly sqlite). Most of what I see in there is not user-set printer preferences; it's cached settings it fetched for printers from the OS. That's generally not really supposed to be the sort of stuff dumped into the prefs system. What I'm suggesting is moving the bulk of that into its own file and leaving only the main preferences that aren't just cached stuff in prefs.js.

The less involved solution would be to clear out all prefs that match defaults. Does it actually need to store all of this stuff in the first place? I can just quickly go and print to PDF and it adds dozens and dozens of prefs without me doing anything special.

It's also fairly inefficient with regards to storing data and inconsistent in whether it branches with "." or "_" for sets of data. At some point JSON blobs in string prefs became the norm for some things like this so that's also an option (even if its debatable if that should be the case). This file does have to be loaded on startup, so reducing inefficiency here is probably the better option.

All that being said, if this bloat isn't reduced, moving it to its own section in about:support is a probably good idea. I don't disagree with that.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Dave Garrett from comment #3)
> The Addon Manager caches metadata in its own JSON file (formerly sqlite).

OK, it's possible that's a reasonable pattern to follow then.

> The less involved solution would be to clear out all prefs that match
> defaults. Does it actually need to store all of this stuff in the first
> place?

Probably not. IIRC a lot of the prefs are ignored (i.e. only written, never read), too.

I think a lot of the code for managing those prefs is from early-2000's-era or older, and it's entirely possible that it stands to be improved / redesigned.

> All that being said, if this bloat isn't reduced, moving it to its own
> section in about:support is a probably good idea. I don't disagree with that.

Cool.

Comment 5

[vulcain]

(In reply to Daniel Holbert [:dholbert] from comment #0)
Thanks to open a new specific bug.

You could find on attachement with bug 767857  an example of a big list of old printer:
https://bugzilla.mozilla.org/attachment.cgi?id=698135

Comment 6

[Mark Banner (:standard8)]

The idea here diverged a bit, but the fundamental issue is bug 1286428. I'm going to dupe this there as there's better overall discussion on there.