[$250] Chart should maintain aspect ratio when window/screen size changes

[melvin-bot]

Problem

The chart does not maintain its aspect ratio when the window (or screen) size changes. Instead, it shrinks in an awkward, non-proportional way. The expected behavior is that the chart should scale uniformly — like any other image — so that the entire chart shrinks proportionally as the viewport shrinks.

This is a general issue on web, but critical on mobile where screen real estate is limited and non-uniform scaling can make the chart unusable.

Expected behavior

When the window or screen size changes, the chart should scale proportionally (maintaining its aspect ratio), similar to how a standard <img> element would respond to a responsive container.

Actual behavior

The chart shrinks in a disproportionate/unexpected way when the viewport is reduced, rather than scaling uniformly.

Platforms affected

• Web
• Mobile (iOS / Android) — high priority

Notes

Maintaining aspect ratio is a core UX concern on mobile given the limited screen size. A responsive, aspect-ratio-preserving layout is the correct behavior.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060871654030567102
• Upwork Job ID: 2060871654030567102
• Last Price Increase: 2026-05-30

[MelvinBot]

ℹ️ This looks like a duplicate of #91515 (status: Reviewing), which tracks the same Victory Chart aspect-ratio bug introduced in #90253. The analysis below is provided in case it's useful while triaging.

Proposal

What is the root cause of that problem?

The Victory Chart container has a fixed pixel height but a fluid width, so as the viewport shrinks the chart compresses horizontally while its height stays constant — aspect ratio is not preserved.

Specifically, the chartContent style hard-codes height: 250 while the outer wrappers apply maxWidth: '100%':

• src/styles/index.ts:6087-6092 — chartContent: { height: CHART_CONTENT_MIN_HEIGHT } (constant = 250)
• VictoryChartContainer.tsx:9-13 — both nested Views use mw100 (maxWidth: 100%) for width but inherit the fixed height
• VictoryTheme.ts:85 — CHART_CONTENT_MIN_HEIGHT = 250
• parseStyles.ts:14-21 — when the HTML element passes width/height attributes, they're applied independently with no aspectRatio derived from them

Mobile and web share the same code path (the .native.tsx variant just re-exports BaseVictoryChartRenderer), so the bug manifests identically — but it's more painful on mobile where the viewport is small and the squashing is more pronounced.

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

Drive sizing by an aspect ratio derived from the <victorychart width="..." height="..."> HTML attributes, instead of a constant pixel height:

1. In parseStyles.ts, when both width and height are provided on the <victorychart> element, emit aspectRatio: parsedWidth / parsedHeight into the parsed style (and stop emitting a fixed height).
2. In VictoryChartContainer.tsx, let the parsed aspectRatio win over chartContent.height. Keep minHeight: CHART_CONTENT_MIN_HEIGHT as a floor so very narrow viewports don't collapse the chart entirely.
3. If no width/height attributes are present, fall back to a sensible default aspect ratio (e.g. matching the current 680×430 ≈ 1.58) instead of fixed height.

aspectRatio is supported by both React Native and the web. This makes the chart scale uniformly on resize without any transform tricks.

What alternative solutions did you explore? (Optional)

• transform: scale(s) on the outer wrapper — rejected: doesn't change layout flow on web, and the Skia canvas in victory-native's CartesianChart would still rasterize at the original size, producing blurry/clipped output.
• SVG viewBox + preserveAspectRatio — not applicable: the rendering goes through victory-native's CartesianChart (Skia), not a raw SVG, so there's no viewBox to set at the top level.

Data flow evidence

1. Chat HTML contains <victorychart width=W height=H> (introduced in #90253)
2. VictoryChartRenderer → BaseVictoryChartRenderer → VictoryChartContainer
3. VictoryChartContainer renders nested Views: outer mw100 + chartContainer, inner mw100 + chartContent (fixed height 250px)
4. parseStyles accepts explicit width/height numbers but does NOT compute aspect ratio — the fixed chartContent.height wins
5. CartesianChart fills its parent View, so the Skia canvas's coordinate space gets non-uniformly remapped on resize, compressing bars/lines horizontally

Related issues

• #91515 — same aspect-ratio bug, currently in Reviewing. The contributor team should consider closing this issue as a duplicate.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92147) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-30 23:59:40 UTC.

Replaces my earlier proposal. The earlier draft targeted the search/home chart components. The verified root cause is in the HTML Victory chart renderer: numeric width and height are applied independently, so max-width clamps only the width and leaves the height fixed.

Proposal

What is the root cause of that problem?

The affected chart path is the HTML Victory chart renderer, where custom <victorychart> blocks are registered as renderable HTML nodes and routed to VictoryChartRenderer:

App/src/components/HTMLEngineProvider/BaseHTMLEngineProvider.tsx

Lines 203 to 234 in 3ec7273

	victorychart: HTMLElementModel.fromCustomModel({
	tagName: 'victorychart',
	contentModel: HTMLContentModel.block,
	}),
	victorybar: HTMLElementModel.fromCustomModel({
	tagName: 'victorybar',
	contentModel: HTMLContentModel.block,
	}),
	victoryline: HTMLElementModel.fromCustomModel({
	tagName: 'victoryline',
	contentModel: HTMLContentModel.block,
	}),
	victoryaxis: HTMLElementModel.fromCustomModel({
	tagName: 'victoryaxis',
	contentModel: HTMLContentModel.block,
	}),
	victorylabel: HTMLElementModel.fromCustomModel({
	tagName: 'victorylabel',
	contentModel: HTMLContentModel.textual,
	}),
	victorylegend: HTMLElementModel.fromCustomModel({
	tagName: 'victorylegend',
	contentModel: HTMLContentModel.block,
	}),
	victorygroup: HTMLElementModel.fromCustomModel({
	tagName: 'victorygroup',
	contentModel: HTMLContentModel.block,
	}),
	victorypie: HTMLElementModel.fromCustomModel({
	tagName: 'victorypie',
	contentModel: HTMLContentModel.block,
	}),

App/src/components/HTMLEngineProvider/HTMLRenderers/index.ts

Lines 62 to 63 in 3ec7273

	victorychart: VictoryChartRenderer,
	};

That renderer copies numeric width and height from the <victorychart> node directly onto the inner chart view:

App/src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/utils/parseStyles.ts

Lines 14 to 21 in 3ec7273

	const parsedHeight = parseAttribute(tnode.attributes.height);
	if (typeof parsedHeight === 'number') {
	nodeStyles.height = parsedHeight;
	}
	const parsedWidth = parseAttribute(tnode.attributes.width);
	if (typeof parsedWidth === 'number') {
	nodeStyles.width = parsedWidth;
	}

Those parsed styles are then passed through context and applied after the shared styles.chartContent and styles.mw100 styles:

App/src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/context/VictoryChartContext.tsx

Lines 34 to 38 in 3ec7273

	function VictoryChartProvider({tnode, children}: {tnode: TNode; children: React.ReactNode}) {
	const {regular: regularTypeface} = useChartDefaultTypeface();
	const {data, xKey, yKeys, xAxis, yAxis, domain, domainPadding, padding, isHorizontal, categories, labelItems, legendItems} = processVictoryChartTree(tnode, regularTypeface, null);
	const {nodeStyles: chartContentStyles, parentNodeStyles: chartContainerStyles} = parseStyles(tnode);

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

Lines 10 to 11 in 3ec7273

	<View style={[styles.chartContainer, styles.mw100, chartContainerStyles]}>
	<View style={[styles.chartContent, styles.mw100, chartContentStyles]}>{children}</View>

So when a viewport becomes narrower than the original chart width, maxWidth: '100%' clamps only the width. The fixed numeric height remains unchanged, so Victory/Skia redraws into a narrower-but-equally-tall canvas instead of scaling the full chart rectangle proportionally.

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

Change the Victory chart sizing contract so a numeric width/height pair is treated as an intrinsic size, not two independent responsive dimensions.

Concretely, update parseStyles() after all attribute and style.data merging is complete. When the final node style has a positive numeric width and height, convert that pair into responsive image-style sizing: preserve the original width as the maximum rendered width, set the rendered width to fill the available container up to that maximum, remove the fixed height, and set aspectRatio to width / height. Leave single-dimension, percentage/string, and explicit parent styles unchanged.

Add focused coverage for parseStyles() so a width=450 height=300 chart returns a style equivalent to width: '100%', maxWidth: 450, aspectRatio: 1.5, and no fixed height, while width-only and height-only charts keep their current behavior.

Scope boundaries: touch src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/utils/parseStyles.ts and, only if needed for layout alignment, src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/components/VictoryChartContainer.tsx. This affects rendered HTML Victory charts on web, mWeb, desktop, iOS, and Android through the shared renderer. It does not change the search/home chart components in src/components/Charts, chart data parsing, Victory axis/domain settings, tooltip behavior, or backend/API behavior.

What alternative solutions did you explore? (Optional)

Updating the search chart components would not fix this HTML-rendered chart path; those components have their own dashboard layout and do not parse <victorychart width height> from report HTML.

Only removing styles.mw100 would prevent width clamping, but then charts would overflow small screens. Scaling the whole chart with a transform would preserve visuals but would make layout height, hit testing, and tooltip coordinates fragile. Using aspectRatio from the intrinsic width/height pair fixes the layout at the source while keeping the existing Victory render and interaction code intact.

[ReaperOAK]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @ReaperOAK Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.