Don't render videos with relative or invalid URLs, show the error in development builds

[Eugene (OEvgeny)]

Video attachments, video cards, and animation cards threw an error when the video URL was relative or could not be parsed, which hid the whole card, including its title, text, and buttons.

Changelog Entry

Fixed

• Fixed video and animation cards disappearing in production builds when the video URL is relative or invalid, in PR #5889, by @OEvgeny

Description

VideoContent called new URL(src) to detect YouTube and Vimeo links, which throws for relative URLs and URLs that cannot be parsed, so the whole attachment disappeared in every build. The src prop now requires an absolute URL: development builds fail prop validation and show the existing error for an attachment that fails to render, and production builds, which do not validate props, leave out the video and show the rest of the card. YouTube and Vimeo URLs without a video ID are no longer embedded and play in <video>, like other URLs that cannot be embedded.

Design

• Relative URLs, including //host/..., are never resolved or requested, because they would point to a different server in each chat client.
• Development builds reuse the existing error for attachments that fail to render, which replaces the whole card; production builds show the card without the video.
• Open question: images, audio, and video posters still pass relative URLs to the browser. Should they follow?

Specific Changes

• Attachment/VideoContent.tsx: src must be an absolute URL, render nothing if it cannot be parsed, embed YouTube and Vimeo only with a video ID
• Removed the <a href> URL parsing workaround for Internet Explorer
• Added Attachment/VideoContent.spec.tsx: production builds render nothing for relative and invalid URLs
• Added __tests__/html2/attachment/video.url.html: development builds show the error for relative and invalid URLs and never request them; YouTube and Vimeo URLs without a video ID play in <video>

• I have added tests and executed them locally
• I have updated CHANGELOG.md
• I have updated documentation

Review Checklist

This section is for contributors to review your work.

• Accessibility reviewed (tab order, content readability, alt text, color contrast)
• Browser and platform compatibilities reviewed
• CSS styles reviewed (minimal rules, no z-index)
• Documents reviewed (docs, samples, live demo)
• Internationalization reviewed (strings, unit formatting)
• package.json and package-lock.json reviewed
• Security reviewed (no data URIs, check for nonce leak)
• Tests reviewed (coverage, legitimacy)

[Eugene (OEvgeny)]

TODO: Can we have snaps for this, so we don't break it? Also, dark-green video could work better in this case.

[Eugene (OEvgeny)]

Done: the test now snapshots the video attachment, video card, and animation card with a relative URL, plus the player for an unparsable URL, using a dark green video (a player that cannot play is gray, so a loaded video stands out); the YouTube/Vimeo fallbacks load from the network, so they are asserted instead.

[Eugene (OEvgeny)]

This one is on hold. We're still figuring if we want relative URL support at all.

[Eugene (OEvgeny)]

This one can change direction to the opposite: don't render relative URLs surfacing the broken activity/attachment error in dev mode.

[Eugene (OEvgeny)]

Done: src now requires an absolute URL, so development builds fail prop validation and show the usual "render of attachment" error (console names the URL), while production builds leave out the video, keep the card, and never request the relative URL.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[William Wong (compulim)]

Nitpicking.

[William Wong (compulim)]

It's a bit "far" from where the relativeURLs are.

Later, we should consider split this test into multiple (relative, invalid, YouTube/Vimeo).

[Eugene (OEvgeny)]

Agreed, we'll split it into relative, invalid and YouTube/Vimeo tests in a follow-up PR after this one merges.