Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Depends on D152951
Differential Revision: https://phabricator.services.mozilla.com/D150433
Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Differential Revision: https://phabricator.services.mozilla.com/D150433
I noticed that the current implementation is very short and easy to miss. Chrome is much longer. I tweaked it to what felt pretty good.
Although this seems like only an increase from 0.25s to 0.35s it's actually much longer than that because the cubic-bezier curve (viewable at https://cubic-bezier.com/#.07,.95,0,1 ) goes to zero almost immediately. The new curve (viewable at https://cubic-bezier.com/#.25,.1,.25,1 ) is closer to linear with an ease-in and an ease-out.
Differential Revision: https://phabricator.services.mozilla.com/D142818
We can get into a state where box.style.opacity = 1 but that hasn't been flushed to the style system yet, the style system thinks the value is 0, so when we set box.style.opacity = 0 later it won't cause any transition to start and transitionend will never happen and the ui element will never been shown with non-zero opacity.
We use getComputedStyle to flush the value to the style system, this has two positive effects. It means we will show the ui element with non-zero opacity as well as making sure the transition will happen and transitionend will be called.
I think getComputedStyle should only flush in the relevant subtree (two elements total) so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D142822
The patch for bug 1762875 stops us from calling SwipeTracker::StartAnimation if we are performing a navigation (but still call it if we aren't performing a navigation). This also has the effect of not calling SwipeTracker::SwipeFinished since it is triggered from StartAnimation. This means we don't null out nsBaseWidget::mSwipeTracker from the mWidget.SwipeFinished() call. This means that when the next pan that we want to track as a swipe then when we call nsBaseWidget::TrackScrollEventAsSwipe it will find the existing mSwipeTracker and call mSwipeTracker->CancelSwipe(), which sends a MozSwipeGestureEnd event. It would be okay if we didn't send the MozSwipeGestureEnd event in the case of a succesful navigation, the MozSwipeGesture event can serve the same purpose, but to send a MozSwipeGestureEnd when the _next_ swipe gesture is started does not seem like a good idea.
I noticed this while writing the test for bug 1762875.
To fix it just call SwipeFinished immediately when we get a successful swipe navigation. There are two side effects to consider: nulling out mSwipeTracker on the widget, and sending the MozSwipeGestureEnd event.
Nulling out mSwipeTracker on the widget seems fine, it's only there to track ongoing swipes. Since the current swipe is finished we don't need it anymore. However it brought up an issue where existing tests in widget/tests/browser/browser_test_swipe_gesture.js started failing. A test would finished immediately after a successful swipe navigation, remove the tab, and move on to the next test before the fade out animation could run. If the fade out animation had finished it would have called removeBoxes and removed the dom elements for the visual swipe arrows. So they stick around instead. Removing the tab seems to have disconnected these elements from the DOM. The structure above the swipe elements goes up to the hbox created here https://searchfox.org/mozilla-central/rev/dd404f43c7198b1076fe5d7e05b1e6b1a03bdfeb/browser/base/content/tabbrowser.js#2182 I don't know the tabbrowser code but I'm guessing that gets removed on removing a tab. So in order to fix this we always remove and re-create the boxes when we start a new animation. It should be safe to always do this and remove the isAnimationRunning early exit because we don't call startAnimation when we get a MozSwipeGestureStart event, so we should always want to start fresh when we get that event.
Sending the MozSwipeGestureEnd event means we need to be a bit more careful in stopAnimation. We don't want to do anything in stopAnimation if we are already stopping animation because the fade out will handle it, so we add a early return so that another stopAnimation call (which can come from a MozSwipeGestureEnd) won't cut off the animation prematurely.
Differential Revision: https://phabricator.services.mozilla.com/D145545
I think this is because this._completeFadeOut is a function but calling it from to handle the event isn't going to have any reference to this so it doesn't do anything.
Differential Revision: https://phabricator.services.mozilla.com/D142821
Apparently we should check each command specified by
browser.gesture.swipe.left or browser.gesture.swipe.right, it will be fixed
in bug 1707118.
Differential Revision: https://phabricator.services.mozilla.com/D113635
Unify two separate codepaths that do conceptually identical things. That is,
instead of having the widget code directly dispatch wheel and pinch gesture
events to Gecko, allow APZ to do it as part of it's handling of pinch inputs
when zooming is disabled.
The main difference is that the WidgetSimpleGestureEvent delta values come out
different, because they are based on the macOS event's magnification value,
rather than the (now deprecated) deltaZ value. This is actually better since it
makes the values consistent across platforms and allows removal of some ifdefs.
Differential Revision: https://phabricator.services.mozilla.com/D74640
This clarifies the intention of each caller, and opens up the possibility of converting the notificationbox element to a class that creates the DOM nodes on demand.
Differential Revision: https://phabricator.services.mozilla.com/D10577
--HG--
extra : rebase_source : e311dd7144cf9f7cd513761f97bb3dd0a35dce71
extra : source : 9532194794ba9c87025da92cf70f76c21a277220
In the frontend we need to know if XUL buttons in the toolbar were
triggered by a touch event, so we're passing on the inputSource
in the command event.
MozReview-Commit-ID: DMvgZULk9hT
--HG--
extra : rebase_source : c455c8ec77e439bf02c1e3e8d34a36e1fb5e3bd0
Unreachable code can be a sign of a mistake so we should turn this rule on.
MozReview-Commit-ID: LQphsNL7HBX
--HG--
extra : rebase_source : eb5fdb1157cac6e447492ac89bb15d83dc32eef6
