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
On OSX we want to show doorhangers when in fullscreen, since OSX
fullscreen doesn't hide the nav toolbox. This makes that change,
and also adds flip="slide" to the panel so that the arrow adjusts
correctly. Unfortunately there still seems to be a bit of a
problem with this where the doorhanger adjusts its position when
entering fullscreen but then waits a little bit (not sure what
triggers it) before updating the anchor arrow. This is tracked by
Bug 1368094.
MozReview-Commit-ID: 3dRLwgMjxIb
This also fixes two issues I found whilst writing the tests:
1. Exclude hidden items from the set of navigable buttons and
2. Exclude disabled items from the set of navigable buttons whilst navigating,
because they may get disabled in the meantime (like with the edit controls).
MozReview-Commit-ID: 5WThVoTZjbV
Right now, app menu doorhangers/badges have their state managed
directly inside panelUI.js. This is problematic because these
doorhangers and badges usually have to do with Firefox itself,
and not the specific window that's showing them. Accordingly, the
simplest solution was to move panelUI.js's notification state out
into a jsm file, which will fire notifications that all panelUI
instances can listen to.
MozReview-Commit-ID: 7b8w1WsQ29p
