The previous code here always set the `isActive` property on all themes. When writing the
patch for bug 1402981 I ran into issues because the default theme has an `isActive` property
anyway (it's a different type of object). So I tried to avoid setting `isActive` if it was
already present. Unfortunately, the result was that `isActive` values, once set, weren't
correctly updated. Worse, these values are (and were, prior to bug 1402981) persisted in
some cases.
There's no point persisting these values, all that will happen is that they'll start
mismatching the 'real' state of the world (LightweightThemeManager.currentTheme). So instead,
let's just not set the `isActive` property at all, and rely solely on the ID of the current
theme (or the default theme's ID, now that we no longer support non-lightweight-themes) to
establish whether any of the themes should appear selected or not.
MozReview-Commit-ID: 7rajS71FoQR
* Harden the new `hideAllViewsExcept()` to not do erroneous things if called when
the binding is already gone.
* Generalize things into `hideAllViewsExcept(thisOne)`:
- Clear `_viewShowing` in there and do the descriptionHeightWorkaround thing
in there too,
- For Photon panels, do all the 'current' attribute setting in there. To show
a panel during transition, I introduced the 'in-transition' attribute.
* I had to make sure not to over-eagerly dispatch 'ViewShowing' events, because
that confuses some,
* Move the temporary panel handling, which contains an ephemeral panelmultiview
instance, internally. This cleans up the hacky, duplicate PanelUI.js code nicely.
* Keep a local copy of `_transitionDetails` to ensure it's still there after transition,
* Harden `_cleanupTransitionPhase()` to only clear the phase that belongs to a
specific transition, _if_ that's passed in as an argument. This resolves any
potential raciness that might occur when `showSubView()` is called again mid-transition.
* Skip the UITour element visibility check when it's inside a panelview, because
too many things need to happen and that check is too simple to be useful in
that case.
MozReview-Commit-ID: 5HpJKs1Ny5j
The goal of this patch is to ensure that:
- in default placements, specials have no unique ids
- in actual placements as stored by CUI, they do
- we reset the counter for those unique ids on reset.
- we re-number specials when building an area (like on startup, or when resetting),
ensuring that the actual nodes always match the placements for a given area.
- we force saves after resetting, to ensure that the gNewElementCount is always persisted correctly.
This last part will also fix bug 1393661
MozReview-Commit-ID: HAS5J5ZSgB5
The panel-subview-header is always hidden in photon (sub)panels, and so we now never show it.
Removing it avoids having to readd the old label for the bookmarks view, remove some unused
strings, and I noticed that we accidentally left the PanelUI-sidebar container which is
unused since bug 1360282.
MozReview-Commit-ID: 4ProWA1sUUs
Because we generate IDs for special nodes, we should update the inDefaultState getter to actually consider
these nodes to match even when the ids differ. This wasn't an issue before because specials weren't in the
default set for any nodes.
MozReview-Commit-ID: AI85yt2LuJD
