Summary

This PR adds a new height parameter to st.chat_input (Python API + typing), forwards it through layout config, and updates frontend chat input rendering for stretch/content behavior. The overall direction is good, but there is one blocking behavior mismatch for pixel height.

Code Quality

The implementation is clean and mostly consistent with existing layout patterns, but there is a high-severity semantic mismatch:

• High: Pixel height is implemented as a fixed container height, not a minimum height, which conflicts with the public API contract.
  • API docs explicitly describe pixel height as a minimum that still auto-expands (lib/streamlit/elements/widgets/chat.py:728-741).
  • The backend always forwards pixel height via LayoutConfig(height=height) (lib/streamlit/elements/widgets/chat.py:1013-1015).
  • Frontend layout currently interprets pixel height as fixed height and adds overflow scrolling (frontend/lib/src/components/core/Layout/useLayoutStyles.ts:325-328).
  • chatInput only has a special container config for useStretch, so pixel mode still uses the fixed-height default path (frontend/lib/src/components/core/Block/ElementNodeRenderer.tsx:810-813).
  • ChatInput sets textarea minHeight for pixel mode (frontend/lib/src/components/widgets/ChatInput/ChatInput.tsx:802-811), but this cannot restore true outer auto-expansion when the parent container is fixed.

Test Coverage

Coverage is decent for Python API validation and typing:

• Added backend tests for default/valid/invalid height values in lib/tests/streamlit/elements/chat_test.py.
• Added typing assertions for height in lib/tests/streamlit/typing/chat_input_types.py.

Gaps:

• Frontend tests only verify stretch/content style toggles (frontend/lib/src/components/widgets/ChatInput/ChatInput.test.tsx:891-914), not pixel-height behavior.
• No e2e coverage was added for the new user-visible sizing behavior (especially pixel minimum-height + growth behavior).

Backwards Compatibility

The API change is additive (height is optional and defaults to prior behavior), so source compatibility is generally good. However, the current pixel-height behavior may break user expectations because it behaves like a fixed-height container rather than a minimum-height chat input.

Security & Risk

No direct security issue identified. Main risk is UI regression: clipped/scrolling chat input container behavior in pixel mode under realistic content growth scenarios.

Accessibility

No new a11y violations found in the changed code paths. Existing semantic controls/labels remain intact.

Recommendations

1. Align pixel-height behavior with the documented contract by avoiding fixed outer container height for chatInput pixel mode (similar to existing textArea handling), and apply the pixel value as an inner minimum height target.
2. Add frontend unit tests that assert pixel mode preserves growth behavior (not just static style assertions).
3. Add at least one e2e scenario covering st.chat_input(height=<int>) with multiline growth and container behavior.

Verdict

CHANGES REQUESTED: Pixel height currently behaves as fixed height instead of minimum height, which conflicts with the documented API behavior and should be corrected before merge.

This is an automated AI review by gpt-5.3-codex-high. Please verify the feedback and use your judgment.

Summary

This PR adds a height parameter to st.chat_input() that supports three modes:

• None or "content" (default): Standard single-line height with auto-expand.
• "stretch": Fills available height of the parent container.
• Integer (pixels): Fixed minimum height with auto-expand behavior.

Changes span the Python backend (parameter validation, protobuf integration via LayoutConfig), the React frontend (styled-component prop plumbing, textarea min-height calculation, ElementContainerConfig.STRETCH_HEIGHT), and test coverage (Python unit tests, typing tests, frontend unit tests).

Code Quality

Good patterns observed:

• The STRETCH_HEIGHT static config in ElementContainerConfig ensures referential stability, following the repo's guidance on avoiding inline object creation per render.
• Height validation reuses the existing validate_height / LayoutConfig infrastructure from layout_utils.py.
• The heightConfig is correctly propagated through widgetProps (via elementProps spread) in ElementNodeRenderer.tsx.
• The getTextareaMinHeight function correctly derives values during render rather than using a useEffect, following the "You Might Not Need an Effect" guidelines.

Issues / observations:

1. Potential layout conflict between isStacked and isStretchHeight (styled-components.ts, line 88): In StyledTextareaWrapper, when both isStacked and isStretchHeight are true, the spread ...(isStretchHeight && { flex: 1 }) overrides flex: "none" from isStacked. In stacked mode, flex: "none" is needed so the textarea wrapper can wrap to its own line (via flex-wrap). Overriding it with flex: 1 when stretch height is active could cause unexpected layout behavior where the textarea doesn't properly wrap above the buttons.

2. Hardcoded border constant (ChatInput.tsx, line 805): CONTAINER_BORDER = 2 assumes the border is always 1px top + 1px bottom. This is fragile if theme.sizes.borderWidth changes. Consider reading the actual border width from the theme instead.

3. getTextareaMinHeight defined as a nested function (ChatInput.tsx, lines 791-814): While it correctly depends on reactive values (heightConfig, theme), it's only called once immediately after definition. Inlining the logic (or using a useMemo) would be cleaner and avoid the function allocation on every render. This is a minor style concern.

4. Pixel values for min-height (ChatInput.tsx, line 810): The frontend AGENTS.md says "Avoid using pixel sizes for styling, always use rem, em, percentage, or other relative units." However, since the user specifies height in pixels, returning a pixel value is acceptable here. No action needed, just noting the tradeoff.

Test Coverage

Python unit tests (chat_test.py): Good coverage of the height config protobuf fields for all three modes (pixel, stretch, content), the default case (no height_config field), and invalid inputs (string, negative, zero, float). Uses @parameterized.expand per best practices.

Python typing tests (chat_input_types.py): Comprehensive coverage of the height parameter across all overloads, including None, "content", "stretch", and integer values. Combined parameter tests also updated.

Frontend unit tests (ChatInput.test.tsx): Tests cover stretch, undefined, and content modes. However:

• Missing test for pixel height mode: There's no test verifying that heightConfig: { pixelHeight: 200 } applies the correct calculated min-height to the textarea.
• Missing test for interaction between stretch height and stacked layout: Given the potential conflict noted above, this would be valuable.

Missing E2E tests: Per the project's testing strategy ("Most new user-facing features should be covered by both unit tests and E2E tests"), this feature is missing E2E tests entirely. For a user-visible layout feature like this, E2E/snapshot tests would help verify the visual behavior across different configurations.

Backwards Compatibility

This change is fully backwards compatible:

• The height parameter defaults to None, preserving existing behavior.
• The protobuf HeightConfig message is already defined and used by other elements. No protobuf changes were needed.
• The ElementContainerConfig.DEFAULT is used when height is not stretch, maintaining existing container behavior.
• The height parameter is keyword-only across all overloads, so it won't interfere with positional arguments.

Security & Risk

No security concerns identified. The feature only affects layout/rendering. Input validation properly rejects invalid height values (negative, zero, float, invalid strings).

Low regression risk for existing users since the default behavior (height=None) is a no-op path through all the new code.

Accessibility

No accessibility concerns. The height parameter only affects visual sizing. The textarea remains fully accessible with proper aria-label, aria-describedby, and keyboard interaction regardless of height configuration. Focus management is unaffected.

Recommendations

1. Add a frontend unit test for pixel height mode: Test that heightConfig: { pixelHeight: 200 } applies the correct min-height calculation to the textarea.

2. Investigate the isStacked + isStretchHeight flex conflict: In StyledTextareaWrapper (line 88 of styled-components.ts), when both are true, flex: 1 overrides flex: "none". This may break the stacked wrapping behavior. Consider guarding the override: ...(isStretchHeight && !isStacked && { flex: 1 }) or verifying the combined behavior visually.

3. Add E2E tests: Per project guidelines, a new user-facing feature should have E2E coverage. At minimum, snapshot tests for the three height modes (content, stretch, pixel) in different container contexts (e.g., inside a container with a fixed height for stretch mode) would be valuable.

4. Minor: Consider using theme border width instead of hardcoded CONTAINER_BORDER = 2 in the pixel height calculation.

Verdict

CHANGES REQUESTED: The implementation is solid overall and backwards compatible. However, the potential layout bug when isStacked and isStretchHeight are both true (recommendation #2) should be investigated and tested, and E2E test coverage should be added per project guidelines. The missing pixel-height frontend unit test is a smaller gap but worth addressing.

This is an automated AI review by opus-4.6-thinking.

Summary

This PR adds a new height parameter to st.chat_input, wires it through Python layout config, and updates frontend chat input layout/styling paths for content, stretch, and pixel modes. The API shape and typing updates are solid, but there is a blocking frontend layout issue in pixel mode that conflicts with the documented behavior.

Code Quality

The implementation is generally clean and follows existing patterns, but one functional issue stands out:

• Blocking: In frontend/lib/src/components/core/Block/ElementContainerConfig.ts (STRETCH_HEIGHT/AUTO_HEIGHT) and frontend/lib/src/components/core/Block/ElementNodeRenderer.tsx (chatInput case), pixel mode maps to ElementContainerConfig.AUTO_HEIGHT, which only overrides height: "auto". However, the base layout engine still applies pixel-height semantics (flex: 0 0 <px> + overflow: auto) for vertical flex layouts (frontend/lib/src/components/core/Layout/useLayoutStyles.ts), so the outer container can still behave like a fixed-height scroll region rather than a true minimum-height container.
• This conflicts with the public contract in lib/streamlit/elements/widgets/chat.py, where pixel height is documented as a minimum height that still auto-expands with text.

Test Coverage

• Python unit coverage is good for this scope: validation, proto field mapping, and typing updates are present in lib/tests/streamlit/elements/chat_test.py and lib/tests/streamlit/typing/chat_input_types.py.
• Frontend unit tests in frontend/lib/src/components/widgets/ChatInput/ChatInput.test.tsx do not validate the critical pixel-mode behavior end-to-end (min-height + auto-expand semantics under renderer/container layout). Current assertions mostly check presence/style basics, so the container-layout regression path is not caught.
• No e2e test coverage was added for this user-visible feature (st.chat_input(height=...)), which leaves integration behavior under real app layout unverified.

Backwards Compatibility

The API change is additive and keyword-only, so existing callers are unlikely to break. However, the new pixel-height mode does not reliably match the documented behavior, so users adopting the new option may experience unexpected fixed-height scrolling behavior.

Security & Risk

No direct security concerns identified. Main risk is UI/behavioral regression for chat UX in pixel-height mode, especially in typical vertical container layouts.

Accessibility

No obvious new a11y violations in semantics/labels. That said, if pixel mode creates an unintended nested scroll container, keyboard navigation and screen-reader interaction can degrade versus expected auto-expanding input behavior.

Recommendations

1. Update pixel-height container behavior for chatInput to neutralize pixel-mode fixed-layout effects at the outer container level (at least flex in vertical layout, and likely overflow as needed), similar to the existing textArea handling pattern.
2. Add/adjust frontend tests to assert pixel-mode runtime behavior through renderer/container layout, not only isolated ChatInput component rendering.
3. Add an e2e test case that exercises st.chat_input(height=<int>) and height="stretch" in a realistic layout to validate integration behavior.

Verdict

CHANGES REQUESTED: The feature is close, but pixel-height mode currently has a blocking layout behavior mismatch with the documented "minimum height with auto-expand" contract.

This is an automated AI review by gpt-5.3-codex-high. Please verify the feedback and use your judgment.

Summary

This PR adds a height parameter to st.chat_input() that controls the minimum height of the chat input widget. It supports three modes:

• None or "content" (default): Uses the default single-line height with auto-expand behavior (preserves current behavior).
• "stretch": Fills the available height of the parent container.
• Integer (pixels): Sets a fixed minimum height while retaining auto-expand.

Changes span the Python backend (chat.py), frontend React components (ChatInput.tsx, styled-components.ts, ElementNodeRenderer.tsx, ElementContainerConfig.ts), and comprehensive tests (Python unit tests, frontend unit tests, and typing tests).

Code Quality

Overall: Clean implementation that follows existing patterns in the codebase. The code is well-structured and maintainable.

Good practices observed:

• Static ElementContainerConfig instances (STRETCH_HEIGHT, AUTO_HEIGHT) used in ElementNodeRenderer.tsx for referential stability — consistent with the AGENTS.md guidance.
• textareaMinHeight correctly computed via useMemo with proper dependencies.
• Layout/pixel calculations performed on the frontend side, following the lib/streamlit/AGENTS.md guideline ("Theming and layout calculations must be done in the frontend").
• height validation only runs when height is not None, preserving the default behavior.
• isStretchHeight && !isStacked guard in StyledTextareaWrapper properly avoids disrupting the stacked layout behavior.

Issue — Variable shadowing (ChatInput.tsx line 801):

The local innerHeight variable on line 801 shadows the destructured innerHeight from useWindowDimensionsContext() on line 184. While functionally correct (the outer value isn't needed here), it is confusing and may trigger linting warnings. Consider renaming to something like adjustedHeight or innerMinHeight.

Test Coverage

Python unit tests (chat_test.py): Good coverage including:

• Default behavior (no height_config field present).
• Parameterized tests for all three modes (pixel, stretch, content).
• Invalid input validation tests (string, negative, zero, float).

Typing tests (chat_input_types.py): Thorough coverage of the height parameter across all overload combinations with accept_file and accept_audio.

Frontend unit tests (ChatInput.test.tsx): Adequate but could be stronger:

• Tests stretch mode correctly applies height: 100%.
• Negative cases properly check that non-stretch modes don't get height: 100%.
• The pixel height mode test (line 912-917) only asserts the textarea element exists (toBeInTheDocument), but does not verify that the correct min-height style is applied. This test would pass even if the pixel height logic was completely broken.

Missing E2E tests: This is a new user-facing feature, and per the project's testing strategy (AGENTS.md): "Most new user-facing features should be covered by both unit tests and E2E tests." No E2E tests were added. Given that the height behavior is visual and involves CSS flex layout interactions (especially stretch mode in containers), E2E/snapshot tests would provide valuable confidence.

Backwards Compatibility

No breaking changes. The height parameter defaults to None, which preserves the existing behavior. The height_config protobuf field is optional on the Element message and was already defined before this PR. All existing overload signatures maintain their original parameter order with height appended as the last keyword argument.

The height parameter is included in compute_and_register_element_id but not in key_as_main_identity, which means changing height won't reset widget state when a user key is provided. This is the correct design choice since height is purely visual.

Security & Risk

No security concerns identified. The height parameter is validated server-side before being sent via protobuf, rejecting invalid types and non-positive integers. The frontend handles the value defensively with Math.max(0, ...) for pixel calculations.

Low regression risk: the changes only affect ChatInput and are gated behind the new height parameter. Default behavior (None) follows the existing code path.

Accessibility

No accessibility regressions introduced. The height changes are purely CSS-based and don't affect the DOM structure, ARIA attributes, keyboard navigation, or focus management. The textarea remains fully accessible regardless of height mode.

Recommendations

1. Rename shadowed variable: In ChatInput.tsx line 801, rename const innerHeight to const adjustedHeight or const innerMinHeight to avoid confusion with the innerHeight from useWindowDimensionsContext() on line 184.

2. Strengthen the pixel height test: The frontend test "renders textarea element in pixel height mode" (line 912-917) should verify the actual min-height style on the textarea root, not just that the textarea element exists.

3. Add E2E tests: Consider adding E2E tests (can be in a follow-up PR) covering:

   • height="stretch" inside a fixed-height st.container.
   • height=<int> renders the widget at the specified minimum height.
   • Default behavior remains unchanged.

4. Note on do-not-merge label: The PR currently has a do-not-merge label. Ensure this is removed when the PR is ready.

Verdict

APPROVED: Well-implemented feature with good backend validation, clean frontend integration following existing patterns, and adequate test coverage. The variable shadowing and weak pixel-height test are minor issues. Missing E2E tests can be addressed in a follow-up.

This is an automated AI review by opus-4.6-thinking.

Summary

This PR adds a new height parameter to st.chat_input across backend and frontend layers, wires it into layout config/protobuf handling, and introduces Python + frontend unit tests plus typing coverage. The implementation is generally clean and consistent with existing patterns, but I found one regression risk that should be fixed before merge.

Code Quality

The code is readable and follows existing architecture well (backend API + layout config + frontend rendering).
However, there is a layout behavior regression risk:

• Potential horizontal-layout regression for pixel height mode
  In frontend/lib/src/components/core/Block/ElementContainerConfig.ts:134, AUTO_HEIGHT forces flex: "".
  In frontend/lib/src/components/core/Block/ElementNodeRenderer.tsx:817, this config is selected for chatInput when heightConfig.pixelHeight is set.
  In horizontal flex layouts, this clears the computed flex distribution (useLayoutStyles), which can break width behavior (e.g., items no longer participating correctly in row sizing).
  This differs from the existing textArea handling pattern, which only neutralizes flex when not in horizontal layout.

Test Coverage

Coverage is improved and generally strong:

• Python unit tests validate height_config serialization and invalid inputs in lib/tests/streamlit/elements/chat_test.py.
• Typing tests validate new overload behavior in lib/tests/streamlit/typing/chat_input_types.py.
• Frontend unit tests validate stretch/content/pixel mode rendering behavior in frontend/lib/src/components/widgets/ChatInput/ChatInput.test.tsx.

Remaining gap:

• No test currently exercises chat_input(height=<pixel>) in a horizontal layout container, which is where the flex regression risk appears.
• No e2e test was added for this new user-facing sizing behavior.

Backwards Compatibility

The API change is additive (height is optional and keyword-only), so it is broadly backwards compatible.
That said, the flex override issue above can introduce behavior changes for apps using st.chat_input(height=<int>) inside horizontal layouts.

Security & Risk

No direct security concerns identified.
Main risk is UI/layout regression in specific container configurations.

Accessibility

No new accessibility regressions are obvious from the changed code.
Existing button semantics and labels are preserved, and no new non-semantic interactive patterns were introduced by this PR.

Recommendations

1. Update pixel-height container behavior so flex is only neutralized when not in horizontal layout (mirror the existing textArea strategy).
2. Add a frontend unit test that renders ChatInput in a horizontal flex context with heightConfig.pixelHeight and asserts expected sizing/flex behavior.
3. Add an e2e test covering st.chat_input(height="stretch") and st.chat_input(height=<int>) in realistic container scenarios.

Verdict

CHANGES REQUESTED: Good feature implementation overall, but the AUTO_HEIGHT flex override can regress horizontal-layout behavior and should be fixed before merge.

This is an automated AI review by gpt-5.3-codex-high. Please verify the feedback and use your judgment.

Summary

This PR adds a height parameter to st.chat_input() that controls the minimum height of the chat input widget, with three modes:

• None or "content" (default): Standard single-line height with auto-expand behavior (no change from current behavior).
• "stretch": Fills available height of the parent container.
• Integer (pixels): Fixed minimum height with auto-expand behavior.

The implementation spans backend (Python validation, protobuf integration via existing HeightConfig), frontend (styled components, container config, textarea overrides), and test code (Python unit tests, frontend unit tests, typing tests).

Code Quality

The code is well-structured and follows existing patterns in the codebase:

• Backend: The height parameter is properly added to all four overloads of chat_input(), validated via the existing validate_height() utility, and flows through LayoutConfig to the protobuf HeightConfig message — the same pattern used by other elements. The height parameter defaults to None, which is the correct backward-compatible default.

• Frontend: The ElementContainerConfig uses static constants (STRETCH_HEIGHT, AUTO_HEIGHT) for referential stability, following the class's documented pattern. The textareaMinHeight calculation correctly uses useMemo to avoid recomputation. The createTextAreaOverrides function cleanly integrates the minHeightOverride parameter.

• Styled components: The isStretchHeight prop is threaded through StyledChatInputContainer, StyledChatInput, StyledInputRow, and StyledTextareaWrapper to correctly propagate stretch behavior down the component tree.

Minor observations:

1. Redundant flex spread in StyledTextareaWrapper (styled-components.ts line 89): The conditional ...(isStretchHeight && !isStacked && { flex: 1 }) is redundant because the base flex: isStacked ? "none" : 1 already produces flex: 1 when !isStacked, regardless of isStretchHeight. The spread doesn't change the computed value.

2. Stacked + stretch interaction (styled-components.ts lines 64-73, 78-90): When both isStacked (text fills width, triggers wrapped layout) and isStretchHeight are true, the textarea wrapper gets flex: "none" with width: "100%". In a wrapped flex row, align-items: stretch only stretches items to the line height, not the container height. This means the textarea won't actually fill the vertical space in stacked mode. This is likely acceptable since stacked mode implies enough text to auto-expand, but it's worth noting as a potential visual inconsistency.

Test Coverage

Python unit tests (chat_test.py): Good coverage with:

• Default height (no height_config field present) — validated via HasField.
• Parameterized tests for all three valid modes (pixel, stretch, content).
• Parameterized tests for invalid inputs ("invalid", -100, 0, 100.5).

Frontend unit tests (ChatInput.test.tsx): Reasonable coverage with:

• Stretch mode: Validates height: 100% is applied to the container.
• Negative tests: Parameterized check that non-stretch modes don't apply height: 100%.
• Pixel height mode: The test at line 912 acknowledges it cannot verify the actual min-height CSS value applied through baseweb overrides. It only verifies the component renders and the textarea exists — this is a known limitation but means the pixel-height CSS path is not truly asserted.

Typing tests (chat_input_types.py): Thorough coverage of height parameter with None, "content", "stretch", and integer values across different accept_file combinations.

Missing E2E tests: The PR does not include E2E tests. Per the project's testing strategy (AGENTS.md: "Most new user-facing features should be covered by both unit tests and E2E tests"), this is a notable gap. E2E tests would verify the actual rendering behavior across all three height modes, especially stretch mode within a container with defined height and pixel-height mode visual appearance.

Backwards Compatibility

This change is fully backward compatible:

• The height parameter defaults to None, which produces no height_config field in the protobuf message, matching pre-PR behavior exactly.
• The frontend falls through to ElementContainerConfig.DEFAULT when no heightConfig is present.
• No existing protobuf fields or messages were modified — the HeightConfig message already existed.
• All existing overloads maintain their signatures; height is added as an optional keyword argument.

Security & Risk

No security concerns identified. The height parameter undergoes proper server-side validation:

• String values are restricted to "stretch" and "content".
• Integer values must be positive (rejects 0, negatives, and floats like 100.5).
• Invalid inputs raise StreamlitInvalidHeightError.

Regression risk: Low. The default behavior is unchanged, and the feature is additive. The most complex path (pixel height with auto-expand) involves CSS min-height calculations, but these are well-isolated in useMemo and don't affect the default code path.

Accessibility

No accessibility concerns. The changes are purely visual/layout:

• No new interactive elements are added.
• All existing aria-label, aria-describedby, and keyboard interaction patterns are preserved.
• The textarea remains the same semantically; only its minimum height changes.
• Focus management is unaffected.

Recommendations

1. Add E2E tests: Create E2E tests covering the three height modes. At minimum, test height="stretch" inside a container with defined height, and height=<int> to verify visual rendering. This follows the project's stated testing strategy for new user-facing features.

2. Remove redundant flex spread in StyledTextareaWrapper (styled-components.ts line 89): The conditional ...(isStretchHeight && !isStacked && { flex: 1 }) produces the same value already set by flex: isStacked ? "none" : 1 in the non-stacked case. Consider removing it or adding a comment explaining the intent if kept for documentation purposes.

3. Strengthen pixel-height frontend test: While baseweb override style assertions are difficult, consider testing the createTextAreaOverrides function directly to verify the minHeight value matches expectations (e.g., "174px" for pixelHeight: 200). This would provide stronger coverage than only checking the component renders.

Verdict

APPROVED: Well-implemented feature with clean backend/frontend integration, proper validation, and good backward compatibility. The missing E2E tests are the main gap but don't block the merge — they should be added as a follow-up.

This is an automated AI review by opus-4.6-thinking.

Summary

This PR adds a height parameter to st.chat_input, allowing users to control the minimum height of the chat input widget. It supports "content" (default auto-expanding behavior), "stretch" (filling the parent container), and integer values for fixed minimum pixel heights.

Code Quality

The code changes are clean, well-structured, and follow the established patterns in the repository. The frontend changes correctly handle the different layout modes (stacked vs inline) and correctly adjust the flex and height properties based on the heightConfig. The backend changes properly validate and pass the new height parameter.

Test Coverage

The changes are well-tested:

• E2E Tests: Added scenarios for height=200 and height="stretch" in e2e_playwright/st_chat_input.py and st_chat_input_test.py, with corresponding snapshot updates.
• Frontend Unit Tests: Added tests in ChatInput.test.tsx to verify the correct application of styles for different heightConfig modes.
• Python Unit Tests: Added tests in chat_test.py to verify the default behavior and the mapping of the height parameter to the protobuf height_config.
• Typing Tests: Added assert_type checks in chat_input_types.py for the new height parameter combinations.

Backwards Compatibility

The changes are fully backwards compatible. The default value for the height parameter is "content", which preserves the existing auto-expanding behavior of the chat input widget.

Security & Risk

No security concerns or regression risks identified. The changes are limited to UI presentation and standard parameter passing, with no impact on sensitive areas like authentication, file serving, or code execution.

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence:
  • The changes are purely cosmetic and structural (UI layout and parameter parsing).
  • No routing, auth, websocket, embedding, or storage logic is touched.
• Suggested external_test focus areas: N/A
• Confidence: High
• Assumptions and gaps: None

Accessibility

The changes do not negatively impact accessibility. The chat input remains fully functional via keyboard and screen readers, and the new layout modes correctly preserve focus management and ARIA attributes.

Recommendations

No specific recommendations for improvement. The implementation is solid and ready for merge.

Verdict

APPROVED: The PR successfully implements the height parameter for st.chat_input with excellent test coverage and code quality.

This is an automated AI review by gemini-3.1-pro.

Summary

This PR adds a new height parameter to st.chat_input across backend API, frontend rendering/layout, typing checks, and e2e snapshots. The implementation is generally clean and well-structured, but there is one behavior mismatch between the documented contract and frontend behavior that should be fixed before merge.

Code Quality

The overall structure follows Streamlit patterns (backend validation + layout config, frontend container config, unit/e2e updates).
One significant issue was found:

• Behavior contract mismatch (merge-blocking): height=<int> is documented as a minimum height with auto-expand, but frontend logic currently enforces fixed-height behavior for configured heights by bypassing autoExpand.
  • Docs/contract: lib/streamlit/elements/widgets/chat.py (around lines 746-757) states integer height still auto-expands with content.
  • Implementation: frontend/lib/src/components/widgets/ChatInput/ChatInput.tsx (around lines 135-143, 820-821, 881-890) sets useFixedHeight for pixel mode and applies height: "100%" / maxHeight: "none" instead of using the autoExpand height path.
  • Resulting risk: long input in pixel-height mode can stop expanding and rely on internal scrolling, which conflicts with documented API behavior.

Test Coverage

Coverage is improved and broad:

• Python unit tests validate height default, accepted values, and invalid values.
• Typing tests validate overload behavior with height.
• Frontend unit tests validate stretch/content style branches.
• E2E coverage includes new snapshot states for height=200 and height="stretch".

Gap that matters for this change:

• No test verifies interactive text-growth behavior for height=<int> (or stretch) while typing multiline content. Current tests are mostly static style/snapshot checks, so the contract mismatch above is not caught.

Backwards Compatibility

API-wise this is additive (height is optional with default), so call signatures are backward compatible.
However, behavior compatibility for users adopting the new parameter is currently inconsistent with docs: height=<int> does not clearly preserve the existing auto-expand expectation.

Security & Risk

No direct security issues identified (no auth/session/cookie/CORS/path handling/runtime execution changes).
Primary regression risk is user-visible widget behavior in chat UX (layout + input growth semantics), especially in multiline prompts.

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence:
  • lib/streamlit/elements/widgets/chat.py: API parameter/validation + layout config wiring for chat input height.
  • frontend/lib/src/components/widgets/ChatInput/ChatInput.tsx: widget-local layout/styling behavior changes only.
  • frontend/lib/src/components/core/Block/ElementNodeRenderer.tsx: element container layout policy for chat input.
  • e2e_playwright/st_chat_input.py, e2e_playwright/st_chat_input_test.py: local app/e2e rendering updates, no external-hosting protocol changes.
• Suggested external_test focus areas:
  • None required for this PR specifically.
• Confidence: High
• Assumptions and gaps: Assessment assumes no hidden changes outside this diff touching routing/auth/websocket/embed/postMessage/cross-origin policies.

Accessibility

No new critical a11y regressions spotted in this diff. Interactive icon buttons retain accessible names (aria-label), and semantic button usage remains intact.
The major concern here is behavioral (height growth), not assistive-tech semantics.

Recommendations

1. Restore true auto-expand behavior for height=<int> in frontend/lib/src/components/widgets/ChatInput/ChatInput.tsx (keep pixel value as minimum height, but do not force fixed height: 100% for pixel mode).
2. Add a focused frontend unit test and one e2e interaction test that type multiline text in height=200 mode and assert growth behavior (plus a negative assertion for non-regression, e.g., no premature scrollbar/fixed clipping).

Verdict

CHANGES REQUESTED: The height=<int> behavior in frontend does not currently match the API/doc contract (minimum + auto-expand), so this should be corrected before merge.

This is an automated AI review by gpt-5.3-codex-high.

Summary

This PR adds a height parameter to st.chat_input() that allows controlling the minimum height of the chat input widget. The parameter supports three modes:

• "content" (default): Standard single-line height with auto-expand behavior (unchanged from today).
• "stretch": Fills the available height of the parent container.
• Integer (pixels): Sets a fixed minimum height while retaining auto-expand.

The implementation spans backend (Python parameter + validation), protobuf (reuses existing HeightConfig), and frontend (new layout logic in ChatInput.tsx and styled-components.ts, plus container config in ElementNodeRenderer.tsx). E2E snapshots and unit tests (Python, TypeScript, and typing) are included.

Code Quality

Strengths:

• Cleanly reuses the existing HeightConfig protobuf and LayoutConfig infrastructure—no new proto fields needed.
• Follows the established pattern from st.text_area height configuration in ElementNodeRenderer.tsx (stretch uses flex: "1 1 8rem", pixel uses height: "auto" + overflow: "visible").
• Good separation of concerns: the textareaMinHeight calculation is memoized with correct dependencies.
• The layout correctly falls back to the non-expanded (row) layout during audio recording, even when heightConfig is set—this avoids breaking the waveform display.

Concerns:

1. Significant code duplication in ChatInput.tsx (lines 896–1094): The expanded (hasExpandedHeight && !isRecording) and non-expanded branches duplicate the entire button cluster: StyledLeftCluster with ChatFileUploadButton, StyledRightCluster with audio buttons, error tooltips, send button, and StyledInputInstructions. This is roughly 100 lines of duplicate JSX. Any future change to button behavior must be replicated in both branches, creating a maintenance risk. Consider extracting shared button clusters into helper components or using a render function to reduce duplication.

2. StyledInputInstructions visual positioning change affects all chat inputs: The removal of position: "absolute", top, right, and zIndex from StyledInputInstructions (styled-components.ts, lines 129–138) moves the character count indicator from a floating overlay position to inline within the button row. This is a global visual change for every st.chat_input() that uses max_chars, not only those with the new height parameter. The numerous snapshot updates confirm this. While this may be intentional (and arguably a better design), it should be explicitly called out as a visual/behavioral change to existing users.

3. parseInt for border width (ChatInput.tsx, line 807): parseInt(theme.sizes.borderWidth, 10) works for pixel values like "1px" but would silently return NaN for rem-based values. The || 1 fallback mitigates this, but it's worth noting this assumption is theme-dependent.

Test Coverage

Python unit tests (lib/tests/streamlit/elements/chat_test.py):

• Tests the default height config (use_content: true).
• Parameterized tests for all three height modes (pixel, stretch, content) validating the correct protobuf field and value.
• Parameterized invalid-input tests (invalid string, negative, zero, float).
• Good coverage following the @parameterized.expand pattern.

Python typing tests (lib/tests/streamlit/typing/chat_input_types.py):

• Covers height with all three modes combined with accept_file and the "all parameters" combined tests.

Frontend unit tests (ChatInput.test.tsx):

• Tests height: 100% style for stretch mode.
• Parameterized negative tests for undefined, content mode, and pixel height mode (correctly verifying NO height: 100%).
• The pixel-height test ("renders with correct calculated min-height in pixel height mode") does not actually assert the computed min-height value—it only checks the textarea root element exists. The comment acknowledges baseweb style injection makes this hard. This is a gap in coverage, but understandable.

E2E tests (e2e_playwright/st_chat_input_test.py):

• Snapshot tests for height=200 and height="stretch" are added to the existing test_chat_input_rendering aggregated test, following the established pattern.
• The stretch test correctly screenshots the parent container (height_stretch_container) to show the widget filling it.
• New snapshots are provided for all browser/theme combinations.
• Missing: No behavioral E2E test verifying that text typed into a height-configured chat input actually submits correctly, or that auto-expand still works within a pixel-height input. The visual snapshots cover the static appearance, but an interaction test would increase confidence.

Backwards Compatibility

• The height parameter defaults to "content", which preserves the existing single-line auto-expand behavior. No breaking change for existing st.chat_input() calls.
• The height parameter is not included in key_as_main_identity, so changing it won't reset widget state. This is correct.
• The StyledInputInstructions positioning change (absolute → inline) is a visual regression for users who have max_chars set on chat_input. While likely an improvement, it changes the appearance of existing apps without the user changing any code. This should be documented as a visual change.

Security & Risk

No security concerns identified. The changes are confined to:

• A new validated parameter on a public API method.
• CSS/layout changes in the frontend.
• No new dependencies, no HTML injection, no eval, no network changes.
• Input validation correctly rejects invalid height values (floats, negatives, unknown strings).

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence:
  • All changes are in UI element rendering (CSS layout, protobuf field reuse, parameter validation).
  • No changes to routing, auth, websocket, embedding, asset serving, CORS, storage, or security headers.
  • No changes to server-side behavior or network protocols.
• Suggested external_test focus areas: N/A
• Confidence: High
• Assumptions and gaps: None. The changes are purely additive UI parameter support with no infrastructure impact.

Accessibility

• aria-label and aria-describedby attributes are preserved in both expanded and non-expanded layout branches.
• The StyledInputInstructions remains linked via id="stChatInputInstructions" to the textarea's aria-describedby.
• All buttons retain their aria-label attributes ("Send message", "Start recording", "Cancel recording", "Submit recording").
• The StyledSendIconButton components retain focus-visible styles.
• No accessibility regressions identified. The layout restructuring doesn't affect screen reader behavior since the same semantic elements are rendered.

Recommendations

1. Reduce JSX duplication in ChatInput.tsx: Extract the button clusters (file upload button, audio buttons, instructions, send button) into shared components or a render function to avoid maintaining identical JSX in two branches. This is the most significant maintainability concern in the PR.

2. Explicitly document the StyledInputInstructions positioning change: The PR description only mentions the new height parameter. The global visual change to character count positioning (from absolute overlay to inline) should be mentioned in the PR description and/or changelog, as it affects all st.chat_input() usages with max_chars.

3. Consider adding a behavioral E2E test: A test that types text into a height-configured chat input and submits it would verify that the new layout doesn't interfere with core chat input functionality (beyond visual appearance).

4. Minor: The pixel-height frontend unit test could be strengthened: Currently it only verifies the textarea root element exists rather than asserting the actual computed min-height. If testing the baseweb override style is feasible (e.g., via getComputedStyle in the test), it would add confidence.

Verdict

APPROVED: Well-implemented feature that follows established Streamlit patterns for height configuration, with thorough backend validation, typing tests, and visual snapshot coverage. The main concern is JSX duplication in the expanded/non-expanded layout branches, which is a maintainability issue rather than a correctness bug. The implicit visual change to StyledInputInstructions positioning should be explicitly documented.

This is an automated AI review by opus-4.6-thinking.