[Due for payment 2026-03-19] [$250] Attachments-Video is not playing when opened from the attachments history, play/pause blinks

[vincdargento]

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.11-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176710/test-cases/41236953
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 iOS 26.2
App Component: Other

Action Performed:

1. Sign in to ND
2. Create a chat with another user
3. Send some images and a video in the chat
4. Open and play the video, close it
5. Open any other attachment and navigate through the attachments until you reached the video

Expected Result:

The video starts playing, when opened from the attachments history

Actual Result:

Video can't be played if opened from the attachments history, play/pause button blinks. Sometimes the whole attachment or control modal at the bottom blink

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.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/~022029612432673873511
• Upwork Job ID: 2029612432673873511
• Last Price Increase: 2026-03-05

[melvin-bot]

Triggered auto assignment to @RachCHopkins (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 navigating through attachments in the carousel on iOS native and reaching a video by swiping (not opening directly), the video cannot be played. The play/pause button blinks, and sometimes the entire attachment or control modal at the bottom blinks.

What is the root cause of that problem?

There are two compounding bugs, both specific to native:

Bug 1: Double onNavigate call (native only)

In AttachmentCarouselView/index.native.tsx:49-52, onNavigate is called twice per page change:

if (onNavigate) {
    onNavigate(item);   // first call
}
onNavigate?.(item);     // duplicate call

The web version at index.tsx:109-111 correctly calls it only once. Each onNavigate triggers Navigation.navigate (via onCarouselAttachmentChange in ReportAttachmentModalContent.tsx:83), causing double route navigation per swipe. This creates unnecessary re-renders and route transitions that destabilize the video initialization flow.

Bug 2: Feedback loop in AttachmentView's video URL registration

The useEffect in AttachmentView/index.tsx:157-163 has currentlyPlayingURL, updateCurrentURLAndReportID, and playVideo in its dependency array, but only updateCurrentURLAndReportID is actually used in the effect body. This creates a feedback loop:

1. Swiping to a video triggers this effect, which calls updateCurrentURLAndReportID(videoURL, reportID)
2. This sets currentlyPlayingURL in the PlaybackContext, which changes the updateCurrentURLAndReportID callback reference (since currentlyPlayingURL is in its useCallback deps at PlaybackContext/index.tsx:66)
3. Both currentlyPlayingURL and the new updateCurrentURLAndReportID reference re-trigger the effect
4. Meanwhile, resetVideoPlayerData at PlaybackContext/index.tsx:97-119 also fires on currentlyPlayingURL change and may detect a route mismatch (since Navigation.navigate from the double onNavigate is async), triggering a full player reset that sets currentlyPlayingURL = null
5. This null value re-triggers the AttachmentView effect, restarting the cycle

Each cycle calls video.pause() then video.play(), toggling isPlaying which directly drives the play/pause button icon (VideoPlayerControls/index.tsx:112), causing the visible blinking.

An additional contributing factor: the native Pager computes isFocused from two separate state sources (Pager/index.tsx:136) -- activePageIndex (updated via useEffect with one render-frame delay) and activeAttachmentID (updated immediately). This causes isFocused to briefly be false for all pages during transitions, adding extra effect triggers. The web version avoids this by only checking activeAttachmentID.

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

1. Fix the double onNavigate call in AttachmentCarouselView/index.native.tsx:49-52: Remove the duplicate onNavigate?.(item) call at line 52, keeping only the guarded call at lines 49-51. This matches the web version's behavior.

2. Remove currentlyPlayingURL and playVideo from the AttachmentView useEffect dependency array at AttachmentView/index.tsx:163: These values are not used in the effect body and their presence creates the feedback loop. The effect should only re-run when isFocused, source, reportID, or updateCurrentURLAndReportID actually change in ways relevant to the effect's purpose.

3. Consider stabilizing updateCurrentURLAndReportID by removing currentlyPlayingURL from its useCallback dependency array in PlaybackContext/index.tsx:66. The function reads currentlyPlayingURL to decide whether to pause, but this could use a ref instead of a state dependency, preventing the callback reference from changing on every URL update.

What alternative solutions did you explore? (Optional)

• Synchronizing activePageIndex directly in the onPageSelected callback instead of via useEffect on initialPage in the Pager. This would eliminate the isFocused flicker but doesn't address the core feedback loop.
• Using useRef for currentlyPlayingURL inside updateCurrentURLAndReportID to avoid recreating the callback. This would stabilize the reference but still leaves currentlyPlayingURL as a direct dependency in the AttachmentView effect.

---

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]

Current assignee @abzokhattab is eligible for the External assigner, not assigning anyone new.