Open Bug 1767018 Opened 3 years ago Updated 2 years ago

Support enterprise policy for toolbar customization

Categories

(Firefox :: Enterprise Policies, enhancement, P4)

Firefox 91
enhancement

Tracking

()

People

(Reporter: office, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

I am not exactly sure where to raise this question as it's not a bug, but rather a request for where I can find documentation on this specific preference to understand what has to be included and what can be excluded.

But possibly this could be a feature request to split the browser.uiCustomization.state preference so that only settings relating to customising the toolbar are actually set here as the underlying problem is that this preference is also storing settings that have nothing to do with Toolbar customisation.

What I am trying to achieve (and which does work) is to deploy a common layout of Firefox where I can say printer, Find etc to taskbar, whilst removing features the users don't need.

So what I have been doing for the last few years is setting up Firefox Profile as desired, customising the Toolbar, then copying everything in the browser.uiCustomization.state prefs to a user.js file for all users (along with some other settings).

Actual results:

The deployment works perfectly, but suffers several flaws.

One - it retains legacy settings - such as in the past, you used to need / after the commas for everything to work correctly. You no longer need to do that.

Second - any setting that used to exist (like Loop whatever that was) is carried forward when Firefox is updated despite the setting no longer working.

But last and most important, this pref setting includes the following: Placements, Seen, dirtyAreaCache and currentVersion. It would seem that Placements is a: necessary (and is the toolbar customisation) and b: identical on whatever Firefox profile I pull it from (assuming that I have customised the toolbar identically). But with the other settings, either the order is different or the actual values are different. For example in CurrentVersion the new element count is 5 in one and 27 in the other!

I have tried Googling browser.uiCustomization.state to find out exactly what Seen, dirtyAreaCache and currentVersion actually do and more importantly find out whether these settings need to be included in this particular preference in the user.js file or within the Firefox Policy registry setting. Unfortunately I cannot find any documentation .

I have included a sample file below broken into the four different elements so it's easier to see what I am talking about.

Expected results:

{"placements":{"widget-overflow-fixed-list":[],"nav-bar":["home-button","back-button","forward-button","stop-reload-button","customizableui-special-spring1","urlbar-container","customizableui-special-spring2","downloads-button","print-button","find-button","sidebar-button","ublock0_raymondhill_net-browser-action"],"toolbar-menubar":["menubar-items"],"TabsToolbar":["tabbrowser-tabs","new-tab-button","alltabs-button"],"PersonalToolbar":["personal-bookmarks"]}

"seen":["save-to-pocket-button","developer-button","ublock0_raymondhill_net-browser-action"]

"dirtyAreaCache":["nav-bar","PersonalToolbar","toolbar-menubar","TabsToolbar"]

"currentVersion":17,"newElementCount":5}

Perhaps what this preference should do in future versions of Firefox is only have placements and the other three settings should be moved to a new preference. This would allow easy deployment of toolbar customisation? But in the interim, documentation on what exactly seen, dirtycache and currentversion are actually doing would be very helpful and also to know if necessary to include in user.js file

The Bugbug bot thinks this bug should belong to the 'Firefox::Toolbars and Customization' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Toolbars and Customization

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Hi,

Thank you for opening this enhancement. I will set this as New and waiting for the developers opinion about it.

Thanks for your report.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Aaaaargh. Please don't set this value in user.js. Doing so also permanently breaks user customization (ie if they ever want to change something themselves, it will get reset when the browser restarts). It also breaks Firefox's changes (so when we introduce new stuff, it will automatically keep getting removed by your "customization").

The right way to do this would be to use some kind of enterprise policy.

Component: Toolbars and Customization → Enterprise Policies
Summary: Firefox Documentation for browser.uiCustomization.state → Support enterprise policy for toolbar customization

(We're not going to document the JSON blob stored in the prefs as it's liable to change and isn't meant to be changed manually anyway.)

Thank you for getting back to me. I appreciate that this is not the best way to manage Toolbar Customisation. Which is why I created this post as I realised the shortcomings including the ones you have just mentioned. I have the ability to make registry changes to all computers as well as edit/replace any files on each client computer.

So I guess the question is where should the toolbar be configured for client deployment? Thank you.

I couldn't see an existing policy for this but it's quite possible I missed something. Mike?

Flags: needinfo?(mozilla)

We don't have a policy for setting the default layout of the toolbar.

It's something that's been in my head, but I haven't figured out the right way to do it.

Step one was disabling customization completely.

Flags: needinfo?(mozilla)
Severity: -- → N/A
Priority: -- → P4

I have discovered that there is a registry policy setting to show the Home Button.

Software\Policies\Mozilla\Firefox\ShowHomeButton = 0x1 | 0x0

This was always the most important reason why I was using the browser.uiCustomization.state prefs as we have a custom home page - with lots of links to many websites.

I have now moved virtually every Firefox setting (bar 2) to the registry - most in the registry location shown above. As a result of getting the ability to enable the home button in the registry, I have now deprecated the use of the browser.uiCustomization.state prefs in my deployments, as I I do agree it is a terrible hack and not a good way to configure settings in Firefox. So I am pleased to be rid of this now.

While I have disabled this setting and enabled the home button in the registry, I would still like to be able to show the Find button and the bookmarks button in the Toolbar.

Would it be possible to create two more registry entries similar to the Show Home Button registry setting.

Software\Policies\Mozilla\Firefox\ShowBookmarksButton = 0x1 | 0x0
Software\Policies\Mozilla\Firefox\ShowFindButton = 0x1 | 0x0

The only consideration would be that the Show Home Button defaults to the left of the Navigation Bar (which it does), but that the bookmarks and Find Buttons should default to the right of the Navigation Bar as the LHS should only have Home, Back, Forward and Reload ideally.

The order of placements of the buttons , while ideal is not that important. It is more important to have the ability to enable/disable buttons. So I am happy to amend the feature request to just enabling/disabling buttons on the Toolbar.

Thank you.

You need to log in before you can comment on or make changes to this bug.