[$250] console error while playing video attachment

[m-natarajan]

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.31-5
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @rojiphil
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open a workspace chat.
2. Add video attachment (app. 10MB size)
3. In the report action for attachment, start playing the video attachment.
4. While the video is playing, change the seek position repeatedly

Expected Result:

No console error should get displayed.

Actual Result:

Following console error is displayed
AbortError
The play() request was interrupted by a call to pause(). https://goo.gl/LdLk22

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

84197-web-chrome-002.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abzokhattab

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029614022620435044
• Upwork Job ID: 2029614022620435044
• Last Price Increase: 2026-03-05

[melvin-bot]

Triggered auto assignment to @lydiabarclay (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.

[MelvinBot]

Proposal

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

When playing a video attachment in a workspace chat and repeatedly changing the seek position via the progress bar, the browser console displays: AbortError: The play() request was interrupted by a call to pause(). This happens on Chrome and Safari (web platforms).

What is the root cause of that problem?

The HTML5 video.play() method returns a Promise. If pause() is called (or the browser internally pauses due to seeking) before that Promise resolves, the browser rejects it with an AbortError. The expo-video library's web implementation (VideoPlayer.web.tsx) calls HTMLVideoElement.play() in its play() method but discards the returned Promise entirely — the method signature is typed as void, and the Promise is never .catch()-ed.

The specific trigger is in the ProgressBar component (src/components/VideoPlayer/VideoPlayerControls/ProgressBar/index.tsx). The Pan gesture handler:

1. onBegin: Calls pauseVideo() then seeks to the touched position
2. onChange: Updates currentTime on every drag event (no debouncing)
3. onFinalize: Calls playVideo() if the video was previously playing

When the user rapidly re-grabs the seek bar after releasing it, the sequence becomes: play() → immediate pause() → play() → immediate pause(), causing the pending play() Promise to be interrupted each time. The unhandled rejection surfaces as the console error.

There are actually 5 separate locations in expo-video's VideoPlayerWeb that call HTMLVideoElement.play() without catching the Promise: play(), onplay listener, _synchronizeWithFirstVideo(), replace(), and replay().

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

Patch expo-video's VideoPlayerWeb (via patch-package) to wrap every HTMLVideoElement.play() call with a .catch() that silently swallows AbortError while re-throwing any other errors. This is the standard fix recommended by Chrome's documentation for this exact error.

For each of the 5 call sites in VideoPlayer.web.ts, change:

video.play();

to:

video.play()?.catch((e) => { if (e.name !== 'AbortError') throw e; });

This handles the root cause at the library level, covering all code paths — not just the seek bar scenario.

What alternative solutions did you explore? (Optional)

1. Fix only in the ProgressBar: Add a flag or debounce to prevent playVideo() from being called when another gesture begins immediately. This would fix the specific seek-bar scenario but leave the other 4 unhandled play() call sites in expo-video vulnerable to the same error in other contexts (e.g., replace(), replay(), video synchronization via onplay).

2. Debounce/throttle seek operations: Reduce the frequency of currentTime assignments during drag. This would reduce the likelihood of the error but not eliminate it, since the core issue is the unhandled Promise from play().

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[abbasifaizan70]

Proposal

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

1. Open a workspace chat.
2. Add a video attachment.
3. Start playback in the report action attachment.
4. While the video is playing, repeatedly change the seek position.

Console shows:
Uncaught (in promise) AbortError: The play() request was interrupted by a call to pause().

What is the root cause of that problem?

The seek gesture intentionally pauses on drag start and resumes on drag finalize. During rapid scrubbing, this creates overlapping pause() and play() operations in a short window.

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

Lines 52 to 67 in 9d50c7a

	.onBegin((event) => {
	setIsSliderPressed(true);
	checkIfVideoIsPlaying(onCheckIfVideoIsPlaying);
	pauseVideo();
	progressBarInteraction(event);
	})
	.onChange((event) => {
	progressBarInteraction(event);
	})
	.onFinalize(() => {
	setIsSliderPressed(false);
	if (!wasVideoPlayingOnCheck.get()) {
	return;
	}
	playVideo();
	});

The playback context playVideo calls player.play() without handling promise rejection. On web, interrupted autoplay/playback transitions reject this promise with AbortError, which becomes an uncaught promise rejection in console.

App/src/components/VideoPlayerContexts/PlaybackContext/usePlaybackContextVideoRefs.ts

Lines 8 to 10 in 9d50c7a

	const playVideo: PlaybackContextVideoRefs['play'] = useCallback(() => {
	currentVideoPlayerRef.current?.play();
	}, []);

Shared playback entry points (for example, shared element autoplay) call into the same video.play() action, so this missing rejection handling affects multiple seek/play paths.

App/src/components/VideoPlayerContexts/PlaybackContext/index.tsx

Lines 90 to 92 in 9d50c7a

	if (!shouldNotAutoPlay) {
	video.play();
	}

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

In usePlaybackContextVideoRefs, normalize play() handling so promise rejections from interrupted playback are safely consumed at the context boundary.

App/src/components/VideoPlayerContexts/PlaybackContext/usePlaybackContextVideoRefs.ts

Lines 8 to 10 in 9d50c7a

	const playVideo: PlaybackContextVideoRefs['play'] = useCallback(() => {
	currentVideoPlayerRef.current?.play();
	}, []);

const playVideo: PlaybackContextVideoRefs['play'] = useCallback(() => {
    const playResult = currentVideoPlayerRef.current?.play() as Promise<void> | undefined;

    // During rapid seek interactions, pause() can interrupt play() on web and reject with AbortError.
    // This is expected behavior and should not surface as an uncaught console error.
    playResult?.catch?.(() => {});
}, []);

This keeps the existing UX (pause on drag, resume after seek) while preventing noisy unhandled rejections in console when users scrub quickly.

Demo

Screen.Recording.2026-03-06.at.1.17.18.AM.mov