Pull request overview

Adds an optional title parameter to Streamlit’s alert/status callouts (st.error, st.warning, st.info, st.success) so users can render a bold title above the existing Markdown body.

Changes:

• Extends the Alert protobuf with a new title field and wires it through backend → frontend rendering.
• Updates the Python alert APIs + docstrings to accept title and populate the proto field.
• Adds/updates unit + frontend + E2E coverage for title rendering (including snapshots).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Summary

This PR adds an optional title parameter to the four alert callout elements (st.error, st.warning, st.info, st.success), enabling users to display a bold title above the body text. The implementation spans the full stack: a new string title = 5 field on the Alert protobuf message, a keyword-only title parameter (default None) on all four Python methods with clean_text() sanitization, and frontend rendering via new StyledAlertTitle and StyledAlertTextContent styled components. As a bonus, the PR refactors the inline width-calculation style on StreamlitMarkdown into a proper styled component — a code quality improvement aligned with frontend conventions.

All three expected reviewers (claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high) completed their reviews.

Code Quality

Reviewers unanimously agreed the implementation is clean and follows established patterns well:

• Protobuf: The additive title = 5 field is backwards-compatible and safe for the externally consumed Alert message.
• Python backend: The title parameter is correctly keyword-only, defaults to None, uses clean_text() for sanitization, and only sets the proto field when non-None. Docstrings are consistent Numpydoc style across all four methods.
• Frontend: Good refactoring — the useEmotionTheme hook and inline markdownWidth calculation are replaced with the StyledAlertTextContent styled component using a $hasIcon transient prop. New styled components follow naming conventions (Styled prefix), use theme properties, and live in styled-components.tsx as expected.
• Styled components: StyledAlertTitle correctly uses theme.fontWeights.bold and theme.spacing.twoXS, with no hardcoded values.

One reviewer (claude-4.6-opus-high-thinking) noted that AlertBase in lib/streamlit/testing/v1/element_tree.py (used by AppTest) does not expose a title property — users can still access element.proto.title, but a convenience property would improve discoverability. This is a reasonable follow-up item, not a blocker.

Test Coverage

All reviewers agreed test coverage is thorough across all three layers:

• Python unit tests (alert_test.py): Four parameterized test methods covering title-present, title-absent, title-with-icon, and title-whitespace-cleaning, each expanded across all four alert types (16 test cases total).
• Frontend unit tests (AlertElement.test.tsx): Three tests covering title rendering, title absence (negative assertion), and title-with-icon combination.
• E2E tests (st_alert_test.py): Themed snapshot tests for all four alert types with titles plus a title+icon combination, a negative test for alerts without title, and properly updated element counts (34 → 39).

One reviewer (gpt-5.3-codex-high) raised a concern about missing snapshot baselines for the new assert_snapshot calls. After verification, the 5 new snapshot names (st_alert-error_with_title, etc.) do not have corresponding baseline images in e2e_playwright/__snapshots__/. However, the repo's e2e AGENTS.md explicitly states: "You can ignore missing or mismatched snapshot errors. These need to be updated manually." This is standard workflow — baselines are generated during CI and committed in a follow-up. This does not constitute a blocking issue.

Backwards Compatibility

All reviewers unanimously confirmed full backwards compatibility:

• The title parameter is keyword-only with None default — no existing code will break.
• The proto field title = 5 is additive; existing consumers ignore unknown fields.
• When title is not provided, the frontend renders identically to current behavior.
• The styled component refactoring is an internal implementation detail.

Security & Risk

All reviewers agreed there are no security concerns:

• The title is rendered as a React text node ({title}), automatically escaped — no XSS risk.
• Title content is sanitized via clean_text() on the backend.
• allowHTML={false} on StreamlitMarkdown for the body is preserved.
• No new dependencies, external requests, or dynamic code execution introduced.

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence:
  • All changes are confined to the Alert element's data flow (proto field, Python parameter, React component, styled components).
  • No changes to routing, auth, WebSocket, embedding, asset serving, CORS, security headers, or storage.
• Suggested external_test focus areas: N/A
• Confidence: High (all three reviewers unanimously agreed)
• Assumptions and gaps: None. This is a purely additive UI feature with no infrastructure or security boundary implications.

Accessibility

Two reviewers offered complementary perspectives:

• claude-4.6-opus-high-thinking: The title as a plain <div> with bold font weight is acceptable within an alert container — the title is part of the alert's content and will be read by screen readers as regular text within the alert region. A heading element would be semantically incorrect inside an alert context. No interactive elements or ARIA attributes are needed.
• gemini-3.1-pro: Suggested the title might benefit from a heading element (h3/h4) or ARIA roles for screen readers, but acknowledged the current implementation is acceptable.

Both perspectives are valid. The current implementation is acceptable for initial merge. A future enhancement could explore whether ARIA attributes or a semantic element improves the screen reader experience, but this is not blocking.

Recommendations

1. (Follow-up) Add a title property to AlertBase in lib/streamlit/testing/v1/element_tree.py for better AppTest discoverability.
2. (Follow-up) Consider adding alert typing tests in lib/tests/streamlit/typing/ covering the new title parameter (and existing parameters — this is a pre-existing gap).
3. (Expected workflow) Generate and commit e2e snapshot baselines after the first CI run.

Verdict

APPROVED: Well-implemented, fully backwards-compatible feature with thorough test coverage across all layers. All three reviewers confirmed clean code quality, no security concerns, and no external test needs. The sole "changes requested" concern (missing snapshot baselines) was verified to be standard repo workflow per the e2e AGENTS.md, not a blocking issue. Two of three reviewers approved outright.

This is a consolidated AI review by claude-4.6-opus-high-thinking, synthesizing reviews from claude-4.6-opus-high-thinking, gemini-3.1-pro, and gpt-5.3-codex-high.

This review also includes 2 inline comment(s) on specific code lines.

Summary

This PR adds an optional title parameter to the four status callout elements (st.error, st.warning, st.info, st.success), allowing users to display a bold title above the body text. The implementation spans the full stack: protobuf schema (Alert.proto), Python backend (alert.py), React frontend (AlertElement.tsx, styled-components.tsx), and comprehensive tests (Python unit, frontend unit, E2E with visual snapshots). The feature is fully backwards compatible — title defaults to None, the protobuf field is additive (string title = 5), and the frontend gracefully handles absence of title via falsy empty-string guard.

Reviewer consensus: All three reviewers (claude-4.6-opus-high-thinking, gemini-3.1-pro, gpt-5.3-codex-high) unanimously approved this PR with no blocking issues.

Code Quality

All reviewers agreed the implementation is clean, consistent, and follows existing patterns:

• Backend: The title parameter is added identically to all four alert methods as a keyword-only argument (SupportsStr | None). Title text is sanitized through clean_text(). The conditional protobuf field set (if title is not None) avoids unnecessary data.
• Frontend: The width-calculation fix from issue #6394 was properly refactored from an inline style into the new StyledAlertTextContent styled component. The transient $hasIcon prop follows Emotion conventions. The {title && ...} guard correctly handles the protobuf default empty string.
• Protobuf: New field string title = 5 at the next sequential field number — a safe, backwards-compatible addition. The proto comment about external service usage is noted; adding an optional field is safe.
• Docstrings: Thorough and consistent across all four methods.

No code quality issues were identified by any reviewer.

Test Coverage

All reviewers confirmed test coverage is comprehensive and multi-layered:

• Python unit tests (AlertTitleTest): 4 parameterized test cases across all 4 alert types — title present, title absent, title+icon combination, and title whitespace cleaning.
• Frontend unit tests: 3 new tests covering title rendering, absence of title element when not provided (good negative test), and title with icon combination. Follows RTL best practices.
• E2E tests: Themed snapshot tests for all 4 alert types with titles, plus title+icon variant. Uses stable locators via filter(has=...) with exact text matching. Includes a dedicated negative test (test_alert_without_title_has_no_title_element).
• Proto compatibility test: Updated to include the new title field.
• Snapshot coverage: 30 new snapshots covering all combinations of alert type × theme × browser.

Minor gap noted (non-blocking): Two reviewers (claude-4.6-opus-high-thinking, gpt-5.3-codex-high) noted the absence of typing tests in lib/tests/streamlit/typing/ for alert functions. Both agreed this is a pre-existing gap not introduced by this PR. Adding typing coverage for the new title argument would be a nice follow-up.

Backwards Compatibility

All reviewers unanimously confirmed full backwards compatibility:

• title defaults to None — existing code is unaffected.
• The protobuf field is an optional string with default "" — old clients ignore it, old servers send the default.
• The frontend gracefully handles absence of title (empty string is falsy → no title element rendered).
• No changes to public API surface or return types.

Security & Risk

No security concerns identified by any reviewer:

• Title is rendered as plain text via React's JSX ({title} inside a <div>), which auto-escapes special characters. No dangerouslySetInnerHTML, no Markdown rendering for title — no XSS risk.
• No new dependencies (frontend or backend).
• No file operations, external network calls, subprocess execution, or auth changes.
• The clean_text() function used for title sanitization is the same well-tested utility used for body text.
• Regression risk is low and limited to visual layout, which is covered by updated snapshots.

External test recommendation

• Recommend external_test: No
• Triggered categories: None
• Evidence: All changes are confined to the Alert element's display logic (protobuf field, Python parameter, React rendering, styled components). No routing, WebSocket, auth, embedding, asset serving, CORS, security header, or cross-origin changes.
• Suggested external_test focus areas: None needed.
• Confidence: High (unanimous across all three reviewers)
• Assumptions and gaps: None — this is a pure UI feature addition with no external integration surface.

Accessibility

Reviewers had minor divergence on accessibility semantics:

• claude-4.6-opus-high-thinking suggested using <strong> instead of <div> for StyledAlertTitle to improve semantic HTML for screen readers. The visual appearance would remain identical since <strong> defaults to bold.
• gemini-3.1-pro noted the title is rendered within the Notification container (which has role="alert" or role="status"), ensuring screen readers announce the title text naturally.
• gpt-5.3-codex-high confirmed no accessibility regressions.

Consolidation assessment: Both perspectives are valid. The current implementation is accessible because the parent alert container's ARIA role ensures the title content is announced. Using <strong> would be a minor semantic improvement (not a blocker). See inline comment for this suggestion.

Recommendations

1. Optional (low priority): Consider using <strong> instead of <div> for StyledAlertTitle to improve semantic HTML — see inline comment.
2. Optional (follow-up): Add typing test coverage in lib/tests/streamlit/typing/ for the new title argument on alert APIs to lock public API typing behavior.

Verdict

APPROVED: A clean, well-tested, backwards-compatible feature addition that adds title support to alert elements with comprehensive test coverage across all layers. All three reviewers unanimously approved with no blocking issues.

This is a consolidated AI code review by claude-4.6-opus-high-thinking, synthesizing reviews from claude-4.6-opus-high-thinking, gemini-3.1-pro, and gpt-5.3-codex-high.

This review also includes 1 inline comment(s) on specific code lines.