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
The third param of 'getTabsFragment' and 'getWindowsFragment' toggles whether the 'restore all' item
gets prefixed (true) or suffixed (false). The prefixed version doesn't get a separator, so this
seems like the simplest fix.
MozReview-Commit-ID: BzKWvndWUMp
This moves the explanatory text from a pseudoelement to a real element,
and keeps only the image in a pseudoelement. It then uses a transitioned
opacity to fade that image in and out.
Because we need to fade this based on dragging items over the panel when
it's empty, it adds/removes a 'draggingover' attribute to handle the fade.
To cope with the extra element in the drag/drop container in customize mode,
this also makes the following changes:
- bail out of _onDragStart if there's no actual selected item.
- pick the fixed list in the panelHolder more reliably
- add a max-width to avoid the description making the panel wider
MozReview-Commit-ID: 9PEJSoJJ0Rp
* 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
We weren't removing the 'open' attribute from the anchor if the transition didn't complete.
This patch fixes this by moving the addition of 'open' into _transitionViews, and its removal into
_cleanupTransitionPhase.
MozReview-Commit-ID: TS0CcwsHVN
The margin rules for labels mean that if the See what's new link
starts its own line, the alignment looks off. We could override this,
but matching the styling for "Learn more" links, which get their own
line, seemed the better option.
MozReview-Commit-ID: 4WK9QtRMUQs
Prior to this change, showMainView set the 'current' attribute on a main view, but then _cleanupTransitionPhase() would remove it again.
This patch fixes that by calling showMainView *after* _cleanupTransitionPhase.
Separately, we weren't removing the 'open' attribute from the anchor if the transition didn't complete.
This patch fixes this by moving the addition of 'open' into _transitionViews, and its removal into
_cleanupTransitionPhase.
MozReview-Commit-ID: 24FYaxDVlga
Rather than using left-hand-side at all times (which can go over the edge of the window
in some cases) this uses left or right-hand-side panels, always opening towards the
center of the window.
MozReview-Commit-ID: EvjDmKR1G5A
Note that we will no longer show the panel if you use the context menu to move the item in one
window and have customize mode open in the other. I don't think that edgecase matters.
MozReview-Commit-ID: 3dzGr3cs2oQ
The highlight styling was recently added, causing update notification
buttons to both be styled as grey. This fixes that to style them as
blue again.
MozReview-Commit-ID: HDSA9NWBmIA
