171200 - If preference exists in user.js, then dialogs should be greyed out

Status: VERIFIED INVALID

(SeaMonkey :: Preferences, enhancement)

Description

[mozilla]

If a preference exists in user.js, then the user cannot override this through
the GUI. Therefore, users should not have the ability to 'change' the preference
in the GUI where a relevant preference exists in user.js. This will align
expectations with performance.

For example:
user_pref("browser.downloadmanager.behavior", 1);

This presets the download manager behavior. This enhancement request suggests
that the download preference dialog box should have its options greyed out.

More difficult to implement but useful, would be some notice to the user that
the option is not available because it has been preset--above and beyond the
greyed out user controls.

Comment 1

[mozilla]

*** Bug 171201 has been marked as a duplicate of this bug. ***

Comment 2

[Sander]

On the other hand, it's quite possible that even though you've set a global
preference in user.js that you want to keep returning to, you still want to
change one of these preferences just for this session. Disabling any of these
settings is IMO not a good idea.
Some visual indication (in the status bar? any other ways which aren't alerts?)
that the changed setting will be undone the next time that Mozilla is started
might be nice though.

Comment 3

[Sven Grull]

If you want to change the settings from user.js you have to change them in
user.js because AFAIK these settings overwrite the preferences in prefs.js each
time mozilla starts.

Comment 4

[Chris Lyon]

->Prefs

Comment 5

[Michael Lefevre]

I think this has to be INVALID. What Sander wrote is correct - the prefs dialog
allows you to change stuff for the session, and for the session overrides
whatever is in the user.js.

the whole point of the user.js stuff is that it doesn't complicate the UI. I
think it would be more confusing, rather than less, if the user.js stuff had an
effect on the UI.

Comment 6

[Kenneth Herron]

It doesn't appear that there are any further comments on this request. Resolving
invalid per comment #5.

Comment 7

[sairuh (rarely reading bugmail)]

v inv