This prevents synchronous reflows when opening subviews. This also removes a superfluous invocation of the workaround while the panel is still hidden.
MozReview-Commit-ID: DohLjntVaPU
--HG--
extra : rebase_source : 8cd1b86168aee23d4e75556c2b11baf2c8dd0b9c
Views moved to a different panel and then moved back could be placed after the subviews they give access to, if the other subviews were not moved. The transition would be incorrect when these subviews are opened later.
MozReview-Commit-ID: 6JJa0p0McxL
--HG--
extra : rebase_source : 7e28c0638c46b26c45b1073d8a76173fa75fd5fa
The transition code now returns early if the panel was closed during an "await" statement.
Given that transitions can only be interrupted when closing the panel, and the _cleanupTransitionPhase method handles exclusively state related to the panel rather than the individual views, it is now possible to call the _cleanupTransitionPhase method only when the panel is hidden or at the end of a transition.
MozReview-Commit-ID: GYRKyyhJBPK
--HG--
extra : rebase_source : cd66a1e68d0f6cf0a371d7216d54e7d07b576529
This was added in bug 1354141 and is not needed anymore.
MozReview-Commit-ID: 42oF7LpCa6R
--HG--
extra : rebase_source : cd002b7052d14318efe4ef1ac6cc48fe30467265
The anchor state does not need to be cleaned up synchronously, so we can handle it seperately from the transition state.
MozReview-Commit-ID: 1CBP9OS5WmM
--HG--
extra : rebase_source : 533cee34a8f8e0e4bae00a4ff4eb00b9f330f7c1
We now use the "active" property of views to track whether navigation is possible. This has the advantage of being already handled correctly when views are moved to a different panel, and is in line with the purpose of the "active" state. The note about using the "popupshown" event for navigation has been updated accordingly.
Keyboard navigation is also linked to the "active" property now, so there is no need to track the state of the "_transitioning" property anymore.
Since the goBack and showSubView methods can only be called when the view is active, we don't need to check for attempts to start a transition while the panel is closed anymore.
MozReview-Commit-ID: 3KT3A5EwGFy
--HG--
extra : rebase_source : c338362923a7574210c7329bb84316d549898fdc
This allows the state to be handled correctly when views are moved to a different panel.
The "margin-inline-start" style property on the view stack is also reset unconditionally, allowing less state to be stored in the transition details object.
MozReview-Commit-ID: IpgnYsVvx0w
--HG--
extra : rebase_source : 222a398546da3c142f4051c88f5cf9b4da2b8e98
This makes the intent of the code clearer and hides the details of how the association is made.
MozReview-Commit-ID: C2L0vsjhxNO
--HG--
extra : rebase_source : 8ff0ef3463470ed909a60c788ec59eaefa6795a9
This was originally introduced in bug 1374749 but isn't needed anymore, and removing this allows making the _cleanupTransitionPhase method synchronous.
MozReview-Commit-ID: 6v78QoPXZoU
--HG--
extra : rebase_source : 1c089d8a9e4e6a1031a7d0337f3459b7c1e37117
The null check for the "node" property can also be removed since the caller already checks it synchronously.
MozReview-Commit-ID: 7FaCdtWTz20
--HG--
extra : rebase_source : 9162b3588b6085da5385a63401457192b1d9e690
The "ephemeral" attribute was not actually used anymore, because it is redundant with the "viewCacheId" attribute.
MozReview-Commit-ID: 6zxf2DmcEfI
--HG--
extra : rebase_source : b3fb5381152c8baaf8f77549e87723e1815f945f
Since we control the code path that invokes the PanelMultiView destructor, it is now possible to call the _moveOutKids function only as needed, avoiding some unnecessary DOM modifications when the browser window is closing.
MozReview-Commit-ID: JTJQmhZKFOh
--HG--
extra : rebase_source : cc3f1843cfd57e94bdf657aa033fbc9d5a086bf7
The main view is already included in the children of the view stack, so the code that moves it out separately can be removed. The "mainview" attribute is already set to the correct value the next time the view is opened.
MozReview-Commit-ID: B8LMAxWvvTb
--HG--
extra : rebase_source : ae8afd201782346e63772cdb62797b7069e0d3ac
The value "single" for the "closemenu" attribute on panel buttons is unused, so the only consumer of the "showingSubView" property can be removed.
MozReview-Commit-ID: 2jf5YE4Uyd
--HG--
extra : rebase_source : d1940fb7a470b42e0550c0e2876ad947d1c85d9d
This includes both canceling the ViewShowing event and calling the hidePopup method of PanelMultiView.
MozReview-Commit-ID: Goo45SEBC3z
--HG--
extra : rebase_source : d78376d7a69dd47157e049da1aaa19e97b9bd12c
This also adds a new "active" property that can be used by regression tests to determine whether they should still wait for the ViewShown event.
MozReview-Commit-ID: K25F09llooj
--HG--
extra : rebase_source : 9f6dad605243fcd3633260c4fa34011f9cfab27c
extra : source : 2dad70b2a723e67b45563dd3ac254911dd193439
This is made possible by a new workaround for a layout issue with panels that would prevent the main view from being displayed.
MozReview-Commit-ID: 3LGzq50QXt2
--HG--
extra : rebase_source : 2af636d4d93bf760b9ec4fd8b31ed77c715ab93f
extra : source : 9906b468eb78016aa4994b674da85bf7663c0285
This fixes an issue where the two transition are not simultaneous.
MozReview-Commit-ID: 8JKunQV3MDI
--HG--
extra : rebase_source : f272ab4c60de4361b44e71403806cd84436280db
This also adds a new "active" property that can be used by regression tests to determine whether they should still wait for the ViewShown event.
MozReview-Commit-ID: K25F09llooj
--HG--
extra : rebase_source : 8c9e2a86285be6453cd60b3da448876e6dfa7e8a
This is made possible by a new workaround for a layout issue with panels that would prevent the main view from being displayed.
MozReview-Commit-ID: 3LGzq50QXt2
--HG--
extra : rebase_source : 5e594347fc612af2b3ee44748dd44383aa08f1a5
window.promiseDocumentFlushed will call a callback as soon as a style or layout
flush is not required for the document (which might be immediately). This is a
new ChromeOnly API introduced in an earlier patch in this series.
This patch also removes the now-unneeded BrowserUtils.promiseLayoutFlushed and
BrowserUtils.promiseReflowed methods and infrastructure.
MozReview-Commit-ID: Jv7KoxBXhHG
--HG--
extra : rebase_source : b8c9ae40dbdd0f5587d03e8b7c0833bd94032a78
window.promiseDocumentFlushed will call a callback as soon as a style or layout
flush is not required for the document (which might be immediately). This is a
new ChromeOnly API introduced in an earlier patch in this series.
This patch also removes the now-unneeded BrowserUtils.promiseLayoutFlushed and
BrowserUtils.promiseReflowed methods and infrastructure.
MozReview-Commit-ID: Jv7KoxBXhHG
--HG--
extra : rebase_source : b8c9ae40dbdd0f5587d03e8b7c0833bd94032a78
This also updates the AppMenu mozscreenshots module to work with the Photon main menu.
MozReview-Commit-ID: FciQH815F95
--HG--
extra : rebase_source : 5c129b0d4aa824bbe899066f2bb197106d1c0408
This stops redundant ViewHiding and late ViewShown events from being dispatched when the panel is closed during a ViewShowing event or a transition, and stops dispatching ViewHiding events when a view becomes invisible but is still open.
The panelMultiView property on "panelview" nodes is now set to null when the view is closed, indicating that the view can be immediately reused in a different panel. The Places view had to be updated so it doesn't rely on this property during the PanelMultiViewHidden event.
MozReview-Commit-ID: B1yU6si3eD3
--HG--
extra : rebase_source : 440ddc3eabcbe9d0f02a172f8adf047c66ca53ac
The ViewHiding event is now dispatched consistently, regardless of whether the ViewShowing event is canceled or the panel is closed during the event. This is done by a new _openView helper, while the logic that is specific to each of the showMainView, showSubView, and goBack functions has been moved out of the _showView function.
MozReview-Commit-ID: 5WvW6THWbyb
--HG--
extra : rebase_source : 666c5744843f5197ab5130212096a1c83a2e3983
This allows the openViews array to reflect the state of the navigation more accurately, paving the way for further simplification of the code. The showSubView function will now fail early when it's called with a view that is already open, so the rest of the code doesn't have to take this case into consideration.
MozReview-Commit-ID: 1VoIImxVTDN
--HG--
extra : rebase_source : b483f9c7e2782f070f5694d85a91a0bfefff5457
extra : source : 7ce7a10fd212989eee76b482632eac9b985d4b2e
The ViewShowing event is now called earlier and unconditionally, since we don't set the "current" attribute and call showMainView while the panel is closing anymore.
It is already the case that the ViewShowing event handlers don't depend on the "current" property, so we don't need to keep track of it before ViewShown events are dispatched.
MozReview-Commit-ID: Ii4SN03KjwW
--HG--
extra : rebase_source : 5e994fa4d54b2805b5eb10d9471bbb25bd21f24c
The showSubView public method now aligns with its callers and doesn't return a Promise anymore. The showMainView method still returns a Promise because at the moment it is used externally for asynchronous cleanup.
MozReview-Commit-ID: FcnEx5f5HKh
--HG--
extra : rebase_source : dc0a8e5267b7211c7ee3e2216bd1dc0cabdbd4bd
extra : intermediate-source : 9cc3eafb24f3936eb8ccb359f2f04e9839ae9ff2
extra : source : 7ce7a10fd212989eee76b482632eac9b985d4b2e
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
This allows the ViewShowing event for the main view to prevent the panel from opening. It also avoids setting up the main view if the panel is not opened.
MozReview-Commit-ID: LK8tBcz6lkK
--HG--
extra : rebase_source : beb721ff996f11d7e162a4ff431c38b30bf42ca6
extra : source : c8115e90ffa8af27ef00cbd0f8da68dce7ce36bd
The only purpose of these bindings was to insert a stylesheet, which has been
moved to be included in toolkit/content/components.css.
MozReview-Commit-ID: 23jqkIrbVvi
--HG--
extra : rebase_source : 8d13f7a8afa730207d40e1457e36ec51331c4ea7
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
--HG--
extra : rebase_source : 856ef3715c924ca16e993ea57d92d1243b5cc6be
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This replaces all non-test usage of sanitize.js or legacy Sanitizer.jsm
to use the new Sanitizer.jsm module which does not hold internal state
and instead receives all configuration through function arguments (or by reading prefs).
MozReview-Commit-ID: KitMVptuIG3
--HG--
extra : rebase_source : e6696a5246db3f6ef9dd25aeab5d239d7fc7f8e3
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
This also fixes the clean up of the width and height properties of the viewContainer.
MozReview-Commit-ID: 28XQlUoLLCr
--HG--
extra : rebase_source : ce0df7ab26ce0212137003e2c700fac4d49e228d
extra : source : c06ebffb1795cf555f5ce609ab133b3bad594137
This also removes some unneeded checks for variables that are now never false.
MozReview-Commit-ID: KVVwARLrpYO
--HG--
extra : rebase_source : 5d6ebaabce6964fd57cda83685194e339f143865
This allows removing the separate keyboard navigation map.
MozReview-Commit-ID: 2N0wflAvg7Y
--HG--
extra : rebase_source : 63b9ae6e4db0de1957cb011c69134894d311b703
Only one method is moved to the PanelView class to simplify the keyboard navigation test.
MozReview-Commit-ID: CHB5FiT9ptn
--HG--
extra : rebase_source : ec588beae9f1208a37ce85f9d28029dfd979db24
This makes the code easier to follow and facilitates future refactoring, for example the set of known views can be removed entirely by making the clean up and navigation code use the stack of open views.
The SlidingPanelView class can thus be removed, saving various lines of code. The class implemented a small optimization for garbage collection, that was already less effective because various other objects are created during each view transition anyways.
MozReview-Commit-ID: Z4JJMklUMf
--HG--
extra : rebase_source : 8789a35c4234fc691c62efeb3445b776b14fc1f9
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
--HG--
extra : rebase_source : b527827d30d682d183981347c2caf3a8a5d81355
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