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