When a setting related to the new tab is locked, it's disabled in about:preferences, but it's not disabled in the new tab settings popup.

I swear this used to work and I'm getting mixed results in my testing (they never lock but sometimes they disappear?)

I'm more than happy to fix this. I'm not sure what the right behavior is. Should they disappear if they are not changeable by the user or be disabled?

Here's an example JSON to test:

{
    "policies": {
        "FirefoxHome": {
            "SponsoredStories": false,
            "Stories": false,
            "TopSites": true,
            "Locked": true
        }
        
    }
}

"On Windows, create a directory called distribution where the EXE is located and place the file there. On Mac, the file goes into Firefox.app/Contents/Resources/distribution. On Linux, the file goes into firefox/distribution, where firefox is the installation directory for firefox, which varies by distribution or you can specify system-wide policy by placing the file in /etc/firefox/policies."

Note the way this shows up today is that if you lock a pref, the toggle is there but doesn't do anything.

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.

PrefsFeed broadcasts the names of the locked prefs to content alongside the
pref values, and the customize panel disables the controls carrying a matching
data-preference. Controls that render a disabled condition of their own opt out
with data-lock-managed and apply the lock themselves.

This keys off Services.prefs lock state rather than the policy engine, so it
covers autoconfig and the Preferences policy as well as FirefoxHome's Locked.
The panel has no controls for showSearch, feeds.section.highlights,
showSponsored or showSponsoredTopSites, so those locks have nothing to disable
here; about:preferences already handles them.

https://hg.mozilla.org/mozilla-central/rev/20dcd33034ef