The last route in the history is a different url (call it /home). When I click on the back link, it does render the landing page, but in the url it shows /home. Then when I click on a link button on the landing page, it flashes the destination page, then immediately navigates to the home page.
I stepped through the debugger after clicking on the back link, and saw that in back.js, it does indeed mutate router.history and view.history to replace home with landing. But then it calls History.back(), which (in history.js) calls window.history.back(). It’s that call that changes the url to /home. So it looks like f7 has its own history list, and window.history have its native stack. How are they in sync? Something seems off here. Am I misunderstanding?
This alternative reproduces the original problem with back-link-force, that is, it displays the landing page but with the url /home in the address bar. And then doing a $f7router.navigate('/foo') click handler on landing page will flash the foo page and then navigate to the home page, even though it was supposed to of course just stay on the foo page.
Is $f7router.back with force:true supposed to work that way?
I guess you are using it with pushState? That won’t work correctly because it is not possible to modify window.history by any means. You can use a hacky workaround, like:
Yes pushState is enabled (except for iOS 9 due to its 100 history length limit thing). I reported this issue when testing in browser, but it is actually a Cordova app. I see elsewhere you encourage people to disable pushState in Cordova apps, so I will consider trying that. I had enabled it for mainly two reasons: (1) browser testing; (2) error reporting is more convenient with url path breadcrumbs.