1668374 - New Preference policy doesn't work on macOS

Status: VERIFIED FIXED

(Firefox :: Enterprise Policies, defect, P1)

Description

[Mike Kaply [:mkaply]]

Because macOS converts all booleans to 0/1, the new Preferences policy doesn't work there.

Comment 1

[Mike Kaply [:mkaply]]

Attachment: Bug 1668374 - Treat 0/1 as boolean in policy unless there is an existing int pref. r?emalysz!

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1ed849fcf90c
Treat 0/1 as boolean in policy unless there is an existing int pref. r=emalysz

Comment 3

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/1ed849fcf90c

Comment 4

[Mike Kaply [:mkaply]]

Emil:

Can you take a quick look at this one as well? This is a bug with the new preferences code. See:

https://github.com/mozilla/policy-templates/blob/master/README.md#preferences

An example mobile config would be:

<dict>
  <key>Preferences</key>
  <dict>
    <key>accessibility.force_disabled</key>
    <dict>
      <key>Value</key>
      <integer>1</integer>
      <key>Status</key>
      <string>default</string>
    </dict>
    <key>browser.tabs.warnOnClose</key>
    <dict>
      <key>Value</key>
      <false/>
      <key>Status</key>
      <string>locked</string>
    </dict>
  </dict>
</dict>

Testing should be similar to bug 1666836

Thanks!

Comment 5

[Emil Ghitta, QA [:emilghitta]]

Sure!

I have extended the scope a little bit (in order to include a couple of more prefixes + some of the security preferences).

I can confirm that issue is verified fixed using Firefox 83.0a1 (BuildId:20201002092536) - The preferences in question are successfully set to true/false and locked (where needed).

Used the following mobileconfig:

 <key>Preferences</key>
  <dict>
         <key>accessibility.force_disabled</key>
   <dict>
           <key>Value</key>
           <integer>1</integer>
           <key>Status</key>
          <string>default</string>
   </dict>
           <key>browser.tabs.warnOnClose</key>
    <dict>
            <key>Value</key>
           <false/>
           <key>Status</key>
           <string>locked</string>
    </dict>
	   <key>print.tab_modal.enabled</key>
     <dict>
	    <key>Value</key>
            <integer>0</integer>
	   <key>Status</key>
	   <string>locked</string>
      </dict>
	    <key>datareporting.policy.dataSubmissionEnabled</key>
	<dict>
	     <key>Value</key>
	     <false/>
	    <key>Status</key>
	    <string>locked</string>
	</dict>
	    <key>media.audioFocus.management</key>
	   <dict>
	      <key>Value</key>
	     <false/>
	     <key>Status</key>
	     <string>locked</string>
	</dict>
	     <key>intl.allow-insecure-text-input</key>
           <dict>
	      <key>Value</key>
	      <false/>
	      <key>Status</key>
	      <string>locked</string>
	</dict>
	      <key>geo.enabled</key>
	    <dict>
	      <key>Value</key>
              <integer>1</integer>
              <key>Status</key>
              <string>locked</string>		
              </dict>
		<key>security.insecure_connection_text.enabled</key>
			<dict>
				<key>Value</key>
				<true/>
				<key>Status</key>
				<string>locked</string>
			</dict>		
                       <key>security.insecure_connection_text.pbmode.enabled</key>
		<dict>
			<key>Value</key>
			<integer>0</integer>
			<key>Status</key>
			<string>locked</string>
		</dict>
		</dict>
  </dict>

Comment 6

[Mike Kaply [:mkaply]]

Awesome. Thank you!

Comment 7

[Mike Kaply [:mkaply]]

Comment on attachment 9178842 [details]
Bug 1668374 - Treat 0/1 as boolean in policy unless there is an existing int pref. r?emalysz!

Beta/Release Uplift Approval Request

• User impact if declined: New Preferences policy doesn't work on macOS.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Policy only, automated test, verified by QA.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Policy related.
• User impact if declined: New Preferences policy doesn't work on macOS.
• Fix Landed on Version: 83
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Policy only, automated test, verified by QA.
• String or UUID changes made by this patch:

Comment 8

[Julien Cristau [:jcristau]]

Comment on attachment 9178842 [details]
Bug 1668374 - Treat 0/1 as boolean in policy unless there is an existing int pref. r?emalysz!

approved for 82.0b8 and 78.4.0esr

Comment 9

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f0259b6b4979

Comment 10

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/a05489887e78

Comment 11

[Vlad Lucaci, Desktop QA (:vlucaci)]

This issue is verified fixed using the mobileconfig from comment 5 on macOS 10.13.
Tested using Firefox 82.0 (BuildId:20201014125134) and Firefox 78.4.0esr (BuildId:20201013163257)