Back button changes URL query params but not `st.query_params` until user leaves page and comes back

[PhilipCavanagh]

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

When using st.query_params to modify the current URL, new items are added to the browser history so one can navigate forwards and backwards to the URLs that have previously been set.

• On using the forwards and backwards buttons in the browser, the URL changes as expected, but calls to st.query_params see only the final version of the URL.
  • This only happens if st.navigation is used - if the app is single-page, the forwards and backwards buttons don't trigger a rerun of the back end at all (as in Back button doesn't work with elements synced with query params #13853).
• If the user navigates to a different page, the forwards and backwards buttons DO cause the st.query_params to change.

Reproducible Code Example

import datetime

import streamlit as st

def page():
    st.write(datetime.datetime.now())

    if st.button("Increment Query Param"):
        value = int(st.query_params.get("value", "0"))
        st.query_params["value"] = value + 1

    st.write(st.query_params)

st.navigation([
    st.Page(page, title="Query Params", default=True),
    st.Page(lambda: None, title="Other Page", url_path="other"),
]).run()

Steps To Reproduce

1. Open the app URL in a browser
2. Press the "Increment Query Param" button twice - the URL should now end ?value=2
3. Press the browser's back button
4. Press the browser's forwards button
5. Click on "Other Page" in the nav bar
6. Press the browser's back button
7. Press the browser's back button again

Expected Behavior

1. The URL has no query parameters and the printed st.query_params are empty
2. The URL ends with ?value=2 and the printed st.query_params shows "value": "2"
3. The URL ends with ?value=1 and the printed st.query_params shows "value": "1"
4. The URL ends with ?value=2 and the printed st.query_params shows "value": "2"
5. The URL has no query parameters, no content is shown
6. The URL ends with ?value=2 and the printed st.query_params shows "value": "2"
7. The URL ends with ?value=1 and the printed st.query_params shows "value": "1"

Current Behavior

After step 3: the printed st.query_params shows "value": "2" (the timestamp and URL do update, but the st.query_params appear to be cached)

Notes:

• after steps 5 and 6 (navigate to a different page and back), step 7 (apparently identical to step 3) works as expected
• replacing step 5 with "navigate to an external site" also makes step 7 work, albeit now in a new session

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

• Streamlit version: 1.54.0
• Python version: 3.11.11, 3.13.1
• Operating System: Windows 11
• Browser: Edge 145.0, Chrome 145.0, Firefox 147.0

Additional Information

No response

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[github-actions]

This is a bug where browser back/forward navigation on the same page sends stale query parameters to the server, causing st.query_params to reflect the wrong values. The root cause is in the frontend onHistoryChange handler in App.tsx. When the browser's popstate event fires, the browser URL updates correctly, but App.getQueryString() reads from this.state.queryParams (which still holds the last server-set value) rather than from document.location.search. The onHistoryChange handler calls onPageChange with preserveQueryParams=true but does not pass the actual URL query string, so the stale state value is sent to the server in the rerun BackMsg. This issue was partially addressed in PR #13129 (which fixed cross-page back navigation for #9279), but the same-page case was not covered.

A potential fix would be to have onHistoryChange explicitly read and pass document.location.search as the queryString parameter to onPageChange, ensuring the actual browser URL query string is sent to the server instead of the stale React state.

Related Issues

• Back button doesn't work with elements synced with query params #13853 - Back button doesn't work with elements synced with query params: Very closely related — reports that browser back button doesn't trigger a rerun for single-page apps using st.query_params. The current issue (Back button changes URL query params but not st.query_params until user leaves page and comes back #13963) notes this same single-page behavior and extends it to the multipage case where reruns do occur but with stale params.
• Query Params not preserved on first script run after using the browser "back" button to back to a previous page. #9279 (closed) - Query Params not preserved on first script run after using browser "back" button: The predecessor bug where query params were lost on cross-page back navigation. It was fixed in PR Fix query parameters not preserved on back navigation #13129 by adding preserveQueryParams, but that fix introduced the stale-state behavior described in this issue for same-page navigation.
• (CommunityCloud) Moving slider seems to generate 2 new (empty) window.history states #9878 - Moving slider generates empty window.history states: Related browser history management issue where widget interactions create spurious history entries, compounding back-button navigation problems.

---

This is an automated triage comment using opus-4.6-thinking. Please verify the suggested labels and related issues.