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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
