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
Original patch authored by Tim Nguyen (:ntim).
MozReview-Commit-ID: 6qQnRMQXPTH
--HG--
extra : rebase_source : 319d160f3057173359f02adba44bdcc12a68e209
The bug has something to do with ContainerLayer nesting changes being mishandled:
a new ContainerLayer for the transform is being inserted around the container
layer for the opacity, which has an intermediate surface.
This change makes the outer ContainerLayer permanent so that the dynamic
insertion case is not hit.
MozReview-Commit-ID: lETpsr4YJi
--HG--
extra : rebase_source : 7b82976c7c91328c72b54a931732447d82a3ce6d
Original patch authored by Tim Nguyen (:ntim).
MozReview-Commit-ID: 6qQnRMQXPTH
--HG--
extra : rebase_source : f85e763cc130a71ba0f4bda228a874ebf65b84be
Migrated to simply use PopupNotifications.jsm. Additionally, this
changes the behavior to always have two buttons and a remember
checkbox. When selecting allow with remember, it will behave like
the always allow option previously, but when selecting block with
remember, it will move that page into a quiet mode with respect
to Flash - i.e., no plugin overlays will show anymore, and instead
you will just see the plugin icon in the URL bar, which you can
continue to interact with as before.
MozReview-Commit-ID: EUFlI7nM09t
--HG--
extra : rebase_source : 4f6fdaa602ea6c398cc646ba98282ee5c154956e
The patch adding support for specifying theme icons had a bug in the CSS: it
added styles for the action in a menu-panel depending on theme, but missed out
the theme pseudo-class selectors. Therefore the dark text icon was always used
since it was last in the CSS.
Additionally, the menu panels can't be styled, so still have light backgrounds
and dark text even in light text themes. If a light icon is used in the menu
panel in a light text theme it will be hard to see.
Thus, this patch adds the pseudo-class for dark text themes, but removes the
selector entirely for light text themes.
MozReview-Commit-ID: AmKVDYwGGKj
--HG--
extra : rebase_source : 3e88af5b0ad27b22e5b4456ee980fd60b6498c8a
* 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
* Add -moz-window-drag: drag property to toolbars in toolkit, on Windows as support was added in bug 1163113
* Use the toolbar-drag binding for #nav-bar on Linux.
MozReview-Commit-ID: 8ZABYMWswk1
--HG--
extra : rebase_source : 28c2fceef4991d4684c8249a787995994af1120d
