-
Notifications
You must be signed in to change notification settings - Fork 4k
Allow setting duration for st.toast
#11872
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
duration for st.toastduration for st.toast
✅ PR preview is ready!
|
duration for st.toastduration for st.toast
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds the ability to configure toast duration in Streamlit, allowing users to control how long toast notifications remain visible. This addresses a longstanding feature request (#7047) by introducing flexible duration settings.
Key changes:
- Added
durationparameter tost.toast()API with support for "short" (4s), "long" (10s), "infinite", or custom integer values - Updated protobuf definition to include optional duration field
- Modified frontend components to respect custom duration settings
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| proto/streamlit/proto/Toast.proto | Added optional duration field to Toast protobuf message |
| lib/streamlit/elements/toast.py | Added duration parameter to toast function with validation logic |
| lib/tests/streamlit/toast_test.py | Added comprehensive unit tests for duration variants |
| frontend/lib/src/components/elements/Toast/Toast.tsx | Updated to use duration from protobuf and apply to autoHideDuration |
| frontend/lib/src/components/core/Block/ElementNodeRenderer.tsx | Simplified props by passing entire element instead of individual fields |
| frontend/app/src/components/EventContainer/EventContainer.tsx | Updated comment to clarify default duration behavior |
| e2e_playwright/st_toast.py | Added test app with duration examples |
| e2e_playwright/st_toast_test.py | Added e2e test for duration functionality |
lib/streamlit/elements/toast.py
Outdated
| elif duration == "infinite": | ||
| toast_proto.duration = 0 | ||
| else: | ||
| toast_proto.duration = duration |
Copilot
AI
Aug 7, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code doesn't validate that integer duration values are non-negative. Negative values could cause unexpected behavior in the frontend.
| toast_proto.duration = duration | |
| if isinstance(duration, int): | |
| if duration < 0: | |
| raise StreamlitAPIException( | |
| "Toast duration must be a non-negative integer, got %r." % duration | |
| ) | |
| toast_proto.duration = duration | |
| else: | |
| raise StreamlitAPIException( | |
| "Invalid value for duration: %r. Must be 'short', 'long', 'infinite', or a non-negative integer." | |
| % duration | |
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Why are we not checking this? It makes sense to me to have something like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added an exception for wrong duration values 👍 But I think this is one of the cases where it's a bit hard to draw a line since it's quite unlikely that a user/AI would be confused here and put in a negative integer. And we are far from protecting against all invalid values in our API via exceptions. And even if we had that as a goal, it could end up in a large number of extremely specific exceptions. This could be something we would need to pay for if we ever get to the exception handling refactoring or internationalisation. At the moment, I'm treating it as: add an exception whenever a user might be confused by the possible values / usage and be more lax on other parameters.
Describe your changes
Allow setting the toast
durationtoshort(4s default),long(10s) orinfinite(until dismissed) or int (number of seconds)GitHub Issue Link (if applicable)
Testing Plan
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.