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
In order to display the Library view sooner, the Recent Highlights section is populated asynchronously after the view is shown. When the Library button is moved to the overflow menu, this prevents the view height animation from including this section.
This can be worked around after the first time the view is opened, and is currently done by reusing the last known height. This logic causes issues with other subviews, but to fix this the Library view has to be changed to keep the existing highlight items while fetching the new ones.
MozReview-Commit-ID: AGs7nh4CsYE
* 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
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
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
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
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
Since we now have a store of notifications that is global across
all windows, it no longer makes sense to consume the API from
within browser.js. This patch moves the browser.js logic out into
a jsm file that is wired up through nsBrowserGlue, such that it
will be lazily instantiated on the first update event it would
receive[1].
We decided to move this into toolkit, as this piece of the
system is fairly generic and shouldn't differ between
applications.
[1]: There is a change to nsBrowserGlue to use "global[module]"
instead of this[module]. This mirrors the code for all the other
types of notifications, and I suspect it was just a latent bug,
since the original diff that includes this line makes no use of
it.
MozReview-Commit-ID: 8EQdM9BOpgl
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
This also improves the styling of checkbox buttons inside the menu and improves
support for adopting panelviews into the app menu from another area properly.
MozReview-Commit-ID: 1I9CeBx3zrz
