148582 - Stop unwanted prefs from being set when opening panels

Status: RESOLVED INVALID

(SeaMonkey :: Preferences, defect)

Description

[Stephen Walker]

By opening the Smart Browsing & the Master Passwords pref panels, 3 prefs are 
set. The prefs are (all set to false): 
pref.browser.smartbrowsing.disable_textbox.add, 
security.disable_button.changePassword, and 
security.disable_button.resetPassword. 

The prefs are being set because the id='s on the xul elements that the prefs 
are associated with are included in the _elementIDs at the top of the xul 
file.  The prefs should only be set by an admin or an embedding person that 
wants to completely disable those prefs.  Removing the id='s from the 
_elementIDs stops the prefs from being set whenever a user views the panel.

Comment 1

[Stephen Walker]

Attachment: patch

Comment 2

[Kai Engert [:KaiE:]]

These prefs were once added with the patch in bug 87334, alecf asked for adding
those prefs, and morse produced the patch. Therefore I think, they should give
their opinion whether it is ok to remove them.

walk84, you're also removing an "addDomain", but you don't explain why. That
setting has been added by ben in April 2000, rev 1.24.

Comment 3

[Stephen Walker]

addDomain is the id= that is setting 
the 'pref.browser.smartbrowsing.disable_textbox.add' pref when the Smart 
Browsing panel is opened.

Comment 4

[Alec Flett]

if we remove these from _elementIDs then preflocking will fail, no?
it sounds like a bug in prefwindow code that we're setting those prefs in the
first place.

Comment 5

[Stephen Walker]

alecf, preflocking (which involves *just* setting 
pref.browser.smartbrowsing.disable_textbox.add or the other prefs to true?) 
still works when the id='s are removed from _elementIDs.

Comment 6

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)

Comment 7

[Philip Chee]

> pref.browser.smartbrowsing.disable_textbox.add, 
I searched all the way back to suite 1.7, back to the aviary branch and back to classic (pre xpfe) and couldn't find any references to this pref.

> security.disable_button.changePassword, and 
> security.disable_button.resetPassword.

In the new toolkit world the actual true/false state is ignored. Locking the pref disables the button irrespective of the actual setting of the pref. Since we have now migrated all our preferences panes to the extended toolkit preferences system, this bug does not apply any more. Marking as INVALID

Additionally opening the prefpane doesn't set those prefs anyway.