audio_video_progress_bar icon indicating copy to clipboard operation
audio_video_progress_bar copied to clipboard

Handle `onTap` separately than drag events

Open suragch opened this issue 3 years ago • 1 comments

Current Behavior

Currently the behavior is like so:

  • After the user lifts their finger from an drag event, onSeek is triggered at the duration position of the up event.
  • If a user taps the progress bar, onSeek is called at the duration position of the tap event.

This is the behavior of the audio player control in apps like Signal, Messenger, WhatsApp, Teams, YouTube web, and Music Speed Changer.

Proposed Behavior

However, some developers may wish to ignore onTap events or handle them differently than drag events. Here are some reasons:

  • Users might accidentally tap the progress bar and not want to seek to a new position.
  • Implement different behavior on a tap, for example, play/pause, collapsing the player, etc.

This is the behavior of YouTube mobile app, Netflix, and Spotify.

API

This could be implemented with an API like so:

onTap: (duration) {
  // handle tap event
},

If onTap is null then the behavior would default to the current behavior, that is, seek to the tap location.

Notes

This is a slight modification of the original proposal put forth by @thesensibledev. See the discussion in #44 and #49 for more details.

I'm writing this up to see how many developers need this feature. Give this issue a thumbs up if you are using the progress bar in your app and you want to handle onTap separately.

suragch avatar Oct 07 '22 05:10 suragch

This will help https://www.youtube.com/watch?v=IMQdSTlTXjA

BraveEvidence avatar Mar 15 '23 11:03 BraveEvidence