Pages: preserveState prevents the destination URL from being committed
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript, vite
- Domain
- backend-api-design, frontend
Research direction
Start in packages/void/src/pages/navigation-engine.ts, especially makeCommit() and its history-writing condition, then trace how normal visits, router.refresh(), and back/forward navigation select commit behavior. Run the reported unit tests with vp test run and locate the shared-router regression tests. Done means preserveState visits update the URL, replace still replaces, refresh and history navigation add no entries, and tests cover state preservation and URL behavior.
Written by the indexing model from the issue text.
Description
Description
Calling router.visit('/settings', { preserveState: true }) updates the rendered page, but leaves the browser URL pointing to the previous page.
This appears to couple component state preservation with history updates.
Environment
- Commit:
2ceab89154dc6e0c3fa5525f7bd4d1d5f3d0aa64 - Package version in the repository:
1.1.12 - Chromium Headless Shell:
134.0.6998.35 - Playwright:
1.64.1
Steps to reproduce
- Start on
/case. - Navigate using:
await router.visit('/settings', {
preserveState: true,
});
- Return a valid Pages response for
/settings. - Compare the rendered page with
window.location.pathname.
Actual behavior
The destination page renders, but the address bar remains on /case.
In an isolated browser fixture using the production createVoidRouter():
| Value | Result |
|---|---|
| Rendered page | /settings |
window.location.pathname |
/case |
router.path after the visit |
/case |
This reproduced in all three browser runs. A direct regression test against the shared router also fails because history.pushState() is not called.
The unit tests were run with vp test run. The browser fixture was run separately through a Node.js script using Playwright; it was not run as an existing Void browser integration suite. The fixture exercises the actual client runtime with a small HTTP server; this was not a full production-build test across every adapter.
Expected behavior
The rendered page and browser URL should both reflect /settings.
preserveState should control component state preservation independently of whether a normal visit writes history. replace should continue to select between replacing and adding an entry.
Relevant implementation
In makeCommit(), history updates are skipped whenever preserveState is true:
if (!options.preserveState) {
const historyUrl = commitTarget.fetchUrl + commitTarget.hash;
scrollRestoration.writeHistory(historyUrl, !!options.replace);
}
Separating history-writing decisions from state preservation would also need to retain the existing behavior of router.refresh() and back/forward navigation, which should not add history entries.
Acceptance criteria
- A normal visit with
preserveState: trueupdates the destination URL. replace: truereplaces the current entry.router.refresh()and back/forward navigation do not add entries.- Regression coverage checks both state preservation and URL/history behavior.
- Dominant language
- TypeScript
- Stars
- 402
- Forks
- 32
- Avg merge
- 11h 52m
- Merged PRs (30d)
- 88
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from voidzero-dev/void
-
bug
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
voidzero-dev/void#428 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
voidzero-dev/void#511 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
voidzero-dev/void#510 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
voidzero-dev/void#509 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
voidzero-dev/void#507 ·
Maintainers usually reply within 1 day
All issues in voidzero-dev/void
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
logancyang/obsidian-copilot#3753 ·
Maintainers usually reply within 1 day
-
area: presentation severity: important
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
voithos-labs/aragonite#763 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
diegosouzapw/OmniRoute#17386 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 Half a day Newbie friendliness 72/100
super-productivity/super-productivity#10982 · 1 comment ·
Maintainers usually reply within 1 day