1579332 - app.update.auto set to true and locked in about:config does not lock Check box in about:preferences

Status: RESOLVED DUPLICATE of bug 1612979

(Firefox :: Enterprise Policies, defect, P3)

Description

[drlellinger]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Set User Configuration\Administrative Templates\Mozilla\Firefox\Preferences - app.update.auto to activated which triggers app.update.auto to being set to true and locked in about:config

Actual results:

Preferences panel in about:preferences still gives user option to change setting

Expected results:

Preferences panel in about:preferences does not give user option to change setting

Comment 1

[drlellinger]

Also this setting locked to true does not affect the update behaviour

Comment 2

[Liviu Seplecan]

Hi @drlellinger, about this preference, did you have at some point this functionality if you set this pref the user shouldn't be able to change or select other checkbox? You have that requirements?
For now I can set a component for it, please fell free to change if isn't the right one, further we let someone from dev team to take a look and give us a hand.
Regards,
Liviu

Comment 3

[drlellinger]

The checkbox is still available with preference set to true and locked. Still it's possible to change settings.
To confirm that is not a UI bug we tested the update function.

Comment 4

[:Gijs (he/him)]

Mike, can you help clarify what's happening here? ISTR a similar report recently, is this a dupe of sorts?

Comment 5

[Mike Kaply [:mkaply]]

So app.update.auto was moved to be a JSM not actually tied directly to the preference anymore, so the prefs code doesn't update properly.

So there are two parts:

1. Make app.update.auto properly disable prefs on Mac/Linux.
2. Create a new policy that sets/locks AutoUpdate on Windows.

Comment 6

[:Gijs (he/him)]

Given that bug 1467603 has a request for this to work, and got duped to bug 1556551, I guess this is an enterprise policy thing to figure out.

Comment 7

[Mike Kaply [:mkaply]]

Kirk,

Can you offer advice as to how we can accomplish this on Windows now? We need some way to lock auto updates on on Windows.

Comment 8

[Robin Steuber (she/her) [:bytesized]]

I'm taking a look at this bug and trying to figure out the context of the question. It looks to me like the reporter is hoping to prevent users from disabling automatic update which, frankly, makes me a happy developer. Unfortunately, as mkaply has already pointed out, it is no longer appropriate to attempt to manipulate app.update.auto directly. Sadly, there isn't really a great way to convey this in about:config, so the comment explaining this lives somewhere not particularly accessible to users.

mkaply- It appears that you have correctly determined that locking the setting here is not currently possible on Windows. However, I would like to take this a step further. Please do not manipulate this pref directly on any operating system. At this point, I consider app.update.auto to be an operating-system-specific implementation detail of UpdateUtils.(get|set)AppUpdateAutoEnabled() and would greatly prefer that all queries and manipulations of this value use that interface.

As already mentioned, that interface does not currently implement a locking feature. I think that it makes a lot of sense to add this feature to enable this enterprise policy use case. Presumably, this feature, policy-wise, will need to take the form of a new enterprise policy since setting the pref directly isn't a good mechanism for this.

I'd be happy to work on adding this feature to UpdateUtils so that it could be manipulated by the enterprise policy engine.

mkaply- Have I understood the situation correctly? Are you on board for adding this policy? Do you have a timeline in mind for this so I can prioritize this correctly?

Oh! There's one other thing I feel like I should mention here. This setting is a bit complicated in its scope. On Windows, it affects all profiles and OS users who are using that Firefox installation. But on non-Windows, it is still a profile-specific setting. I'm not sure, but it's possible that this could cause potentially confusing results of setting this policy. IIRC, the policy engine accepts policies from HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE, but some policies are configured to ignore HKEY_CURRENT_USER. I think that if the policy was set via HKEY_CURRENT_USER, it could end up having confusing effects between users where it would lock it for one user, but allow it to be manipulated by another. Depending on the exact implementation details, this has the potential to result in some very weird behavior. Could we avoid that altogether by just not allowing this to be via HKEY_CURRENT_USER? All other policy mechanisms affect all users of the Firefox installation, right?

Comment 9

[Mike Kaply [:mkaply]]

At this point, I consider app.update.auto to be an operating-system-specific implementation detail of UpdateUtils.(get|set)AppUpdateAutoEnabled() and would greatly prefer that all queries and manipulations of this value use that interface.

Is that true on macOS too?

I'll add to my list to create a separate policy for this in my next sprint (starting for release in FF 75 most likely)

I'd be happy to work on adding this feature to UpdateUtils so that it could be manipulated by the enterprise policy engine.

That would be great. Or I could help if necessary.

Could we avoid that altogether by just not allowing this to be via HKEY_CURRENT_USER? All other policy mechanisms affect all users of the Firefox installation, right?

I can totally make this policy machine only on Windows.

Comment 10

[drlellinger]

Hello Kirk, Hello Michael,

i am happy this bug is currently being tracked. As the product owner of Mozilla Firefox in the company i am working for I would be very happy if a fix to the current situation would be possible.

In the meantime to the bug creation I have come up with a workaround to set the setting to default for all users for once but cannot prevent them to change the setting again.
My favorite solution the problem would be a policy to set the setting to a default value or lock it entirely.

A fix in the 75/68.7 release would be very nice.

Greetings from Germany

Comment 11

[Robin Steuber (she/her) [:bytesized]]

Hello drlellinger,

I am also glad that this policy is being investigated. I think that this is an important feature for enterprise Firefox to provide. Thank you for supporting Firefox!

---

mkaply-

At this point, I consider app.update.auto to be an operating-system-specific implementation detail of UpdateUtils.(get|set)AppUpdateAutoEnabled() and would greatly prefer that all queries and manipulations of this value use that interface.

Is that true on macOS too?

Manipulating app.update.auto is no longer the "correct" way to change this setting on any operating system. Currently, it will probably work, but I really do not recommend using it this way. UpdateUtils.(get|set)AppUpdateAutoEnabled() is the correct interface to use for changing this setting. Does this pose a problem on macOS?

I'd be happy to work on adding this feature to UpdateUtils so that it could be manipulated by the enterprise policy engine.

That would be great. Or I could help if necessary.

I would prefer to do the work within UpdateUtils. I think I should have some time free this week to work on this, so I'm hoping to be able to have this working pretty quickly. I'll leave the policy engine part to you though.

Comment 12

[Mike Kaply [:mkaply]]

We have a new app update policy that properly hides this checkbox.