Right now it uses extends="xul:button" so that the element it wraps doesn't get
mouse events. There's a way to do that with CSS, using pointer-events: none on
the child.
MozReview-Commit-ID: GKLG62HDD7l
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
***
Bug 1454202: Part 1a - Auto-replace uses of callback-based AddonManager APIs with Promise-based versions. r=aswan
This was done using the following script:
4cd5ae9597/processors/aom-api-generators.jsm
MozReview-Commit-ID: 8hobLz15a66
***
Bug 1454202: Part 1b - Manually fix eslint errors after auto-rewrite. r=aswan
This also deletes an obsolete test whose xpcshell variant was already deleted.
MozReview-Commit-ID: DM9W9Q2SVIE
***
Bug 1454202: Part 1c - Manually fix non-eslint issues after auto-rewrite. r=aswan
MozReview-Commit-ID: DtMscWZuExc
--HG--
extra : rebase_source : d4c2f80bdf02ec4a07e3713a9ae1823145d25942
In addition to removing the unnecessary return value and the logic that may anchor the panel to anything other than the main menu button, this also fixes the asynchronous error handling.
MozReview-Commit-ID: KaUKYUhrUoc
--HG--
extra : rebase_source : 25dd26a850654c9c6762dc41dc0ac7ae3f0199eb
extra : amend_source : 74c9a5dd5fed72e7afd8e4028eef9e8cea00a17a
extra : source : 3ee2aed561555aecd1349412e9ccc228b7c91f3b
The shims that this rule tests for no longer exist.
MozReview-Commit-ID: DMgP7Hczavc
--HG--
extra : rebase_source : 765ddd5c62c9449c07ed050e44d86a3bd5c0ae64
extra : amend_source : 627a7694ac07182200f876901ded7a34721cd228
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
The UIState.ON_UPDATE notification should be enough to reset the state of the
panel every time the test is about to be executed. Wrong.
In response to this notification, gSync.onActivityStop() is called, which disables
the syncing animation immediately ONLY if it has been running for at least 1.5sec
(which is almost never happening in tests), otherwise we get a setTimeout with
the remaining time.
When the sync animation is running, we also do not react to clicks (disabled),
hence the test failing.
We fix this by stopping the animation ourselves manually at the end of the test,
so any subsequent test will start with a correct UI state.
MozReview-Commit-ID: CrEb82Tw5SO
--HG--
extra : rebase_source : da4822c9fb6f41e6fbfeec5a63086c43aeca7944
* 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
With the migration of Promise microtasks to the main microtask queue, promise
resolution handlers are now called immediately after any JS event listener
returns. The result of this is that in the case of the show() method, the
resolution handlers now run before the view's own popupshown handlers run and
the view is set active, which breaks handlers which expect it to act more
sensibly.
By deferring the resolution until the next tick, the resolution handlers are
called when the view is visible and in a consistent state.
MozReview-Commit-ID: C7697CBoHFt
--HG--
extra : rebase_source : a9d89920a14cc7a7c14da70bb07b35625769041a
extra : amend_source : 9439650fdc13dee24bb34c9c09d09a66697de7b6
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 {, <