This allows removing the separate keyboard navigation map.
MozReview-Commit-ID: 2N0wflAvg7Y
--HG--
extra : rebase_source : 63b9ae6e4db0de1957cb011c69134894d311b703
Only one method is moved to the PanelView class to simplify the keyboard navigation test.
MozReview-Commit-ID: CHB5FiT9ptn
--HG--
extra : rebase_source : ec588beae9f1208a37ce85f9d28029dfd979db24
This makes the code easier to follow and facilitates future refactoring, for example the set of known views can be removed entirely by making the clean up and navigation code use the stack of open views.
The SlidingPanelView class can thus be removed, saving various lines of code. The class implemented a small optimization for garbage collection, that was already less effective because various other objects are created during each view transition anyways.
MozReview-Commit-ID: Z4JJMklUMf
--HG--
extra : rebase_source : 8789a35c4234fc691c62efeb3445b776b14fc1f9
The setMainView method of PanelMultiView controls the "mainview" attribute, which is already set or removed later in the showSubView method. When called at construction time, it changes the mainViewId if there is at least one child in the "panelmultiview" element and the original mainViewId does not already reference the first child. This would be incorrect, but in practice it never happens for either ephemeral or static panels, and can be avoided for the throw-away activated page action panel.
The setMainView method of PanelUI is never called, and this makes the corresponding PanelMultiView method removable.
MozReview-Commit-ID: 5bNidHfKFTA
--HG--
extra : rebase_source : b527827d30d682d183981347c2caf3a8a5d81355
The height of the subview being opened was supposedly calculated using an off-screen container independent from the currently displayed views, but this didn't work as expected because of the incorrect box alignment. This is now fixed and the correct minimum and maximum heights are set on the container separately, also preventing the current view from flickering before the transition in case the subview was taller.
With this issue fixed, the height can now be recalculated each time the subview is opened, without the caching that caused incorrect results when the same view was reopened with different elements or text.
Jumping could also occur because of a border applied only during the transition, which could influence the subview height in the presence of wrapping text.
MozReview-Commit-ID: EWHs1hFKXT4
--HG--
extra : rebase_source : 5b0bc4e5d4d2d10d684c2c2bf94a9030aadd09bd
* Let popup code initially measure and place the panel without maxHeight, this ensures alignmentPosition is a reasonable value
* Assign maxHeight from a popuppositioned handler and update the comment explaining the role of the autoPosition property
* Refactor to move the maxHeight calculation into a method on PMV
* panel autoPosition now gets reset to false in popuppositioned (was popupshowing) as the ShowWithPositionedEvent on popupFrame sets it back to true every time
* Update reflow tests with new signatures, and elimination of 1 reflow
* In appMenu reflow test, we must now wait for popupshown before opening subviews
MozReview-Commit-ID: KfHxngnajM3
--HG--
extra : rebase_source : 2918a30f6ecdfded57fb7b93aba3f0479fd4635c
The site security subview is now implemented using the "photonpanelmultiview" element, replacing the last instance of the "panelmultiview" element. The subview features a standard Photon header, hence the connection state icon was moved to the element below it. This makes the styles more similar between the main view and the subview. The connection state styles are now applied using a class name, and the tests have been updated accordingly.
This change required some fixes in the "photonpanelmultiview" implementation to make sure the height of the subview is correct and to allow keyboard navigation back to the main view.
Since the expander button and the permission controls in the main view are not visible anymore after the subview is shown, some code related to focus and hover could be removed as well.
MozReview-Commit-ID: 4nIAPWJPV8k
--HG--
extra : rebase_source : 74d6d769421c0f8521bdfae249b4d111e630a3bd
* 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
--HG--
extra : rebase_source : b810e1de2dbd75932a42d68e751fdaecd9fee69a
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
--HG--
extra : rebase_source : 1bdace324f22ee95002024fe68b572a16dd25aac
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
--HG--
extra : rebase_source : 41bb5ffe29ca8e0ec9acc1793ae87d63d28e1f43
While this creates several methods with just 1 callsite, given the previous length of the
showSubView method (230 lines), it seems wise to split this up and to try to reduce the
nesting, as well as making it easier to reason about what happens if we hide the panel
mid-transition.
MozReview-Commit-ID: 9Vf4p4fVBSs
--HG--
extra : rebase_source : f21ca55eaeb4bda49ba51f2694ecb5620f47e941
Prior to this patch, both CustomizableUI itself and the PanelMultiView module
tried to ensure that onViewShowing/Shown/Hiding/Hidden listeners were invoked
when the relevant DOM events fired.
PanelMultiView was doing this manually because CUI was only adding listeners
once the corresponding widget was created. Now that the relevant views can be
accessed without the corresponding widgets (via the fixed appMenu), there was
no guarantee that the listeners would be attached, and this caused empty
subviews.
Unfortunately, if the widget *was* present, it caused events to fire more than
once, which understandably broke consumers like the sync remote tabs widget,
which broke the test we're fixing up here. For other views, even if they were
not completely broken it at least did busy-work.
This patch removes the manual event invocation, and delegates the event
listener work to CUI from the PanelMultiView side. This ensures events fire,
and fire only once.
MozReview-Commit-ID: 94GhcrdcBuB
--HG--
extra : rebase_source : 4df42939aa06ec10b7f86c3c2e4fe75160c7e7bd
