1787439 - CustomizableUI doesn't build areas if the default placements contain API-provided widgets (from CustomizableWidgets or external sources), even though those widgets can't be in the DOM yet

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[:Gijs (he/him)]

This logic governs when we rebuild area nodes when they get registered:

      // For toolbars that need it, mark as dirty.
      let defaultPlacements = areaProperties.get("defaultPlacements");
      if (
        !this._builtinToolbars.has(area) ||
        placements.length != defaultPlacements.length ||
        !placements.every((id, i) => id == defaultPlacements[i])
      ) {
        gDirtyAreaCache.add(area);
      }

      // <snip>

      // We only build the toolbar if it's been marked as "dirty". Dirty means
      // one of the following things:
      // 1) Items have been added, moved or removed from this toolbar before.
      // 2) The number of children of the toolbar does not match the length of
      //    the placements array for that area.
      //
      // This notion of being "dirty" is stored in a cache which is persisted
      // in the saved state.
      if (gDirtyAreaCache.has(area)) {
        this.buildArea(area, placements, aToolbar);

This means that if you add a widget to the default placements for a toolbar that is not in the XUL, but provided by CustomizableWidgets.jsm or an external createWidget caller, it doesn't appear in the toolbar on startup.

This doesn't currently affect the navbar because it has 2 spring nodes in the default placements, where we update the IDs from spring to numerically generated unique values, so this comparison:

        !placements.every((id, i) => id == defaultPlacements[i])

fails, so we call buildArea anyway and the save-to-pocket-button does get added - even though otherwise, it would fall victim to this bug.

This burned us pretty badly with Firefox View (which we added to the tabstrip, which doesn't have any spring or other "special" widgets, as CUI calls them).

This is likely at least part of the reason for bug 1395983, where we've noticed we're saving placements for areas on clean new profiles, which ideally we should not need to do.

Comment 1

[:Gijs (he/him)]

Attachment: Bug 1787439 - call buildArea if toolbar default placements contain API-provided widgets that therefore cannot be in the DOM when the toolbar is registered, r?dao,jaws

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ca5658db5125
call buildArea if toolbar default placements contain API-provided widgets that therefore cannot be in the DOM when the toolbar is registered, r=dao

Comment 3

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/ca5658db5125