[$250] Web - Reports - Unable to play video in Reports > Chats

[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: v9.3.60-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86915
Email or phone of affected tester (no customers): negasofonias+sof@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: WIndows 10/Chrome, Android A14
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Upload a video.
4. Go to Reports>Chats.
5. Click on the video.

Expected Result:

Video opens normally

Actual Result:

Video is corrupted and cant be opened

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @eVoloshchak

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044763060052277225
• Upwork Job ID: 2044763060052277225
• Last Price Increase: 2026-04-16

[MelvinBot]

Proposal

What is the root cause of that problem?

This issue was found during QA of Expensify/App#86915 (fix for #82894 — "Downloaded video has corrupted format"). That PR added a shouldResolveUrlFromApiRoot parameter to getValidatedImageSource and skips tryResolveUrlFromApiRoot() for SEARCH-type attachments in ReportAttachmentModalContent.tsx:110.

When a user navigates Reports > Chats (the Search view), PureReportActionItem sets type = CONST.ATTACHMENT_TYPE.SEARCH via AttachmentContext (PureReportActionItem.tsx:781). When the user clicks a video, VideoRenderer resolves the URL via tryResolveUrlFromApiRoot at line 21 before navigating to the attachment modal. In the modal, the PR's change skips re-resolving this already-resolved URL — which should be a no-op.

Key finding: The URL resolution and auth token paths appear correct. BaseVideoPlayer unconditionally attaches the encrypted auth token to all non-local video URLs at line 69, regardless of isAuthTokenRequired. The SEARCH type also correctly bypasses the not-found page check at line 114.

The most likely culprit is the shared video element mechanism. For SEARCH-type attachments, the modal renders a single AttachmentView (not the carousel) at AttachmentModalBaseContent/index.tsx:233, with shouldUseSharedVideoElement=true. BaseVideoPlayer physically moves the video DOM element between parent containers — if this transfer fails or the element state is corrupted during the transition from inline search preview to the full-screen modal, it would explain "corrupted" playback.

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

This needs runtime investigation to confirm the exact mechanism. Two approaches depending on findings:

1. If shared video element transfer is the issue: Disable shouldUseSharedVideoElement for the SEARCH-type attachment modal path (in AttachmentView when type === CONST.ATTACHMENT_TYPE.SEARCH), forcing a fresh video player instance instead of reusing the shared element.

2. If the URL is actually malformed at runtime (despite code analysis suggesting otherwise): Add logging or check browser network requests to see what URL the video player actually receives. If the URL is wrong, the fix would be in how getValidatedImageSource handles the source for SEARCH type.

What alternative solutions did you explore? (Optional)

• Verified the auth token path — BaseVideoPlayer unconditionally adds auth tokens, so this is not an auth issue.
• Verified the URL resolution path — VideoRenderer pre-resolves URLs and the encode/decode round-trip through route params is symmetric, so the URL should be correct.
• Checked for other entry points to the modal — only VideoRenderer and ImageRenderer open REPORT_ATTACHMENTS routes, and both pre-resolve URLs.

Related issues

• Expensify/App#82894 — "Reports - Web - Downloaded video has corrupted format" (the issue PR fix: Downloaded video has corrupted format #86915 was fixing, still open)
• Expensify/App#87921 — "Chat - Uploaded video cannot be played after 'Clear cache and restart'" (possibly related video playback issue)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[MobileMage]

Proposal

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

When a user uploads a video to a workspace chat and then navigates to Reports > Chats to click on it, the video appears corrupted and cannot be played in the modal.

What is the root cause of that problem?

The bug was introduced by a commit in PR #86915 that changed getValidatedImageSource(sourceParam, false) and was subsequently revised to getValidatedImageSource(sourceParam, type !== CONST.ATTACHMENT_TYPE.SEARCH) (commit a95032d4403). For REPORT-type attachments, this causes getValidatedImageSource to call decodeURIComponent on the sourceParam before passing it to the carousel as source. The carousel's compareImage function matches the currently-requested attachment by comparing attachment.source === source, where attachment.source is produced by extractAttachments via tryResolveUrlFromApiRoot(attribs[CONST.ATTACHMENT_SOURCE_ATTRIBUTE]) — a percent-encoded URL. After decodeURIComponent runs in getValidatedImageSource, the percent-encoding in the path (e.g. %20 for spaces in a filename) is decoded to literal characters, so the two strings no longer match. compareImage returns -1, page is set to -1, and the carousel renders no item — the modal shows a blank/broken video that the user perceives as "corrupted."

App/src/pages/media/AttachmentModalScreen/AttachmentModalBaseContent/index.tsx

Lines 233 to 244 in 06e4e74

	return !isEmptyObject(report) && shouldShowCarousel && type !== CONST.ATTACHMENT_TYPE.SEARCH ? (
	<AttachmentCarousel
	accountID={accountID}
	type={type}
	attachmentID={attachmentID}
	report={report}
	onNavigate={onNavigate}
	source={sourceProp}
	setDownloadButtonVisibility={setDownloadButtonVisibility}
	attachmentLink={currentAttachmentLink}
	onAttachmentError={setAttachmentError}
	/>

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

getValidatedImageSource should not call decodeURIComponent on a URL that is already a fully-resolved HTTPS string coming from the router, because React Navigation already decodes query-param values before they arrive in route.params. The double-decode converts percent-encoded path characters (e.g. %20 → ) and produces a URL that cannot match the percent-encoded source stored by extractAttachments. The fix is to skip decodeURIComponent when the source is a fully-qualified HTTP(S) URL, ensuring it matches what extractAttachments produces.

App/src/libs/AvatarUtils.ts

Lines 113 to 127 in 06e4e74

	function getValidatedImageSource(source: AvatarSource | undefined, shouldResolveUrlFromApiRoot = true) {
	const numberSource = Number(source);
	if (!Number.isNaN(numberSource) && numberSource !== 0) {
	return numberSource;
	}
	if (typeof source === 'string') {
	const decoded = decodeURIComponent(source);
	return shouldResolveUrlFromApiRoot ? tryResolveUrlFromApiRoot(decoded) : decoded;
	}
	return undefined;
	}

 function getValidatedImageSource(source: AvatarSource | undefined, shouldResolveUrlFromApiRoot = true) {
     const numberSource = Number(source);

     if (!Number.isNaN(numberSource) && numberSource !== 0) {
         return numberSource;
     }

     if (typeof source === 'string') {
-        const decoded = decodeURIComponent(source);
-
-        return shouldResolveUrlFromApiRoot ? tryResolveUrlFromApiRoot(decoded) : decoded;
+        // Only decode if the source is not already a fully-resolved HTTP(S) URL.
+        // React Navigation already decodes query-param values, so calling decodeURIComponent
+        // again on an HTTPS URL would convert percent-encoded path characters (e.g. %20 → space)
+        // and break carousel source matching against extractAttachments output.
+        const isFullUrl = source.startsWith('http://') || source.startsWith('https://');
+        const normalized = isFullUrl ? source : decodeURIComponent(source);
+
+        return shouldResolveUrlFromApiRoot ? tryResolveUrlFromApiRoot(normalized) : normalized;
     }

     return undefined;
 }

This preserves the decodeURIComponent call for relative or legacy paths (the email-entry-point case that commit a95032d4 was protecting), while keeping fully-resolved HTTPS URLs unchanged so they remain comparable to the percent-encoded sources stored in extractAttachments.

What alternative solutions did you explore? (Optional)

An alternative would be to normalize both sides of the compareImage comparison in AttachmentCarousel by decoding the attachment source before comparing. However, that approach spreads URL normalization logic into the carousel and risks breaking other consumers of attachment.source. Fixing the decode step in getValidatedImageSource is narrower and addresses the root cause at the point where the URL enters the component tree.

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

After uploading a video to a workspace chat and then navigating to Reports > Chats to click it, the video opens in the attachment modal but appears corrupted and cannot be played.

What is the root cause of that problem?

The bug was introduced by PR #86915 (commit a95032d44038). That PR changed the source resolution logic in ReportAttachmentModalContent to skip tryResolveUrlFromApiRoot for SEARCH-type attachments, since VideoRenderer already resolves the URL before navigating:

App/src/pages/media/AttachmentModalScreen/routes/report/ReportAttachmentModalContent.tsx

Line 110 in 3546a2a

const source = useMemo(() => getValidatedImageSource(sourceParam, type !== CONST.ATTACHMENT_TYPE.SEARCH), [sourceParam, type]);

However, getValidatedImageSource always calls decodeURIComponent(source) before returning, regardless of shouldResolveUrlFromApiRoot:

App/src/libs/AvatarUtils.ts

Lines 120 to 123 in 3546a2a

	if (typeof source === 'string') {
	const decoded = decodeURIComponent(source);
	return shouldResolveUrlFromApiRoot ? tryResolveUrlFromApiRoot(decoded) : decoded;

The problem is a double-decode. On web (Chrome/Android mWeb), React Navigation decodes URL query-param values when parsing the route string — so sourceParam already equals the decoded source URL. Calling decodeURIComponent again decodes any percent-encoded characters still present in the URL path or query string (e.g. %2F → /, %26 → &, encoded GUIDs or filenames with special characters). This corrupts the URL structure, causing the video request to fail.

Note: for SEARCH type, the attachment modal skips the carousel entirely and renders AttachmentView directly (AttachmentModalBaseContent/index.tsx:233). This means the carousel's compareImage matching is not involved — the broken URL goes straight to the video player.

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

In getValidatedImageSource (src/libs/AvatarUtils.ts), skip decodeURIComponent when shouldResolveUrlFromApiRoot is false. That flag is only false for SEARCH-type attachments, where VideoRenderer has already produced a fully-resolved absolute URL — there is nothing to decode. The decode step is only needed when resolving relative or legacy URLs from email deep-link entry points (REPORT type, where shouldResolveUrlFromApiRoot = true).

Change:

const decoded = decodeURIComponent(source);
return shouldResolveUrlFromApiRoot ? tryResolveUrlFromApiRoot(decoded) : decoded;

To:

return shouldResolveUrlFromApiRoot ? tryResolveUrlFromApiRoot(decodeURIComponent(source)) : source;

This preserves existing REPORT-type behavior (decode then resolve, needed for email deep links with relative paths) and fixes SEARCH-type by returning the source as-is — exactly what VideoRenderer produced.

Scope boundaries: Change is a single line in src/libs/AvatarUtils.ts. Affects SEARCH-type attachment modal only (Reports > Chats video/image click). REPORT-type (direct chat view), email deep-link entry points, and download behavior are not affected. No API contract changes.

What alternative solutions did you explore? (Optional)

MobileMage's proposal identifies decodeURIComponent as the problem and proposes skipping it for full http(s):// URLs. The fix target is the same, but the mechanism described — a carousel compareImage mismatch between decoded and percent-encoded sources — does not apply here. For SEARCH type, the carousel is bypassed entirely (AttachmentModalBaseContent/index.tsx:233); the broken URL goes directly to AttachmentView and the video player. The fix in this proposal is narrower: tie the skip to shouldResolveUrlFromApiRoot rather than URL scheme detection, since the flag already encodes exactly the invariant needed ("this URL is pre-resolved, don't touch it").

An alternative would be to revert the SEARCH-type condition entirely and restore getValidatedImageSource(sourceParam) for all types (with shouldResolveUrlFromApiRoot = true). This would also fix playback, but it re-introduces the duplicate tryResolveUrlFromApiRoot call that PR #86915 deliberately removed, which was the root of the original download-corruption bug (#82894).

[KJ21-ENG]

@eVoloshchak I am not able to reproduce the issue on staging.

[hungvu193]

Dupe of #87921

[ProjectNOVACo]

Proposal

Please re-state the problem that we are trying to solve in this issue.
When uploading a video to workspace chat and then navigating to Reports > Chats, the video appears corrupted when clicked.

What is the root cause of that problem?
I dug into the code and found the issue in ReportAttachmentModalContent.tsx line 93. The source URL for videos is being processed with getValidatedImageSource, which is causing problems because it's not handling SEARCH-type attachments properly after recent changes.

The bug was introduced when PR #86915 modified how URLs are resolved, but it didn't fully account for the SEARCH attachment type. The current code assumes that all video sources need URL resolution, but in this case, it's causing corruption because getValidatedImageSource is altering the source incorrectly.

What changes do you think we should make in order to solve the problem?
Let's modify how we handle the source URL in ReportAttachmentModalContent.tsx. We need to skip using getValidatedImageSource for video attachments of type SEARCH:

// Change this line:
const source = useMemo(() => getValidatedImageSource(sourceParam), [sourceParam]);

// To this:
const source = useMemo(() =>
type === CONST.ATTACHMENT_TYPE.SEARCH ? SourceParam : getValidatedImageSource(sourceParam),
[sourceParam, type]
);

This change prevents the source URL from being modified incorrectly for SEARCH-type attachments, which should fix the video corruption issue.

I think this is a clean solution because it respects the original intent of PR #86915 while fixing the unintended side effect on videos in Reports > Chats.