548815 - Tools\Options -> Privacy -> "Use custom settings" doesn't respect locked preferences

Status: RESOLVED DUPLICATE of bug 1203531

(Firefox :: Settings UI, defect)

Description

[Ilanio Castro]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; pt-BR; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; pt-BR; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

The function *PPP_updatePrivacyMicroControls* (in the privacy.js) always enable/disable all the controls ids present in the array *dependentControls* without look if they are disabled by lockPref policies.

The code must be changed, to update the array *dependentControls* removing all the ids that have been disabled by lockPref, to avoid these controls became enabled when user uncheck Private Browsing option

Reproducible: Always

Steps to Reproduce:
1. Lock browser forms fill using lockPref("browser.formfill.enable", false) in a CFG file.

2. Open browser -> Tools\Options -> Privacy -> Change history to "Use custom settings": Form fill option is enabled. The code of privacy.js ignores that form fill option must remain disabled and enable it because the private browsing option is unchecked.

3. If you click on the form fill option it turn disabled. If you check and uncheck private browsing it became enabled again.
Actual Results:  
Since I need that user doesn't change the form fill option, this bug cancels all the lockPref functionality.

Expected Results:  
I expect the private browsing dependent options that are locked by lockPref policy, remains disabled independent of the state of private browsing option.

If I edit *dependentControls* array in privacy.js removing "rememberForms", the option form fill acts as expected, so the code must update *dependentControls*, removing the IDs of options locked by lockPref.

By this way, changing the private browsing option does not change the state (enabled/disabled) of the options locked.

Comment 2

[Nickolay_Ponomarev]

This code was added in bug 462041.

Comment 3

[(no longer active)]

(In reply to comment #2)
> This code was added in bug 462041.

IINM, this problem existed even before that bug -- that bug just refactored the respective code.  Adding QAWanted for someone to see if this issue was present before that bug (like in 3.0.x).

Comment 4

[Ilanio Castro]

The bug was not present before version 3, since the Privacy from "Options" window was completely different.

Comment 5

[Mike Kaply [:mkaply]]

I'm unclear as to why there is a "qawanted" keyword here.

The bug does exist. Whether or not it was a regression is irrelevant.

Also as a side note, when you lock these preferences, the dialog doesn't default to the "custom" page which seems odd as well.

The values are changed, they just happen to be locked.

The value/defaultValue compare in checkDefaultValues is failing in that case.

There should be an extra check and if any of the prefs are locked, you should show the "Use custom" page.

Comment 6

[:aceman]

I do not see any checks for locked prefs in the whole privacy panel. How are locked prefs supposed to work? Does any control need to check if the pref is locked? Or is there some global mechanism that simply discards all changes to locked prefs?

Comment 7

[Mike Kaply [:mkaply]]

Locked pref checking is built into the <preference> XBL binding (as far as I know).

So you shouldn't have to do anything to take advantage of it.

For some reason, these preferences behave differently than other preferences.

Comment 8

[:aceman]

(In reply to Michael Kaply (mkaply) from comment #7)
> Locked pref checking is built into the <preference> XBL binding (as far as I
> know).
Where is this implemented? Which file?

Comment 9

[Mike Kaply [:mkaply]]

> Where is this implemented? Which file?

http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/preferences.xml

For instance, 

http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/preferences.xml#405

is the general disabling.

Comment 10

[Josh Matthews [:jdm]]

The locking only appears to cause the element to appear disabled. It isn't actually checked in the value setting code: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/preferences.xml#170

Comment 11

[Mihaela Velimiroviciu (:mihaelav)]

I can no longer find the form fill option under Options -> Privacy -> History options for latest builds. Does it make any more sense to continue investigation for this issue? Is there any other option related to this?
I removed the qawanted keyword for now. Please re-add it if you have other QA related requests.

Comment 12

[YUKI "Piro" Hiroshi]

This seems fixed by the bug 1203531.

Comment 13

[Mike Kaply [:mkaply]]

You are correct.