-
Notifications
You must be signed in to change notification settings - Fork 4k
Description
Checklist
- I have searched the existing issues for similar issues.
- I added a very descriptive title to this issue.
- I have provided sufficient information below to help reproduce this issue.
Summary
Query Params in the URL sometimes do not get synced to the server when the client navigates backwards in window history to a previous page.
Reproducible Code Example
# in main.py
import streamlit as st
st.write("My Query Params are")
st.write(st.query_params)
st.checkbox("foo")
# in page1.py
st.write("My Query Params are")
st.write(st.query_params)Steps To Reproduce
- Start the app by navigating to localhost:8501/?mykey=myvalue
- See
{mykey: myvalue}on the main page - Navigate to Page1 via the sidebar
- Query string disappears from the URL as expected
- Navigate back to the Main page via the browser back button.
- Note that
?mykey=myvalueis still present in the URL after clicking "back" as expected
Expected Behavior
The first script run of main.py after using the back button should display {mykey: myvalue} in the written query_params.
Current Behavior
The first script run of main.py after using the back button will not display any items in st.query_params.
Upon interacting with any element on the page (say, the checkbox), subsequent reruns will include the params from the URL.
This is happening because for some reason the client App.tsx's onHistoryChanged function is not picking up the "old" query params when it sends a BackMsg to the server to rerun main.py the first time, but it does pick them up on subsequent reruns.
Is this a regression?
- Yes, this used to work in a previous version.
Debug info
- Streamlit version: 1.37.1 (develop nightly)
- Python version: 3.12
- Operating System: Linux
- Browser: Opera One(version: 112.0.5197.53)
Additional Information
I am currently working on this in conjunction with #8112 since the behavior is closely intertwined with feature changes that need to be made there. If someone wants to fix it before that feature is done, it's fine. However if you find the fix requires architectural changes, we'll probably want to sync up on approaches.