1463235 - [History Swipe] New arrows don't appear when swiping quickly

Status: RESOLVED DUPLICATE of bug 1756801

(Firefox :: General, defect, P3)

Description

[Mehmet]

macOS 10.13.4
Nightly 62.0a1 (2018-05-21) (64-Bit)

1.) Visit some pages in succession in a tab
2.) Now put two fingers on the Trackpad and start slowly the swipe gesture for the History Swipe - but don't initiate the navigation to the previous page.
3.) In step 2 make sure, that the appearing arrow svg doesn't renders completely and swipe now back in the other direction so that the arrow disappears again.
4.) Now lift your finger from the Trackpad
5.) Put your fingers again on the Trackpad and now initiate quickly the history swipe to the previous page.

Actual: The arrow don't appear

Expected: The arrow should appear.

If you need more information, please let me know.

Thanks.

Comment 1

[Stephen A Pohl [:spohl] (OOO)]

This is due to the 0.2s CSS transition[1]. To fix this, we would need to interrupt the transition and allow for the arrows to become more opaque again right away.

[1] https://dxr.mozilla.org/mozilla-central/rev/dc1868d255be744a7d2d462216be205086cc60af/browser/base/content/browser-gestureSupport.js#634

Comment 2

[Mehmet]

Attachment: Screencast

Here is a screencast of the issue.

Comment 3

[Markus Stange [:mstange]]

This might be easier to do by using the Web Animation API instead of a CSS transition.

var animation = box.animate({ ... })
animation.onfinish = ...
animation.oncancel = ...

// in startAnimation:
animation.cancel();

Comment 4

[Stephen A Pohl [:spohl] (OOO)]

Attachment: wip

I gave this a shot today, but there is a significant glitch that I couldn't seem to fix: Once the transition to an opacity of 0 completes, the animation appears to snap back to full opacity before onfinished, i.e. _completeFadeOut is called, which then removes the box elements. This looks like flickering of the arrow at the end of the animation and isn't limited to fast swiping.

Markus, do you have any idea why this might be happening? I've tried numerous variations and wasn't able to fix this. By removing the onfinished callback I was able to confirm that the arrow does indeed snap back to full opacity at the end of the animation. My understanding was that this kind of animation should stop at the end of the animation rather than going back to the start of the animation. Is this assumption wrong?

Comment 5

[Stephen A Pohl [:spohl] (OOO)]

(In reply to Stephen A Pohl [:spohl] from comment #4)
> ... before onfinished

s/onfinished/onfinish/

Comment 6

[Markus Stange [:mstange]]

Comment on attachment 8985096 [details] [diff] [review]
wip

Hmm, that's a bit surprising to me, but I don't have a lot of experience with this API, so maybe it's expected. Can you check whether adding fill: "forwards" to the options makes a difference?

Comment 7

[Stephen A Pohl [:spohl] (OOO)]

(In reply to Markus Stange [:mstange] from comment #6)
> Comment on attachment 8985096 [details] [diff] [review]
> wip
> 
> Hmm, that's a bit surprising to me, but I don't have a lot of experience
> with this API, so maybe it's expected. Can you check whether adding fill:
> "forwards" to the options makes a difference?

It does indeed appear to fix this, thank you!

I'm able to make one of the arrows remain visible at full opacity by fast swiping back and forth several times. I will fix this before uploading a patch for review. Thanks again!

Comment 8

[Stephen A Pohl [:spohl] (OOO)]

(In reply to Stephen A Pohl [:spohl] from comment #7)
> I'm able to make one of the arrows remain visible at full opacity by fast
> swiping back and forth several times. I will fix this before uploading a
> patch for review. Thanks again!

This did not turn out to be as easy to fine-tune as I expected. I will have to come back to this.

Comment 9

[Mark Banner (:standard8)]

Comment on attachment 8985096 [details] [diff] [review]
wip

Clearing old feedback request as feedback was given with comments for a future follow up.

Comment 10

[Timothy Nikkel (:tnikkel)]

Are you still able to reproduce this? I tried and was not able to reproduce.

Comment 11

[Timothy Nikkel (:tnikkel)]

Actually, this sounds almost exactly like bug 1756801, so I think I've fixed this.

Comment 12

[Mehmet]

Attachment: Bildschirmaufnahme 2022-04-11 um 12.37.31.mov

(In reply to Timothy Nikkel (:tnikkel) from comment #10)

Are you still able to reproduce this? I tried and was not able to reproduce.

I can confirm that this is fixed now in Nightly. Thanks.

But I am noticing a flicker when the animation triggers now, which I can see in Nightly 101.0a1 (2022-04-10) (64-Bit), but not in Stable 99.0 (64-Bit).

Please see attached the screencast. Is this a known issue/regression?

Comment 13

[Timothy Nikkel (:tnikkel)]

Thanks for testing.

Yeah, I found that as well, it's caused by bug 1763643. Bug 1763815 is probably the same bug so I didn't file a new one.

Comment 15

[Mehmet]

(In reply to Timothy Nikkel (:tnikkel) from comment #13)

Thanks for testing.

Yeah, I found that as well, it's caused by bug 1763643. Bug 1763815 is probably the same bug so I didn't file a new one.

Thanks for the info. Following bug 1763815 now :)