bug(cdk/text-field): cdkTextareaAutosize caches line height before matInput applies `font: inherit`, so min/max rows are wrong
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 57/100
- Type d'issue
- Bug
- Clarté
- Clairement spécifiée
- Activité
- Active
- Stack technique
- angular, typescript
- Domaine
- frontend
Piste de recherche
Start with CdkTextareaAutosize and its first ngDoCheck measurement path (resizeToFitContent and _cacheTextareaLineHeight), then compare it with the MatInput host binding that applies mat-mdc-form-field-input-control. Reproduce the issue in the official CDK text-field autosizing example and inspect the cached line height before and after resizing. Done means min/max heights use the textarea's actual line height on first render, without a window resize.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Is this a regression?
- Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was
14.x (verified on v14.material.angular.dev, Angular 14.0.0)
Description
When cdkTextareaAutosize is used on a matInput textarea inside mat-form-field, the cached line height used for cdkAutosizeMinRows / cdkAutosizeMaxRows is measured with the browser's default textarea font instead of the form field's font. As a result, min-height / max-height are too small until the window is resized.
Cause (as far as I can tell):
CdkTextareaAutosizemeasures and caches the line height on the firstngDoCheck(resizeToFitContent→_cacheTextareaLineHeight, cloning the textarea withrows=1).MatInputappliesfont: inheritvia the classmat-mdc-form-field-input-control, which is a dynamic host binding ('[class.mat-mdc-form-field-input-control]': '_isInFormField').- Host bindings are applied after
ngDoCheckin the first change detection pass. So at measuring time the textarea (and its clone) still uses the UA default textarea font (Chrome: monospace 13.33px,line-height: normal≈ 15px). - The wrong value stays cached until a window
resizeclears it.
Measured on the official docs example (cdkAutosizeMaxRows="5", actual line height 24px):
| Docs | Angular | measured line height | max-height |
|---|---|---|---|
| v14 | 14.0.0 | 18px (correct) | 90px |
| v15 | 15.1.1 | 15px | 75px |
| v17 | 17.3.0 | 15px | 75px |
| v19 | 19.2.6 | 15px | 75px |
| v21 | 21.2.11 | 15px | 75px |
| current | 22.2.1 | 15px | 75px (expected 120px) |
It started with v15, i.e. the switch to the MDC-based form field.
Workaround: a global style so the textarea inherits the font before the first measurement:
textarea.cdk-textarea-autosize { font: inherit; letter-spacing: inherit; }
Reproduction
No StackBlitz needed – the official docs example reproduces it:
https://material.angular.dev/cdk/text-field/examples ("Auto-resizing textarea")
Steps to reproduce:
- Open the page above (fresh load, don't resize the window).
- Select the textarea in DevTools and run:
→({ minHeight: $0.style.minHeight, maxHeight: $0.style.maxHeight, lineHeight: getComputedStyle($0).lineHeight })minHeight: "15px",maxHeight: "75px",lineHeight: "24px" - Type more than 3 lines: the textarea starts scrolling after ~3 lines instead of 5.
- Resize the browser window and run the snippet again →
minHeight: "24px",maxHeight: "120px"(correct).
For comparison, the same example on https://v14.material.angular.dev/cdk/text-field/examples measures correctly on first load.
Expected Behavior
min-height / max-height are based on the actual line height of the textarea (24px → max-height: 120px for 5 rows) right after the first render.
Actual Behavior
They are based on the UA default textarea font (15px → max-height: 75px) until the window is resized.
Environment
- Angular 22.2.1
- CDK/Material 22.2.x
- Chrome (Version 154.0.8037.95 (64-Bit))
- Windows 11
- Langage dominant
- TypeScript
- Étoiles
- 25k
- Forks
- 6.9k
- Merge moyen
- 2 j 7 h
- PR mergées (30 j)
- 83
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de angular/components
-
bug(mat-slider): on Firefox, slider thumb is not aligned with cursorPeut-être pris @Devyalamaddi l’a pris il y a 3 jours. Ouvertearea: material/slider P4
Difficulté 2/5 1-3 heures Accessibilité débutants 62/100
angular/components#34094 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug(material/sort): hover hint arrow on an unsorted header shows the active sort direction, not the resulting direction after click.Peut-être pris @abdul-karim-mia l’a pris il y a 2 jours. Ouvertearea: material/sort P3
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
angular/components#33933 ·
Les mainteneurs répondent en général sous 1 jour
-
bug(mat-date-picker): month shown twice in date pickerPeut-être pris @PreethiPantangi l’a pris il y a 54 jours. Ouvertearea: material/datepicker P4
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
angular/components#33763 · 2 commentaires · 3 réactions ·
Les mainteneurs répondent en général sous 1 jour
-
Bug in table.scss footer cell height: unset instead of footer row height unsetPeut-être pris @minwookshin l’a pris il y a 41 jours. Ouvertearea: material/table P4
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
angular/components#33709 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug(date-adapter): Misleading JSDoc for createDate returns typePeut-être pris @BHUVANSH855 l’a pris il y a 171 jours. Ouvertearea: material/core P3
Difficulté 1/5 Moins d'une heure Accessibilité débutants 78/100
angular/components#33059 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de angular/components
Issues similaires
-
normalizePropName strips `#` characters from Figma property names instead of only the `#id` suffixOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
figma/code-connect#419 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
jeanibarz/knowledge-base-mcp-server#1268 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 78/100
Koenkk/zigbee-herdsman-converters#13820 ·
Les mainteneurs répondent en général sous 2 jours
-
A live recovery copy treats a large whole number and text with the same digits as the same valueOuvertebug sharing & sync
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
Les mainteneurs répondent en général sous 1 jour