Skip to content

[TextareaAutosize] Support max height - #49106

Open
stop1love1 wants to merge 1 commit into
mui:masterfrom
stop1love1:fix/textarea-autosize-max-height
Open

[TextareaAutosize] Support max height#49106
stop1love1 wants to merge 1 commit into
mui:masterfrom
stop1love1:fix/textarea-autosize-max-height

Conversation

@stop1love1

Copy link
Copy Markdown

Closes #43719

Problem

TextareaAutosize measures its content and then writes both height and overflow on the textarea:

textarea.style.height = `${outerHeightStyle}px`;
textarea.style.overflow = textareaStyles.overflowing ? 'hidden' : '';

overflow is only left scrollable when maxRows clamps the height. A CSS max-height is invisible to that computation, so the browser clips the box at max-height while the component keeps overflow: hidden on it — the text below the fold becomes unreachable, exactly as reported in the issue.

<TextareaAutosize style={{ maxHeight: 100 }} defaultValue={'a\n'.repeat(30)} />

Solution

Read max-height from the computed style that is already being fetched, and treat "the height we are about to apply is taller than max-height" the same way the component already treats "maxRows reached": keep the textarea scrollable.

The comparison is done against outerHeightStyle, so box-sizing is accounted for automatically — max-height and height resolve against the same box.

getComputedStyle returns max-height as a resolved computed value, not a used value, so layout-dependent values (percentages, calc() mixing percentages) come back unresolved and can't be compared with a pixel height. Those fall back to the current behaviour rather than guessing; a test locks that in.

No public API change, and no extra layout read — computedStyle was already being queried.

Testing

Three tests added to the existing jsdom layout suite. The first two fail on master (expected … 'overflow' of '', but got 'hidden') and pass with the fix; the third documents the non-absolute max-height fallback.

Test Files  1 passed (1)
     Tests  15 passed | 3 skipped (18)

pnpm eslint, pnpm typescript and prettier --check are clean on the touched files, and the neighbouring TextField / InputBase / Input / OutlinedInput / FilledInput suites still pass (260 tests).

Happy to follow up with a docs demo for max-height if you'd like one in the same PR.

The component forces `overflow: hidden` whenever the content fits the height it
computes, which ignores a CSS `max-height` shorter than that height. The content
was then clipped with no way to scroll to it.

Compare the computed height with the resolved `max-height` and keep the textarea
scrollable when it is clipped, the same way it already behaves once `maxRows` is
reached.

Closes mui#43719
@code-infra-dashboard

Copy link
Copy Markdown

Deploy preview

https://deploy-preview-49106--material-ui.netlify.app/
QR code for https://deploy-preview-49106--material-ui.netlify.app/

Bundle size

Bundle Parsed size Gzip size
@mui/material 🔺+84B(+0.02%) 🔺+52B(+0.03%)
@mui/lab 0B(0.00%) 0B(0.00%)
@mui/private-theming 0B(0.00%) 0B(0.00%)
@mui/system 0B(0.00%) 0B(0.00%)
@mui/utils 0B(0.00%) 0B(0.00%)

Details of bundle changes


Check out the code infra dashboard for more information about this PR.

@zannager zannager added the scope: textarea Changes related to the textarea. label Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

scope: textarea Changes related to the textarea.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[TextareaAutosize] Support max height

2 participants