Safari (iOS 16) odd history behaviour (browser back/forward buttons) #1076
Comments
|
In case anybody comes across this in the future, I believe I have resolved this by doing the following:
<script>
if ( !!window.performance && window.performance.getEntriesByType("navigation")[0].type === "back_forward") {
window.location.reload();
}
</script>One thing to note is that the history API in Safari will behave in unpredictable ways if you are using a self-signed SSL certificate, even if you have trusted the certificate (for example, during development). |
|
Reopening this because I hadn't fully solved the mystery after all :/ What I think is happening is that the value of Using a timeout to delay updating the value of function saveCurrentPageToHistory() {
var elt = getHistoryElement();
var path = currentPathForHistory || location.pathname+location.search;
triggerEvent(getDocument().body, "htmx:beforeHistorySave", {path:path, historyElt:elt});
if(htmx.config.historyEnabled) history.replaceState({htmx:true}, getDocument().title, window.location.href);
saveToHistoryCache(path, cleanInnerHtmlForHistory(elt), getDocument().title, window.scrollY);
}
function pushUrlIntoHistory(path) {
if(htmx.config.historyEnabled) history.pushState({htmx:true}, "", path);
setTimeout(function() {
currentPathForHistory = path;
}, 100)
}
function replaceUrlInHistory(path) {
if(htmx.config.historyEnabled) history.replaceState({htmx:true}, "", path);
setTimeout(function() {
currentPathForHistory = path;
}, 100)
} |
|
I've been down a rabbit hole, but I may have some insight on what is happening here. The fix I posted above solves history navigation between htmx'd links, providing you enter the website and only click htmx'd links. But, it still occurs when you click two or more conventional links within the same website, before you click any htmx'd links. To illustrate:
Now, the interesting thing is that 5) does actually work as expected but only if I was able to confirm this by manually inserting the history entries for My gut feeling is that Safari is not inserting the history items (despite receiving them correctly in the right order) because the time from the last user interaction exceeded a certain margin (500ms). I can only imagine this is a security feature intended to prevent websites inserting multiple history items without human interaction (for example to stop users leaving a website). Another explanation might be that the So, the question is how can we solve this? Is it a consequence of the specific way Some thoughts:
(I'm no expert, I'm just looking at how it's done in this bare bones example: https://github.com/lesjames/history-api-demo).
|
|
For anyone finding this, Apple reverted to the previous back/forward button behaviour in Safari on iOS 16.1 (i.e. they removed or refactored the intervention that was breaking htmx history). History state interventions may reappear in future versions of Safari or other browsers, so the PR referenced above may be needed at a future date. |
I'm seeing some odd behaviour with Safari on iOS when navigating using the back/forwards buttons in the browser app and using boosted links. Sometimes pages are skipped and the browser loads a previous website or a page out of sequence.
This is much more likely to occur when htmx is loaded in the
<body>or when a request for a dynamically generated page or html fragment loads slowly or is quite large. Moving htmx to the<head>and static caching the html (so content loads more quickly) reduces the chances of it happening.Further strangeness: if you open a new browser tab and load the site it does not tend to happen. If however you follow a link to the site, or visit another site in the same tab before visiting your site, then it is far more likely to happen.
This does not happen with React or Vue/Nuxt SPAs in the latest Safari, the problem seems to be specific to htmx.
Possibly related to #854
The text was updated successfully, but these errors were encountered: