Open Bug 17199 (advancedprefs) Opened 24 years ago Updated 3 years ago

Advanced Prefs - Edit *all* prefs using tree UI

Categories

(SeaMonkey :: Preferences, enhancement, P3)

Product:
SeaMonkey
Component:
Preferences
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: BenB, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: See comment 74 for description) 

We have so many, often useful, prefs, that aren't (and can't?) in the Pref UI.
We could add an "Advanced Prefs" dialog, which is basically an editor for for
the prefs.js file (on a lower level than the current Pref UI), that can insert
any possible key/value pair, together with documentation.

The documentation could be in XML or a database and contains all possible keys
with description, value type, default value and category. The latter inserts it
into a hierarchy, so that "mail.do_glyph_substitution" appears as
"Mail/Display/Text Conversion/Glyph Substitution".

The dialog could have a structure like the current Pref UI dialog: The Hierarchy
is displayed on the left, right top the name as header and the description and
right bottom the widgets, depending on the value type, and action buttons ("OK",
"Cancel" and "Reset to default").
Status: NEW → ASSIGNED
The hierarchy could be replaced by tabs containing both the hierarchy and an
alphabetical list (of the names) of the options. This would simply references to
these prefs, e.g. in the "Knowledge Base".
As both the UI and the datasource are in XML, the plan is to realize that using
XSLT. The XUL for both the hierarchy and the "content" on the right are created
on-the-fly, the first on opening the dialog and the latter on a click on an
item in the hierarchy. That way, the implementation is just some XSL, XUL and a
bit JS.
The problem is, that the XSLT processor in Mozilla 1. seems to be unusable yet
(not XP) and 2. doesn't support parameters, which we need for the creation of
the right "content".
Depends on: 18706
QA Contact: cpratt → sairuh
spam: in my testing realm, so reassigning qa contact to me, en masse.
Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.
Component: Pref UI → Preferences
Mass-LATER
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
Depends on: 17200
with the the Future milestone, i'm not sure what to do with Resolved Later 
bugs... reopen, and set the milestone to Future? that way it won't get ignored 
(which often happens to bugs which are resolved or verified). also adding 
helpwanted kw, if there are any [external or otherwise] takers out 
there. :-)
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: LATER → ---
Target Milestone: --- → Future
I am not sure, this bug is still the right way to go. My current preference is
the Deep Prefs Hierarchy(TM), see discussion in .prefs.

This bug might be good for a "TweakUI"-like power-user package.

In short: better than hand-editing prefs.js, but 2 different prefs dialogs are
hardly good UI (opinion of Ben Bucksch at 2000-07-29 :) ).
Attempting a better summary than "advanced prefs".
Summary: Advanced Prefs → [RFE] Advanced users: Prefs Tree UI, edit all prefs w/ tree
Readding old name of this bug, thus keeping longer summary.
Summary: [RFE] Advanced users: Prefs Tree UI, edit all prefs w/ tree → Advanced Prefs - Edit *all* prefs using tree UI
*** Bug 64492 has been marked as a duplicate of this bug. ***
Changing personal priorities. Giving away most of my bugs :-( (reassigning to
default owner).

I will still track these bugs closely. If you need my input, feel free to ask me.

New owner: Please do *not* close these bugs (as WONTFIX or whatever you may
find) unless they are fixed. Rather, reassign to <nobody@mozilla.org>, if you
don't want to work on them.
Assignee: mozilla → matt
Status: REOPENED → NEW
Target Milestone: Future → ---
OT: I am very interested in seeing this bug implemented. It makes me wish i knew
how to program.

How about adding this to: prefs - advanced - miscellaneous?
This bug shou not be limited to just prefs.js settings; but to other settings as
well.

One setting I would really like to see implemented is to be able to turn off the
dreaded cascading of new windows. I place my window EXACTLY where I want it, and
want all new windows to appear there too.
Please also see (and CC and vote for) bug 68134 >>Need list of "tweakable
settings" in advanced preferences<< for some good comments/arguments why this
feature is important and how it can be implemented without confusing the "PC
challenged" user (i.e. prefs - advanced - miscellaneous, should be clear and
hidden enough to indicate to EVERYONE that these are non-required settings).

*** Bug 67996 has been marked as a duplicate of this bug. ***
Sorry, but that didn't insert my comment:

For Boris:
On the first place, thanks Boris. And if the implementation for bug 17199 is
done right, then it might be helpful. I will make this a dup of that other bug,
and i will add my concerns to that bug, which are backed up by a recent user
poll by then. I only hope to protect my kids in a way. Also that bug is rather
old by now. And belief me, this is all about marketing and pushing mozilla
forward with an competitive edge.

I'm not looking to make mozilla bloated, because that's out of the question.
Powerful, Flexible and Customizable that's more like it. I'm also not looking
for tweaks, but i do like to know more about pref. setting in general. But
that's a completely different story.

For Matthew:
Matt, my comment was short, but that's just because i run into a long ammonia.
For now my computer time is limited, and you know, we all have our bad days.
Just bear with me Ok? 

Most friendly, HJ.

Oh lord, what a begin, sorry for that but this had to be inserted for bug 67799.
*** Bug 67996 has been marked as a duplicate of this bug. ***
> One setting I would really like to see implemented is to be
> able to turn off the dreaded cascading of new windows. I place
> my window EXACTLY where I want it, and want all new windows to
> appear there too.

I would imagine this would be a prefs.js setting if implemented.
*** Bug 68134 has been marked as a duplicate of this bug. ***
Bug 46029 deals with a GUI for choosing a different UA string as 'seen' by
webservers (e.g. turn us into IE5.5 according to the webserver). Ben B pointed
us at this which I think is a better choice. CC self.

What is the status of this? Are the technologies ready for use in Mozilla? If
so, is it just a matter of discussing possible designs and implementing the best?

> What is the status of this?

Untriaged. I bet, Netscape won't implement it. So, whoever is interested, take
it (but double-check with current owner, to be sure).

> Are the technologies ready for use in Mozilla?

As for XSLT, I don't know. Might be. But there are other ways to implement it,
without XSLT.

> If so, is it just a matter of discussing possible designs and implementing
> the best?

Yes.

See also bug 74887.

Gerv
Due to the high demand (see duplicates and their CC lists) the keywords:
*nsCatFood*, and *MostFreq* should definetely be added.

How about making the prefs appear in a seletion list. Below the selection list
would be the data/variable selection area that changes according to what pref is
selected.

+-Miscellaneous Prfs-----------+
|                              |
| Pref 1                       |
| Pref 2 ---s-e-l-e-c-t-e-d--- |
| Pref 3                       |
| Pref 4                       |
|                              |
+------------------------------+
| Brief Description of Pref 2  |
|                              |
|  <x> Yes                     |
|  < > No                      |
+------------------------------+
maybe buttons for: 

- "Reset *selected pref* back to Default value" and for 

- "Reset *all Miscellaneous prefs* back to default values" 

Shorter names for the buttons would be needed, of course.
or just have the default value in brackets behind each pref:

+- Miscellaneous Prefs -----------+
|                              /\ |
| Pref 1                       |x||
| Pref 2                       | ||
| Pref 3 ---s-e-l-e-c-t-e-d--- | ||
| Pref 4                       |_||
| Pref 5                       \/ |
+---------------------------------+      +-----------------------------+
| Brief Description of Pref 3     |      | Brief Description of Pref 2 |
|                                 |      |                             |
|  [ 12 ]   (Default = 8)         |  or  |  <x> Yes                    |
|                                 |      |  < > No  (Default)          |
|                                 |      |                             |
+---------------------------------+      +-----------------------------+
*** Bug 74887 has been marked as a duplicate of this bug. ***
Peter: what you propose is unworkable because it requires the UI to know more 
about each pref than the pref system does. 

We basically have the following information:
- pref name
- pref type (string, bool, int)
- current pref value (if any)

We also need the system to work with arbitrary numbers of preferences, and 
automatically incorporate new ones as they are created. There are far too many 
of them for a drop-down box. We either go with Ben's UI, and have a tree, or go 
with mine, and have a text box. 

My idea has the advantage of not requiring XSLT, and probably being simpler to 
implement (get a PrefsService, query for the given prefname string, update if 
it's found, suitable errors if not.) His has the advantage of being more 
user-friendly. 

On the other hand, given a) advanced users can cope with my UI (it's just a 
shortcut for them) b) non-advanced users can probably cope with an email/web 
page telling them "stick this value in here and that value in there and press OK 
and it'll do what you want". 

If we do mine, we can always do the other later. Unless anyone wants to step up 
to the plate for doing the tree view now...

This bug is not mostfreq - it does not have 10 dupes. I very much doubt it's a 
Netscape priority either, and certainly not nscatfood. :-(

Gerv
When prefs are created, they must exist (i.e. be documented) somewhere. All we
need to do is add certain mandatory datafields (database) to that documentation
(i.e. pref description in common terms, default value, pref type, current
value). Then the prefs ui could retrieve those values and display them in the
list i proposed. 

This would deal with an arbitrary number of prefs and automatically incorporate
new ones as they are created since they would be retrieved from the datasource
on startup or on prefs UI loading.

Making users (especially novices) find some newsgroup and edit system files
(prefs.js) is definetely always a very bad idea - let's forget that "solution"
pronto.

Having the number of dupes be the criteria for a *mostfreq* bug seems silly to
me. It merely reflects the number of people who are too clueless to see if their
bug has already been reported. Wouldn't it be better to base *mostfreq* on the
number of persons in the CC list? I think so :)
> what you propose is unworkable because it requires the UI to know more
> about each pref than the pref system does.

I agree wtih Peter L. here: The intention was to build a (XML-based) database of
available prefs and their values. Allowing a user to set 6 as value, while the
pref is an enum and only 0-3 are defined, is not too useful. That is, when you
wan to provide a comfortable UI.

> We either go with Ben's UI, and have a tree, or go 
> with mine, and have a text box.

Or both, one after the other. Please do not close this bug, after you
implemented your short-term proposal in bug 74887.
For the record: While I definitely prefer my inital suggestion of a tree with a
comfortable UI, I have no (strong) objection, should somebody decide to
implement Gerv's suggestion first.

Peter L., the mostfreq keyword is mainly to stop too many dup reports, i.e. to
help the bug triagers with their work. It is not so much a marker of the
importance of a bug. (But it is an indirect one, just as the cc list is.)

> Allowing a user to set 6 as value, while the
> pref is an enum and only 0-3 are defined, is not too useful. 

But going down this route will lead to a world of pain where the prefs database 
gets out of sync with reality, and it either lets you set invalid values or, 
worse, won't let you set valid ones. We must be getting on for 100 prefs, with 
more added every week. 

As you will note, I've closed the other bug, not this one. I have no intention 
of closing this one :-)

Gerv
Gerv, you are right. But the current situation is a problem, and we need a
authorative database of prefs anyway (apart from the default prefs). This bug
would "encourage" programmers to keep the database current, because they like
probably like the comfort of the UI as well, and have an interest themselves to
set the values via the UI -> keep the database current.
As a side note, I doubt anyone could make an authoritative list of prefs without 
trawling the entire source base - AIUI, there's no central registry for them. 
This is another hurdle to cross :-(

Gerv
If the "database" were dynamic (i.e. the prefs UI would retrieve /whatever/ is
in the database), then we could gather together prefs gradually, but implement
the UI now, with only the first set of available prefs.
Isn't that what all.js is for?
> If the "database" were dynamic (i.e. the prefs UI would retrieve /whatever/
> is in the database)

That is the plan, that's what I meant with "on-the-fly" in my Dec 1999 comment.
Note that we don't necessarily need XSLT for it, it canbe coded in JS, just that
XSLT would be the most elegant or coolest solution.

> Isn't that what all.js is for?

all.js (et al) only ontains the default prefs. It does not contain (in a
computer-readable form) all possible values or a description of them. Actually,
for many prefs, there is no description at all currently.

Also, it does not contain really all prefs (but almost all). For these missing
prefs, we fall back to a hardcoded default value ...or misbehave :). In any
case, missing entires in all.js (et al) are a bug.

So, yes, creating such an database (for the current Mozilla) is work, but it is
doable. And Peter is right, we don't need a complete database to implement or
even check in the UI.

->mcafee [default prefs owner].
Assignee: matt → mcafee
mitch, this is the bug i was mentioning earlier... perhaps your webpage/script
suggestion would be an alternative to this? feel free to ping me on irc to
discuss...
Yes, we can do this with a webpage and some signed scripts (as soon as I get
those working again). With a signed script, a webpage can display and modify prefs.
Target Milestone: --- → Future
Problem: 
  You want to keep a DB of prefs with all possible values for each pref.

Idea:
  When the browser loads the prefs, if the prefs value is not in the DB then the
setting is not valid.  This would create a checks and balance system between
programmers adding prefs and them also adding the possible values of that pref
to the DB.

Of course, this would be a startup speed issue, but I think the prefs are being
compiled and cached for speed currently, so the speed issue would only be a
factor the next time you started the browser.

Not valid settings follow the current logic flow when a pref has an invalid value.
Over to vishy to find an owner.
Assignee: mcafee → vishy
In addition to the current value of a pref, we also know the default value (if
the pref is set in all.js et al. If this were for super-advanced folks we can
leave it up to them to know what they're touching. We'll display the uneditable
default value so they can get back to something sane if they screw up.

This would be good for a QA audit, too: we could work down the list and find
prefs that are in-use (exist, have a value) but which don't have a defined
default value.
->samir.

am also wondering if bug 98569 would be considered a dup of this...? esp now
that about:config has been implemented. [yay!]
Assignee: vishy → sgehani
*** Bug 98569 has been marked as a duplicate of this bug. ***
what is with a regular expression to check the value.
this could be implemented as a value in the xml source. to save runtime i prefer to check the values only after a change in the advanced prefs dialog. 
i think it is not a good idea to handle all.js for default values and a xml file as a database. 
Couldn't we implement this as inline editing (ILE) of the about:config tree?
Summary: Advanced Prefs - Edit *all* prefs using tree UI → Advanced Prefs - Edit *all* prefs using tree UI (about:config?)
This bug was supposed to do much more than about:config does. It was planned
that the user gets inline documentation about the pref in question, the possible
input is restricted by the allowed options for the relevant prefs etc..

Making about:config editable might be a good workarond in the meantime, but I
don't know, if it's worth the effort - the full-blown solution shouldn't be
hard, now that Transformiix is supposed to work. That's what I wanted to use 2
years (!) ago.
Summary: Advanced Prefs - Edit *all* prefs using tree UI (about:config?) → Advanced Prefs - Edit *all* prefs using tree UI
*** Bug 103963 has been marked as a duplicate of this bug. ***
Blocks: 107418
I don't know whether about:config is in outliner / tree or not, but if so,
couldn't we leave the config items displayed as they are, except adding an arrow
on the left of each? This, once "opened", would turn the fields editable and add
buttons like "OK", "Cancel", "Reset to default" below. Wish I could find a good
example screenshot at the moment.
It looks like another way to provide prefs editing is in bug 110090.
Blocks: 130920
See also bug 14969, "[RFE] TweakUI-like Package to attract audiences that like
to customize".
*** Bug 147750 has been marked as a duplicate of this bug. ***
I filed an enhancment request about this yesterday (bug 147750), without knowing
that it was already there (sorry about that).

I just want to say that I'd vote for Peter Lairo's suggestion in adding a
description to the database (?) of mozilla preferences, so the UI could also
display what a specific setting does. Since adding a description for each
setting will take time, space could just be reserved for it, then we would add
more and more descriptions of the most common settings as time went by.

'Hixie' Hickson (comment #46) also mentioned the about:config method. This
actually lists exactly the features that we are talking about here. By just
making that list editable and add an extra column (pref description), we would
have the functionality already. Then we could just put that code into a section
of the Preferences window.
This would be very similar to the Gruop Policy Editor in Windows 2000/XP. There
you have the list of preferences, along with a description and default value.
Since we're talking about more or less advanced features, it's not so important
that it's *very* easy to use. It could, in my opinion, look very similar to the
current about:config list, with the addition of being editable. maybe you could
just double click on a true/false setting to toggle it? And string values would
display an edit-box when double-clicking (like when you rename a file in Explorer).
I noted that I have some examples for the XML doc on my website, and I don't
seem to have referenced them here. <http://www.bucksch.com/1/projects/mozilla/17199>

As for the implementation, it's now 2.5 years later and XSLT in Mozilla still
can't be used to generate XUL. Additionally, I have no idea if I can pass
parameters to the XSLT via the URL.
Maybe a hard-coded converter (implemented in JS) of the XML doc to XUL would be
the more realistic way. It would read the XML file(s) into a DOM, generate the
XUL tree for the categories out of it and when the user clicks on an item in the
tree, it looks up the data in the XML DOM and generates the editing UI out of it.

Reassign to nobody, to clarify that nobody is working on this.
Assignee: sgehani → nobody
URL: http://www.bucksch.com/1/projects/moz...
I _might_ be willing to tackle this as "Baby's First Mozilla Project".

I am an amateur Borland "Delphi" programmer with no non-DOS 
or non-Windows experience.   With Delphi, I am more than capable
of writing an applet that can 
1.) Display the contents of all.js, prefs.js, and user.js in
a browsable and searchable interface.
2.) Allow the user to make changes to the values.
3.) Write the changes back to either prefs.js or user.js.

As to what I can do with programming tools/languages I'm 
not familiar with?

As well, it must be noted that all.js, prefs.js, and user.js 
are NOT a comprehensive list.  Example:  if you don't already 
know about browser.bookmarks.file you are not going to find
it in one of those three .js files.
Is this a duplicate of Bug 110090 ?
oh, duh! I just found out about XUL templates and that they might be even more
appropriate than XSLT. I feel a bit like an idiot. I'd like to try it out, but
unfortunately, I have no time right now.
->me
Assignee: nobody → ben.bucksch
Alias: advancedprefs
*** Bug 170661 has been marked as a duplicate of this bug. ***
*** Bug 173465 has been marked as a duplicate of this bug. ***
Here is a proposed solution that requires very little in the way of changes to
the current prefs system and shouldn't be too hard to implement:    
 
Make each pref have its own URL (for example
about:config/browser/popups/showPopupBlocker).  At this URL have a page that
allows the user to set the value of the pref according to its type (bool,
string, whatever).  It doesn't have to have any extra documentation other than
the  pref name, because most people won't go browsing the jillions of prefs. 
Instead this makes it possible to make a *link* to a pref.  Now when someone
hears about a whiz-bang new Moz feature, all they have to do is click the link
given in the Slashdot comment (or whatever) and they get a page that allows them
to set it right away.  No mucking with text files.  

I think this will solve the #1 problem this bug is trying to solve - people hear
about a cool new moz feature but don't like having to find text files and edit
them and restart mozilla and all that.  No extra documentation (taking up
valuable memory space and download time) is needed since this is not meant to be
a way of discovering new prefs.  This just lets people have easy access to any
pref they personally know about, and be easily told about any pref in Mozilla. 
If you *really* can't live without the ability to browse the prefs with
documentation, that could fit in nicely with this solution too.  Just make each
pref group a directory (about:config/browser) showing each pref and have
documentation on each individual pref page.  But I think that the descriptions
aren't really necessary; the problem is mostly setting specific prefs that you
have heard about, not surfing the prefs to find new cool ones, and besides, the
pref names are quite descriptive already by themselves. 
I have just posted an XPI to the mozdev site (http://preferential.mozdev.org)
that provides this very functionality.  

Eventually, I plan to add documentation on each bug from an RDF datastore, but
for now, the XPI simply allows access to a preference tree that can have entries
added, edited and deleted on the fly.  The current results are very similar to
that proposed by comment 62.
The Preferential Mozilla extension (http://preferential.mozdev.org) is now at
version 0.3.1.  It has been successfully tested as providing a tree UI for all
Mozilla preferences on Windows 98 for both Mozilla 1.2b and Phoenix 0.4.

Any feedback on this tool would be welcome.
There's no way to load this pref viewer in the content area, or using URLs, is
there? That could be dangerous.
This is sorta covered by the new editable about:config screen now - no?
*sigh*, no, read up.
Keywords: qawanted
QA Contact: sairuh → nobody
Whiteboard: [se-radar]
Depends on: 195845
No longer depends on: 195845
Depends on: 158384
  Is there any hope for this feature request?  Perhaps the author of
Preferential should be asked if he'd be willing to create a fix for this bug. 
Anyways, this bug has been inactive a rather long time...
Keywords: qawanted
QA Contact: nobody → mozillamonks
Sure, if preferential made it so that it could provide the same functionality
through about:config by overriding chrome://global/content/config.xul, I don't
see why not as long as preferential were allowed to be included as a default
extension. I have some complaints about preferential, though:

*Filter doesn't work (filter does in about:config)
*Needs a root tree element so you can truly Expand All
*Whereas preferential is tree-only (it seems) and about:config is list-only,
we'd want a combination of the two

If we went this route, preferential should probably supply a slightly different
UI for its about:config replacement than it does in a window since standard
menus shouldn't be inside a tab. I like the UI for about:config, and this could
be expanded upon. Perhaps clicking "Advanced Preferences" could simply always
load about:config in a tab.
Summary: Advanced Prefs - Edit *all* prefs using tree UI → Advanced Prefs - Edit *all* prefs using tree UI in about:config
Geez. Read up. This bug is *not* about <about:config>, but a specific GUI idea.
It's not "Preferential" either. Resetting summary.
URL: http://www.bucksch.com/1/projects/moz... → http://www.bucksch.org/1/projects/moz...
Summary: Advanced Prefs - Edit *all* prefs using tree UI in about:config → Advanced Prefs - Edit *all* prefs using tree UI
Ben: The discussions in this bug are old and its hard to follow exactly what
people are talking about in the beginning because a lot has changed. Also, most
these comments were prior to the inclusion of about:config for editing prefs,
and the creation of Preferential.

Please recap what this bug is about because I think there is a lot of confusion
in the last year's worth of comments, and that is what people generally go by
because the older discussion is out of date and also there are conflicting
statements and it also appears incomplete. Whoever orignally CCed themselves has
probably forgot a lot of the original discussion that occurred within newsgroups
and IRC. Can you recap what the most popular ideas are and _exactly_ what this
bug is about?

Is this basically a discussion for a UI that shows the documentation for
preferences that are contained within the source code? I remember something to
that affect, and people mentioning that the documentation could be within
.properties files, etc. If so, why is tree UI mentioned in the summary. Is a
tree necessary to show documentation for the preferences?

It almost seems like 3 different things are discussed in this bug. Please clarify.
Product: Browser → Seamonkey
What is the status of this bug as of now? Is it dead? There were no activity since 2004!
Since there was no clarification, what this bug really is about and the functionality to edit all prefs is given by about:config, I'd suggest to mark it wontfix.
Whiteboard: [se-radar] → [se-radar] [CLOSEME INVA/WONT?]
Bruno, as said above, the idea was expanded on the newsgroup a bit, then drowned into a discussion with Matthew Thomas.
<http://groups.google.com/group/netscape.public.mozilla.prefs/browse_frm/thread/68dd94274bbcb58e/a76398d6c86a0d97>

The idea was:
> the prefs should be designed (semantically) well. But the real solution
> to the problem is to organize prefs well.
>
> In the long term, I'd like to organize them in a deep hierarchy, with
> the "frontpage" (the panel you get by clicking an a parent node) of a
> subtree not being a collection of misc prefs (which didn't well fit in a
> subpanel), but the most important ones. That way, a user with limited
> needs wouldn't have to care about the deep hierarchy. If a user misses a
> pref on the "frontpage", he can explore the hierarchy in more depth.
>
> (See also bug 17199.)

Robert O'Callahan wrote:
<http://groups.google.com/group/netscape.public.mozilla.prefs/msg/12e66c73ba72391a>
> the maximally usable set of preferences is different for different kinds
> of users. Most people can only handle a small set of preferences.
> On the other hand, I just love programs that give me scrolling lists
> with hundreds of checkboxes. So, I would like to have lots of preferences
> that are usually concealed.

about:config is a hack, not a solution.
1) There are absolutely no descriptions what the prefs mean.
   The description is very much needed.
2) It's not discoverable, not browsable. Unless you remember the pref name,
   it's very hard to find.
3) It only lists prefs that are in the default prefs file. The infamous
   "browser.dom.window.dump.enabled" for example - I *always* have to look
   it up, even now, because I can't remember it and it's not in the defaults,
   because default prefs are claimed to slow things down. That's not usable
   in my opinion, I am angry every time I have to set this pref.

This bug would fix all of them. It would have a database of prefs, including descriptions and allowed values, as described at the top and at the URL. They are also categorized, so you can browse. Each category page summaries the most important prefs for that category, so you naturally get a nice UI, where you don't have to drill down deep for commonly needed prefs, but you can drill down as deep as you need to.

This solves the problem that the amount of usable prefs UI, and the number of needed prefs, varies a lot between users and there's no clear cut-off point. The point is different for each user. Given that you can dive deeper, per brach, as much or little as you want, and it's always gentle, this solves the problem.
Whiteboard: [se-radar] [CLOSEME INVA/WONT?] → See comment 74 for description
Assignee: ben.bucksch → nobody
QA Contact: mozillamonks
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.