[Due for Payment now] [$250] Android - DM - Video progress bar disappears when trying to seek

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.16-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #81732
Email or phone of affected tester (no customers): applausetester+ap3@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung a31
App Component: Other

Action Performed:

1.Go to Inbox tab
2.Open any DM chat
3.Add a video attachment
4.Send the message
5.Tap Play on the video
6.Try to drag the progress bar forward or backward

Expected Result:

User can drag the progress bar to seek forward or backward in the video.

Video playback position updates according to the selected point in the progress bar.

Actual Result:

When trying to drag the progress bar, it disappears.

User is unable to seek forward or backward in the video.

Video can only be played from the current position without manual seeking.

This behavior occurs only on Android; Web and iOS allow seeking correctly.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022037291803785028442
• Upwork Job ID: 2037291803785028442
• Last Price Increase: 2026-03-26

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @QichenZhu (External)

[melvin-bot]

Triggered auto assignment to @sonialiap (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022021286851020563878

[btkcodedev]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-11 08:13:31 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Android, seeking in the send-attachment preview (and other video views) causes the progress bar to disappear during drag or buffering. Additionally, the loading indicator can cover the controls and linger after playback resumes. The goal is to keep the progress bar visible while seeking and buffering, and to dismiss the loading indicator immediately when playback resumes.

What is the root cause of that problem?

• The controls are hidden whenever shouldShowLoadingIndicator is true, which removes the progress bar during buffering. This happens in the controls render gate in BaseVideoPlayer.tsx.
• The auto-hide logic does not account for active seek interactions, so controls can be hidden mid-drag when loading starts. This is controlled by hideControl and its debounce in BaseVideoPlayer.tsx.
• The loading indicator visibility is derived from isPlaying on the ref, which can lag during buffer transitions, leaving the loader visible after playback resumes. This is in BaseVideoPlayer.tsx.

What changes do you think we should make in order to solve the problem?

1. Keep controls visible during seek and buffering.

• Track active seek state and prevent auto-hide while dragging in BaseVideoPlayer.tsx.
• Force controls to stay visible when drag starts in BaseVideoPlayer.tsx.
• Ensure controls remain visible while loading by canceling hide and forcing SHOW when shouldShowLoadingIndicator is true in BaseVideoPlayer.tsx.
• Allow controls to render even when loading is true by removing the loading gate in BaseVideoPlayer.tsx.

2. Make loader dismissal immediate after playback resumes.

• Track playback state using the playingChange event and use it for loading indicator logic in BaseVideoPlayer.tsx and BaseVideoPlayer.tsx.

3. Improve drag detection timing on Android.

• Call drag start from the progress bar touch start to avoid late pan recognition in index.tsx.
• Pass drag callbacks through the controls layer in index.tsx.

Code changes summary (paths and key edits)

• ~/App/src/components/VideoPlayer/BaseVideoPlayer.tsx

  • Added isProgressBarBeingDragged and isPlayingState state.
  • shouldShowLoadingIndicator uses isPlayingState.
  • hideControl skips while dragging.
  • handleProgressBarDragStart forces SHOW and cancels hide.
  • New effect: keep controls visible while loading.
  • Controls are rendered even when loading is true.

• ~/App/src/components/VideoPlayer/VideoPlayerControls/ProgressBar/index.tsx

  • Added onDragStart / onDragEnd props.
  • Call onDragStart on touch start and in pan begin.
  • Call onDragEnd on pan finalize.

• ~/App/src/components/VideoPlayer/VideoPlayerControls/index.tsx

  • Added onProgressBarDragStart / onProgressBarDragEnd props.
  • Pass drag callbacks to ProgressBar.

What alternative solutions did you explore? (Optional)

None

Test branch

btkcodedev/82026AndroidVideoSeek

Test results

Tested and verified the solution.
Both attachment viewer and send attachment viewer reuse BaseVideoPlayer, thus checked both.
Sorry about the lag in loading time - Phone is a little older.

screen-20260211-133552.mp4

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-16 17:03:37 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

When trying to drag the progress bar, it disappears. User is unable to seek forward or backward in the video. Video can only be played from the current position without manual seeking. This behavior occurs only on Android; Web and iOS allow seeking correctly.

---

What is the root cause of that problem?

1. Pan gesture activates after movement: The video progress bar uses a Pan gesture from react-native-gesture-handler. By default, Pan requires a minimum finger movement before it "activates." On Android, until the gesture activates, the touch is not fully claimed by the gesture handler. The overlay that contains the progress bar is a sibling of a PressableWithoutFeedback that wraps the video area and toggles control visibility on press. When the user touches the progress bar and starts to drag, the touch (or the release) can be delivered to that Pressable, which calls toggleControl() and hides the controls—including the progress bar.

2. Touch events bubble to parent Pressable: Even with .minDistance(0), on Android Native, when the Pan gesture ends, the touch event can still bubble up to the parent PressableWithoutFeedback, triggering its onPress handler which calls toggleControl() and hides the controls.

3. Small touch target: The progress bar track has a height of 4px. On Android, the user's finger is more likely to land slightly outside the bar or the gesture's hit area, so the touch is delivered to the underlying Pressable instead of the progress bar's GestureDetector, again causing the controls to hide.

4. Limited seek functionality: The current implementation uses event.x (relative position from gesture start), which only allows dragging from the current playback position. Users cannot tap/click anywhere on the bar to jump to that position (like YouTube), making seeking less intuitive.

5. Continuous seeking during drag: The video seeks on every drag movement, causing loading/buffering issues and poor performance during scrubbing.

---

What changes do you think we should make in order to solve the problem?

Proposed solution:

1. Set .minDistance(0) on the Pan gesture so it activates on touch down, capturing the touch immediately.
2. Add .shouldCancelWhenOutside(false) to prevent the gesture from being cancelled when dragging outside view bounds.
3. Wrap the Pan gesture in Gesture.Exclusive() to completely block touch events from bubbling to the parent PressableWithoutFeedback, preventing it from calling toggleControl().
4. On Android only, give the progress bar container a minimum touch target (minHeight: 44) so the draggable area is easier to hit and the gesture reliably receives the touch instead of the Pressable underneath.
5. Implement YouTube-style seeking: Use absoluteX on initial touch to allow tapping/clicking anywhere on the bar, then track drag movements with changeX for smooth scrubbing.
6. Defer seeking until release: Only update the visual progress bar during dragging, and perform the actual video seek operation once when the user releases (in onFinalize), preventing loading issues and improving performance.

All changes are in one file: App/src/components/VideoPlayer/VideoPlayerControls/ProgressBar/index.tsx.

---

Summary

Root causes:

1. On Android, the progress bar's Pan gesture did not activate on touch down, and the touch target was small, causing the overlay's sibling Pressable to receive the touch and hide the controls.
2. Touch events bubbled to the parent PressableWithoutFeedback after the gesture ended, triggering toggleControl() and hiding the controls.
3. Limited seek functionality using event.x prevented tapping anywhere on the bar to jump to that position.
4. Continuous seeking during drag caused loading/buffering issues.

Fixes implemented in ProgressBar/index.tsx:

1. Add Platform import
2. Add shared values for position tracking (sliderLeftOffset, currentProgressPosition)
3. Rename and update progressBarInteraction to updateProgressBar with YouTube-style seeking logic using absoluteX and changeX
4. Call .minDistance(0) on the Pan gesture so it activates on touch down
5. Add .shouldCancelWhenOutside(false) to prevent gesture cancellation when dragging outside bounds
6. Wrap Pan gesture in Gesture.Exclusive() to block touch events from bubbling to parent Pressable
7. Update onBegin to calculate slider offset and update visual only
8. Update onChange to track drag movements and update visual only
9. Update onFinalize to perform the actual seek operation once on release
10. On Android only, set minHeight: 44 on the progress bar container for easier touch targeting

Test Branch

Link

[QichenZhu]

@btkcodedev, can you share a video showing it works? It doesn't work for me.