This also fixes the vertical offset because we take the correct branch in the yDiff if block lower down.
MozReview-Commit-ID: KbHkRx1575X
--HG--
extra : rebase_source : ed9189c10dd00badb4bce9982a7ba20b647cef98
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
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
--HG--
extra : rebase_source : ee2876f45ac16dc6c58d3373dfd2e3cc847dd593
When using "restore defaults", Customize mode unwraps all elements. The previous implementation
of _updateNewTabVisibility assumed that elements were wrapped in <toolbarpaletteitem>s when in
customize mode, but this isn't true during a reset. The new implementation just looks for the
<toolbarpaletteitem>s and their children as necessary.
MozReview-Commit-ID: FjNJ1n8foGi
--HG--
extra : rebase_source : c9de8a2a4d4dcf191281fead320acc2ddc1321d6
* 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
This allows dragging them via touch gestures.
I'm not adding this attribute to all tabs (so that you need
to select a tab before dragging it), because the tab
strip can also be scrolled with touch gestures and
the two touch move actions would easily conflict
otherwise. It would also make it easier to accidentally
mess up your tabs when touching your window somehow.
MozReview-Commit-ID: IVWQtVGFE9j
--HG--
extra : rebase_source : b4d616f45de4362d2fd505dacbf7176d12a04e37
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
Giving all these nodes ids doesn't seem like the right fix. `buildArea` already ignores skipintoolbarset
items before doing anything else with nodes, so bailing out early seemed like the right solution here.
MozReview-Commit-ID: H3EyqoospNR
--HG--
extra : rebase_source : 6dc06d18c82e2af5024be0aba271c270f7403839
Original patch authored by Tim Nguyen (:ntim).
MozReview-Commit-ID: 6qQnRMQXPTH
--HG--
extra : rebase_source : 319d160f3057173359f02adba44bdcc12a68e209
Original patch authored by Tim Nguyen (:ntim).
MozReview-Commit-ID: 6qQnRMQXPTH
--HG--
extra : rebase_source : f85e763cc130a71ba0f4bda228a874ebf65b84be
When the locale has a slightly longer label for 'Zoom', the popup auto-sizing
code starts having trouble with the inline start padding of that label and doesn't
size the popup correctly anymore.
When I change this to using a spacer element, this issue no longer occurs and the
label may become as large as localizers may need, as long as it doesn't exceed
the max-width of a panelview - 30em, currently.
MozReview-Commit-ID: CHRheMqazrj
--HG--
extra : rebase_source : 6e0441908617a954e782d8fcbbc16035e8c0e942
mconley helped with the initial setup here and they were reviewed by myself (jaws). His changes have been folded in to this patch since they didn't work as a standalone changeset.
MozReview-Commit-ID: E7U1ZciJl4D
--HG--
extra : rebase_source : 63400055b28fe15764190127996a0420c5f1f722
The only thing that I didn't remove was the process ID on the tab tooltip, which I find to be super helpful. For that, I changed the check from E10S_TESTING_ONLY to NIGHTLY_BUILD.
MozReview-Commit-ID: 2qNWebBpsMY
--HG--
extra : rebase_source : b30a4492f839186584c074b82a1969973cda48e0
The only thing that I didn't remove was the process ID on the tab tooltip, which I find to be super helpful. For that, I changed the check from E10S_TESTING_ONLY to NIGHTLY_BUILD.
MozReview-Commit-ID: 8wbjdYIC3gb
--HG--
extra : rebase_source : 2ea1b77d4a9fd9c3eb17853c8ec655b309a3fa8c
DevTools are adding a hidden menuitem "Enable DevTools..." that will be used to
propose an onboarding screen to users. This hidden button makes a customizable ui
test fail. It needs to be filtered out.
MozReview-Commit-ID: IX4SlpDHdsT
--HG--
extra : rebase_source : e2c9e26b27b1bf8788739f8d6384c19473ffdd23
The previous code here always set the `isActive` property on all themes. When writing the
patch for bug 1402981 I ran into issues because the default theme has an `isActive` property
anyway (it's a different type of object). So I tried to avoid setting `isActive` if it was
already present. Unfortunately, the result was that `isActive` values, once set, weren't
correctly updated. Worse, these values are (and were, prior to bug 1402981) persisted in
some cases.
There's no point persisting these values, all that will happen is that they'll start
mismatching the 'real' state of the world (LightweightThemeManager.currentTheme). So instead,
let's just not set the `isActive` property at all, and rely solely on the ID of the current
theme (or the default theme's ID, now that we no longer support non-lightweight-themes) to
establish whether any of the themes should appear selected or not.
MozReview-Commit-ID: 7rajS71FoQR
--HG--
extra : rebase_source : a99e04031ea9e122efdaf0436e354abe57439783
The third param of 'getTabsFragment' and 'getWindowsFragment' toggles whether the 'restore all' item
gets prefixed (true) or suffixed (false). The prefixed version doesn't get a separator, so this
seems like the simplest fix.
MozReview-Commit-ID: BzKWvndWUMp
--HG--
extra : rebase_source : 600af608c5c62ed000bec1778c05dcc75e7b8585
This moves the explanatory text from a pseudoelement to a real element,
and keeps only the image in a pseudoelement. It then uses a transitioned
opacity to fade that image in and out.
Because we need to fade this based on dragging items over the panel when
it's empty, it adds/removes a 'draggingover' attribute to handle the fade.
To cope with the extra element in the drag/drop container in customize mode,
this also makes the following changes:
- bail out of _onDragStart if there's no actual selected item.
- pick the fixed list in the panelHolder more reliably
- add a max-width to avoid the description making the panel wider
MozReview-Commit-ID: 9PEJSoJJ0Rp
--HG--
extra : rebase_source : 0a7865fcfd11eb5baca858cde71ea4e8b30d5afc
* 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
The margin rules for labels mean that if the See what's new link
starts its own line, the alignment looks off. We could override this,
but matching the styling for "Learn more" links, which get their own
line, seemed the better option.
MozReview-Commit-ID: 4WK9QtRMUQs
--HG--
extra : rebase_source : d24d83094d5b4ca400fe77358a3c1c2635e033d0
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
Rather than using left-hand-side at all times (which can go over the edge of the window
in some cases) this uses left or right-hand-side panels, always opening towards the
center of the window.
MozReview-Commit-ID: EvjDmKR1G5A
--HG--
extra : rebase_source : 12046edc24b564e035dff68a5e34bce3ff5fd507
Note that we will no longer show the panel if you use the context menu to move the item in one
window and have customize mode open in the other. I don't think that edgecase matters.
MozReview-Commit-ID: 3dzGr3cs2oQ
--HG--
extra : rebase_source : cc5f528557e35e48b0bc06e58b92fdcb7ecfa6fe
Delay the initialisation of the pref until the toolbar has been initialised.
MozReview-Commit-ID: JxQajZ4wrCR
--HG--
extra : rebase_source : 42f936c5a3e6b7f8cdce1703d7d74883fc806d1c
The highlight styling was recently added, causing update notification
buttons to both be styled as grey. This fixes that to style them as
blue again.
MozReview-Commit-ID: HDSA9NWBmIA
--HG--
extra : rebase_source : f9bbe50bb7115b1a2be6aff8fe930bf6c9844dbb