74887 - Need UI for arbitrary pref change

Status: VERIFIED DUPLICATE of bug 17199

(SeaMonkey :: Preferences, enhancement)

Description

[Gervase Markham [:gerv]]

Mozilla has many obscure prefs for things. Not all of them make it into the 
Preferences panel UI. This means that, to change them, you have to edit 
prefs.js. This is prone to error/typos and you could possibly stuff up all your 
prefs if you write some bad JS in there. Also, non-advanced users won't want to 
do this.

We need a way, in the prefs dialog, of setting arbitrarily-named preferences. 
Then, for example, a user could be told "Don't like blink? Go into Advanced 
Prefs (or wherever) and enter pref name 'browser.blink' and pref value 'false'.

This, people can cope with. "Edit prefs.js and add the line: 
user_pref("browser.blink", false);
" is not good.

This system could display the current value of the pref, and do type checking on 
it (for example, only allowing "true" or "false" for bool prefs, or replacing a 
text entry widget with a checkbox). It might even check particular files exist 
for file prefs.

CCing mpt to get some UI ideas. I was thinking a text box for the pref name, and 
something which changed (check box/text box) for the pref value, depending on 
type...

Gerv

Comment 1

[Gervase Markham [:gerv]]

OK, so this is like bug 17199, but this idea might get implemented in our 
lifetime.

Gerv

Comment 2

[ajbu]

And maybe a combo to select known prefs. Would it be hard to put stuff like 
this in a separate package? That way we could build a ‘developer addon’ with 
these tools getting it done without having to battle over UI stuff. Most users 
would not use this anyway, so might be better not to bloat the core browser 
with it.

Comment 3

[Gervase Markham [:gerv]]

> And maybe a combo to select known prefs. 

You mean most-recently-changed?

> Would it be hard to put stuff like 
> this in a separate package? 

Yes. Anyway, the implementation as I envisage it is about 30 lines of Javascript 
and 10 of XUL. Hardly bloat.

> Most users would not use this anyway, so might be better not to bloat the 
> core browser with it.

On the contrary. Look at the Mail/News start page in 4.x - everyone hates it, 
and you have to edit prefs.js to turn it off. There's always _something_ that a 
lot of people don't like and that doesn't make it into the UI. It's Murphy's 
law. Having a general mechanism in all versions of the browser makes tech 
support people's lives much simpler.

Gerv

Comment 4

[Ben Bucksch (:BenB)]

Gerv, bug 17199 is not too hard either. Back then, I was just waiting for XSLT
for be integrated, because I thought this would happen any time then. There are
alternative implementations, which don't involde too much code either.

What you save here of code, you burden on users in form of a very unfriendly UI
(remembering exact strings etc.).

Sure, editing prefs.js is much worse that that, but I don't think that bug 17199
is so far away, assuming anybody is willing to spend a few days. Of course,
that's easy said, since I'm not one of these "anybody" anymore :).

Comment 5

[Ben Bucksch (:BenB)]

I should add that the prefs name strings and values were never intended to be
seen by users and IMO shouldn't be.

Comment 6

[timeless]

Ben: Beonex is not obligated to take this. however if we didn't intend for 
people to be able to read prefs we should have picked a binary hash encoding 
instead of human readable strings.

Comment 7

[Ben Bucksch (:BenB)]

timeless, my argumentation has nothing to do with Beonex. In fact, Beonex Comm.
is more likely to include this than Netsacpe 6 is.

Comment 8

[Matthew T (active 1999-2002)]

[I don't see any tangible difference between this bug and bug 17199 -- even if 
there is a difference in proposed UI design, I doubt that having two bugs for 
mutually exclusive GUIs for the same thing is the best way of handling the issue. 
If you like, rename bug 17199 as `Provide GUI for editing *all* prefs', to make 
it design-agnostic.]

Comment 9

[Peter Lairo]

Agreed, we need only ONE bug for this important feature.

And since bug 17199 has more discussion and has all the duplicate tracking, I
think it should be bug 17199.

mpt is correct about a new summary: `Provide GUI for editing *all* prefs'

In case the bugs aren't merged, then due to the high demand (see duplicates and
CC of bug 17199) the keywords: nsCatFood, and MostFreq should definetely be
added here.

Comment 10

[Gervase Markham [:gerv]]

Fair enough.

Gerv

*** This bug has been marked as a duplicate of 17199 ***

Comment 11

[sairuh (rarely reading bugmail)]

vrfy.