Regression: The new swipe-to-navigation indicator stucks for a moment, when deciding not to navigate the other page

Nightly 111.0a1 (2023-01-24) (64-Bit)
macOS 12.6.3

1.) Open a new tab
2.) Visit a page in that tab
3.) Do the swipe back gesture with the Trackpad a little bit and decide not to navigate and lift the fingers up from the Trackpad

Actual: The last part of the new indicator stucks for a moment before it disappears.

Expected: A smooth animation.

Maybe a little bit related to issue 1811871?

A demo is attached.

Thanks

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Set release status flags based on info from the regressing bug 1799563

:hiro, since you are the author of the regressor, bug 1799563, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Setting P3:S3 since I don't think this is particularly problematic.

The startPosition was -20, but the circle's radius was 50, meaning the
animation started with the first 5px of the circle on-screen. This
simply changes the startPosition to -25 so that it starts entirely
outside the viewport.

Here's a video demoing the fix: 111 stable on the left, my local version on the right.

This bug is still reproducible on the latest Nightly (v150, v152) both macOS (26.5) and Linux (Fedora 43) (Windows shares the same code path but I haven't tested on hardware).

The root cause: in updateAnimation() (browser-gestureSupport.js), the translate formula interpolates from translateStartPosition to translateEndPosition based on gesture progress. When the gesture animates back to zero (unsuccessful swipe), progress→0 means
translate→translateStartPosition. But |ranslateStartPosition| is smaller than the SVG icon width on every platform:

• macOS: icon is 25px wide, startPosition is -20 → 5px tail visible
• Linux/Windows: icon is 66px wide, startPosition is -40 → 26px tail visible

This tail sits at the window edge for the final frames of the return animation, then vanishes abruptly when collapsed is set at
progress=0. It's especially noticeable on HiDPI displays.

D172905 proposed fixing this by changing the start-position pref, but hiro noted that the start position is intentional by design and
suggested tweaking the end position of the transition instead. D172905 has been inactive since March 2023, so I'd like to propose an
alternative approach that follows hiro's suggestion:

Instead of changing the pref values, adjust the translate computation to use an effective start position that guarantees the icon is
fully outside the viewport:

 let effectiveStart = Math.min(
 this.translateStartPosition,
 -(this._iconWidth + 1)
 );
 let translate =
 effectiveStart +
 progress * (this.translateEndPosition - effectiveStart);

this._iconWidth is read from the SVG width attribute in startAnimation().

This preserves the original pref values (the design-intended start position), but ensures the icon is fully hidden when the gesture
returns to zero. At progress=1 the translate equals translateEndPosition — no change from current behavior. The fix is cross-platform
— one code path for macOS, Linux, and Windows.

I have a patch ready. Would this approach be acceptable before I submit it for review?

When a swipe-to-navigate gesture is released without crossing the trigger
threshold, SwipeTracker animates gestureAmount back to 0, which causes
updateAnimation() in browser-gestureSupport.js to interpolate the icon
translate back toward translateStartPosition. On every platform
|translateStartPosition| is smaller than the SVG icon width, so the
trailing edge of the icon stays visible at the window edge for the final
frames of the return animation:

• macOS: icon is 25px wide, startPosition is -20 → 5px tail visible.
• Linux / Windows: icon is 66px wide, startPosition is -40 → 26px tail visible.

The tail is especially noticeable on HiDPI displays.

Bug 1799563 set translateStartPosition intentionally so a sliver of the
icon peeks in at the start of an inbound swipe (per the original Figma
design), so the start-position prefs are load-bearing and should not be
changed. That was the blocker on D172905, where the reviewer suggested
tweaking the end of the transition rather than the start position.

This patch keeps the prefs untouched and instead adjusts the translate
computation in updateAnimation() to use an effective start that
guarantees the icon is fully outside the viewport when the gesture
returns to zero:

effectiveStart = min(translateStartPosition, -(iconWidth + 1))
translate = effectiveStart + progress * (translateEndPosition - effectiveStart)

_iconWidth is read once from the SVG width attribute in
startAnimation(), so the value does not depend on layout and stays
correct while the box is collapsed. At progress = 1 the translate still
equals translateEndPosition, so the visible state of a successful swipe
is unchanged. At progress = 0 the icon is fully hidden on every platform,
in a single code path.

When a swipe-to-navigate gesture is released below the navigation
threshold, SwipeTracker sends a final update with aVal=0.
updateAnimation() then collapses both icon boxes, so
swipeEndEventReceived() -> stopAnimation() does not find a visible box
and skips the opacity transition.

Keep the existing cancel path in updateAnimation(), but remember the
last visible box and its translate before collapsing. stopAnimation()
can then restore that box and run the fade-out transition.

Use a delay-free opacity transition for cancelled gestures, since no
page navigation needs time to settle before hiding the icon.

https://hg.mozilla.org/mozilla-central/rev/8551f02addeb