* Use new panel animation when opening arrow-panels (including bookmarks menu) to fade in and drop into position
* Linux/GTK is (still) excluded
* New animation is non-directional (i.e. LTR vs. RTL)
This was landed then backed out due to test failures. New since last review:
* Make opacity & transform transition durations equal - ensuring popup is not still moving when popupshown is fired
* Fix missing comma in transition-duration values
* Add animating attribute to the arrowpanel binding to disable pointer-events during the opening transition (via :jaws)
* Wait for popupshown rather than transitionend in bookmark reparenting test
* Fix specificity of CSS rules for panels/bookmarks-menu on edges other than the top (via :jaws)
MozReview-Commit-ID: DTnvyMryf5Y
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
There are no more help/quit buttons in the panel that shows up in customize mode,
and there are no more hyphenation quirks in items in the panel, so those tests
have been removed. The remaining tests are updated to test the correct panels.
MozReview-Commit-ID: LiUWejjZC7c
The new panel doesn't have placeholders, or a distinction between wide and
narrow widgets, so those tests can just be removed.
MozReview-Commit-ID: D61AjwMbabG
Apparently the hover state of the combined buttons does not interact well with the menus unless they
share the same containing popup/panel. We broke that condition in bug 1354078. The expedient thing
is to simply move the popup back, and move it back and forth if/when the photon pref is flipped.
When removing the pref, we can simplify this by always putting the menu in the overflow panel.
I also noticed that we use the toolbar context menu in the dynamic portion of the overflow panel.
This has the same problem, and to fix it I switched us to using the same (panel) context menu in
the photon case. Doing this in the non-photon case won't help because the context menu will be in
a separate panel (namely the old hamburger panel) entirely.
MozReview-Commit-ID: 4neHMukTzHA
These rules are set explicitly to allow the two views to be displayed next to
each other briefly when the slide-in transition starts.
This patch also applies the last remaining photon styles to the temporary panel,
which is used by the new Library widget as well.
MozReview-Commit-ID: 45aYzVHwRYv
These rules are set explicitly to allow the two views to be displayed next to
each other briefly when the slide-in transition starts.
This patch also applies the last remaining photon styles to the temporary panel,
which is used by the new Library widget as well.
MozReview-Commit-ID: 45aYzVHwRYv
This #ifdefs out the multiview for non-photon-theme, and checks for it being
present in various bits of JS that interact with it. As a result, this will
'fix' the issues in this bug and in bug 1370967 for 55 as it moves off
Nightly. bug 1370967 will still need fixing in the photonpanelmultiview /
webextensions.
MozReview-Commit-ID: 6x4HmyvxeRP
This #ifdefs out the multiview for non-photon-theme, and checks for it being
present in various bits of JS that interact with it. As a result, this will
'fix' the issues in this bug and in bug 1370967 for 55 as it moves off
Nightly. By switching to the photonpanelmultiview, we get proper anchoring
and slightly improved styling (bug 1354086 covers the rest of that), even
where this code *is* enabled. bug 1370967 will still need fixing in
the photonpanelmultiview / webextensions.
MozReview-Commit-ID: 6x4HmyvxeRP
This ensures we update edit UI visibility state when opening/closing the
overflow panel, as well as ensuring we do so if/when the edit controls
get over/underflowed. It then updates the test to ensure we correctly
check the overflow panel, both for overflown items and for items
put there by the user when photon is enabled.
MozReview-Commit-ID: AjRH8wz5Pla
While we are now correctly evaluating the fullscreen situation
in OSX so that our update doorhangers behave as if we're in
windowed mode, we aren't correctly listening for state changes.
This addresses that, and tries to limit the chattiness by only
listening to the fullscreen events that we care about.
MozReview-Commit-ID: 9J009l4w21E
While we are now correctly evaluating the fullscreen situation
in OSX so that our update doorhangers behave as if we're in
windowed mode, we aren't correctly listening for state changes.
This addresses that, and tries to limit the chattiness by only
listening to the fullscreen events that we care about.
MozReview-Commit-ID: 9J009l4w21E
