1395983 - Ensure CustomizableUI does not save unnecessary state on new profiles

Status: NEW

(Firefox :: Toolbars and Customization, enhancement, P5)

Description

[:Paolo Amadini]

We should verify that the CustomizableUI module does not create any saved state on profiles that have not been customized by the user, which is the whole point of having lazy initialization of the customization state.

Comment 1

[:Paolo Amadini]

Attachment: Bug 1395983 - Ensure CustomizableUI does not save state on new profiles.

Review commit: https://reviewboard.mozilla.org/r/175412/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/175412/

Comment 2

[:Paolo Amadini]

This seems to fail because hookDeveloperToggle calls CustomizableUI.createWidget:

https://dxr.mozilla.org/mozilla-central/rev/13d241d08912be31884f9d0d0e805b25343d6c0a/devtools/shim/devtools-startup.js#272

Comment 3

[:Gijs (he/him)]

TBH, I think it's fine for there to be "seen" widgets, but the state of the navbar and other toolbars should not have been saved in this case. I didn't think we did save them if they matched the defaults, but maybe that's not actually what happens.

Comment 4

[:Gijs (he/him)]

Tweaking the summary. I think this is worthwhile if we can basically drop area placements from being saved when they're at the default. We will likely need to remove support for persisted currentsets in that case (which we should do anyway). That way we can minimize the amount of data we store in the pref.

Comment 5

[:Gijs (he/him)]

This should be better after bug 1510321 lands.

Comment 6

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #5)
> This should be better after bug 1510321 lands.

Nope. I still see it saving placements for every single area.

Comment 7

[:Gijs (he/him)]

When working on the review for https://phabricator.services.mozilla.com/D209978 I think I finally figured out one piece of this puzzle.

https://searchfox.org/mozilla-central/rev/1f46481d6c16f27c989e72b898fd1fddce9f445f/browser/components/customizableui/CustomizableUI.sys.mjs#1027-1034

I think this marks any toolbar with "special" nodes (like the springs / flexible spaces in the navbar!) as dirty, because the ID in defaultPlacements ("spring") won't match the id in placements, which will be of the form customizableui-special-spring1 etc. Which means they get saved.

This should be straightforward to fix but I'm not sure what the fallout will be at this point, having lived with the current status for so long.