PanelMultiView has its own concept of "selected", so we should use this rather than move focus
using advanceFocusIntoSubTree.
MozReview-Commit-ID: DW2JqqggLl1
--HG--
extra : rebase_source : ec7a6f83fdda176f3286cf4395dc72de6cad2466
PanelMultiView has specific code to support keyboard navigation.
However, it only includes elements with class subviewbutton, which has visual styling.
Some views have controls which should be included in keyboard navigation, but for which the subviewbutton styling is not appropriate.
Therefore, also include elements with the new class subviewkeynav, which is specific to keyboard navigation and has no visual styling.
MozReview-Commit-ID: 8A5q9nbGpdc
--HG--
extra : rebase_source : 431fd2b1e2926e53002a45c290f9d88e8463c42c
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
* The extension content drives the sizing of the browser and popup that contains it via the Extension:BrowserResized message. The ignoreResizes property throttles/debounces this initially, stashing the dimensions received rather than triggering resize of the popup for every message. When the popup is a subview and fixedWidth, we ignore width but *do* want to use the stashed height value.
* Until the panel is given visibility, it has 0 height, so after setting visibility, wait until the next refresh-driver tick before measuring any header which should get added to the overall view height
MozReview-Commit-ID: AgcruVb9QPA
--HG--
extra : rebase_source : 429503a7d38559cc8670a3205b3290b8e0bbbfa2
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 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
