Bug 262542
| Summary: | history.back() does not restore scroll position | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Christian Taylor <christianbtaylor> |
| Component: | History | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | beidson, cdumez, simon.fraser, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 16 | ||
| Hardware: | Mac (Intel) | ||
| OS: | macOS 13 | ||
Christian Taylor
When navigating back to a long page using `history.back()` or `history.go(-1)` the browser returns to the page and resets the scroll position to `0`.
However, performing the same navigation using the browser's "back" button restores the scroll position on the previous page.
I would expect `history.back()` to behave the same as clicking the back button and restore the previous page's scroll position.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Simon Fraser (smfr)
Do you have an example of a page that shows this bug?
Radar WebKit Bug Importer
<rdar://problem/116408614>
Christian Taylor
Ah, I put together a demo and found an explanation.
My link markup looked like this:
`<a href="/previous" onclick="history.back()">Back</a>`
I realized `back()` is asynchronous so the `href` is being followed as though the link were clicked.
If I change the `onclick` to `event.preventDefault();history.back()` things work as I would expect.
I was thrown off because `onclick="history.back()"` works in FireFox without needing the `preventDefault()`.
I think this report can be closed. Thanks for letting me rubber duck this issue.
Simon Fraser (smfr)
Thank you for checking.