[$500] Add "expand" button overlay to charts for full-screen mode

[melvin-bot]

Overview

Add a tappable "expand" button overlaid on top of inline charts (e.g. in Concierge Anywhere) so users can view the chart in a full-screen modal — similar to how the video player's expand button works.

Design / Behaviour

• The expand button should sit overtop the chart in the top-right corner, overlaying it (not expanding/shrinking with the chart content area).
• Tapping the button opens a centered full-screen modal and renders the chart at full viewport width.
• The button captures pointer events so that any chart gesture layer (tooltips, etc.) underneath the button in that corner is suppressed — this is acceptable since charts don't render interactive elements in that corner.
• We cannot reuse the existing image attachment modal directly (charts aren't URL-based attachments), but we can reuse the same centered full-screen modal pattern.

Notes

• Once chart tooltips are added in the future, care should be taken to avoid conflicts between tooltip taps and the expand button.
• See Slack thread for full context on the design discussion.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064104217513250497
• Upwork Job ID: 2064104217513250497
• Last Price Increase: 2026-07-06

Issue Owner

Current Issue Owner: @abbasifaizan70

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dubielzyk-expensify (NewFeature)

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-08 22:06:43 UTC.

Proposal

What is the root cause of that problem?

Inline HTML charts are rendered by BaseVictoryChartRenderer as a pure chart view: it parses the <victorychart> tree, wraps it in VictoryChartProvider, and renders only VictoryChartContainer / VictoryChartContent. There is no expand button, no modal state, and no second render path for a larger chart.

Also, the existing responsive chart container is intentionally inline-only: it scales charts down to fit the message width and caps the scale at 1, so it never grows the chart for a full-screen viewer. That leaves users with only the small inline chart.

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

In the Victory chart renderer path, add a small wrapper around the inline chart:

• Keep rendering the inline chart through the existing VictoryChartProvider, VictoryChartContainer, and VictoryChartContent.
• Add an absolute top-right expand button using the existing Expand icon/tooltip style. Put it outside the chart content that may be transformed, so the button overlays the chart without shrinking or growing with the canvas. The pressable itself should sit above the chart and capture pointer events in that corner.
• On press, open a local centered full-screen modal using the existing centered modal pattern, with a close control.
• In the modal, render the same parsed chart data again, but use a modal-specific viewport scale based on the parsed chart width/height and the current window width. This should allow the chart to fill the modal width while preserving the chart's label/legend alignment. Keep the existing inline shrink-to-fit behavior unchanged.

Scope boundaries:

• Touch the HTML Victory chart renderer components/styles only, plus any needed localized label/sentry constant for the chart expand button.
• Apply to web, iOS, and Android because the renderer has both web and native entrypoints.
• Do not change backend/API behavior, chart HTML parsing, attachment modal routing, or search result chart views.

What alternative solutions did you explore? (Optional)

I considered reusing the attachment modal directly, but charts are rendered from parsed HTML and are not URL-based attachments. I also considered changing the global chart scaling cap, but that would alter inline chat layout; the safer approach is a separate modal-specific scale.

[melvin-bot]

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

[wildan-m]

Proposal

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

Inline charts (for example the Victory charts rendered in Concierge Anywhere messages) are rendered at the constrained width of a chat message and have no way to be viewed larger. We want to add a tappable "expand" button overlaid on the top-right corner of an inline chart that opens the chart in a centered full-screen modal at full viewport width, mirroring the behaviour of the video player's expand button.

What is the root cause of that problem?

This is a missing feature rather than a regression. Inline charts are rendered by the Victory chart HTML renderer, which renders only the chart itself with no overlay control and no full-screen presentation path:

App/src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/BaseVictoryChartRenderer.tsx

Lines 30 to 42 in b5363d7

	return (
	<ChartFontsProvider value={fonts}>
	<VictoryChartProvider
	tnode={tnode}
	processedResult={processedResult}
	type={type}
	>
	<VictoryChartContainer>
	<VictoryChartContent />
	</VictoryChartContainer>
	</VictoryChartProvider>
	</ChartFontsProvider>
	);

The chart is parsed from the message HTML node into a processed result and supplied to the chart components through VictoryChartProvider, then drawn by VictoryChartContainer / VictoryChartContent. There is no expand affordance overlaid on top of the chart, and unlike videos the chart is not a URL-based attachment, so the existing attachment/image modal (which keys off a source URL) cannot be reused to present it full-screen.

The video player already solves the equivalent problem: it overlays an Expand icon button in the top-right corner of the preview and, on press, opens the centered full-screen attachment modal:

App/src/components/VideoPlayerPreview/index.tsx

Lines 149 to 159 in b5363d7

	<View style={[styles.pAbsolute, styles.w100]}>
	<IconButton
	src={icons.Expand}
	style={[styles.videoExpandButton]}
	tooltipText={translate('videoPlayer.expand')}
	onPress={onShowModalPress}
	small
	sentryLabel={CONST.SENTRY_LABEL.VIDEO_PLAYER.EXPAND_BUTTON}
	/>
	</View>
	</View>

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

Add an overlay expand button on top of the inline chart and present a copy of the same chart in a centered full-screen modal when it is pressed. The work is contained to the Victory chart renderer.

1. In BaseVictoryChartRenderer, wrap the existing inline VictoryChartContainer/VictoryChartContent in a relatively-positioned container View and overlay an expand IconButton absolutely positioned in the top-right corner. Reuse the existing reusable icon button and the Expand Expensicon already used by the video player overlay, plus an overlay style modeled on videoExpandButton (absolute, top/right offset, rounded translucent background):

App/src/styles/index.ts

Lines 5388 to 5395 in b5363d7

	videoExpandButton: {
	position: 'absolute',
	top: 12,
	right: 12,
	backgroundColor: theme.videoPlayerBG,
	borderRadius: 8,
	padding: 8,
	},

Because the button sits on top of the chart and captures pointer events, any chart gesture layer underneath it in that corner is suppressed — acceptable per the issue, since charts do not render interactive elements in that corner.

2. Track a local isFullScreenVisible boolean state in the renderer. The expand button's onPress sets it to true.

3. Render a full-screen Modal using the same centered full-screen modal pattern the attachment modal uses (CONST.MODAL.MODAL_TYPE.CENTERED_UNSWIPEABLE), driven by isFullScreenVisible, with onClose resetting the state back to false:

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

Lines 43 to 46 in b5363d7

	<Modal
	isVisible={isVisible}
	type={modalType ?? CONST.MODAL.MODAL_TYPE.CENTERED_UNSWIPEABLE}
	initialFocus={() => {

Inside the modal, render a second copy of VictoryChartContainer/VictoryChartContent in a full-width container. Both the inline copy and the modal copy live inside the same VictoryChartProvider, so the already-parsed chart data is reused without re-parsing the HTML. The responsive chart container scales to the width of its parent, so inside the modal the chart fills the full viewport width:

App/src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/components/VictoryChartContainer/VictoryChartContainerResponsive.tsx

Lines 45 to 58 in b5363d7

	<View
	style={styles.mw100}
	onLayout={handleLayout}
	>
	<VictoryChartContainerFixed
	layout={layout}
	themeStyles={themeStyles}
	>
	{children}
	</VictoryChartContainerFixed>
	</View>
	);
	}

4. Add a generic "Expand" tooltip/accessibility label translation for the button (the existing "Expand" strings are namespaced to the video player and the compose menu, so a shared label is added rather than reusing those).

This keeps the change self-contained to the chart renderer, reuses the existing icon button, icon, overlay-style approach, and centered-modal pattern, and does not touch the unrelated attachment/image modal pipeline.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/92969-chart-expand-fullscreen?expand=1

What alternative solutions did you explore? (Optional)

• Routing the chart through the existing ROUTES.REPORT_ATTACHMENTS attachment modal (as videos do). Rejected because that modal resolves content from a source URL/attachment record, and inline charts are HTML-described, not URL-based attachments — it would require synthesizing a fake attachment, which is more invasive than rendering the chart directly inside a local modal.
• Rendering the chart only once and visually "promoting" the same instance into full-screen (e.g. via a portal/animated layout transition) instead of rendering a second copy inside the modal. Rejected as more complex and fragile with the Skia-backed chart canvas; rendering a second copy under the shared provider reuses the parsed data and keeps the inline and full-screen views independent.