Vue Router history not updating `history.state.back` after `ion-back-button` default click event

I have a back button (ion-back-button) that I disable if the next location the router would go back to is "/login" or "/". Just to cover all the bases, I’ve included null or undefined as block-list values as well:

const backButtonDisabled = (): boolean => {
      return !ionRouter.canGoBack() ||
          ["/login", "/", "", null, undefined].includes(history.state.back)
    }
}

What I’ve found on occasion is that after pressing the back button, the Router thinks that the next page to go back to is the current route, which creates some strange behavior in the back-button experience.

history.state.back === route.fullPath
=> true

this should never happen because theres no way in the app to navigate to the same page.

My current theory is that sometimes the ion-back-button default click event (I have no custom hooks) misfires in its attempt to notify the Router that the stack has changed, but I haven’t looked deeply into it.

Has anyone experienced anything like this?

I currently have a hacky guard that forces the router back again to try and correct for the wrong back path, but curious to see if other people have found a better workaround or have spotted the source of this issue.

      /* 
         this should really never be the case
         not sure how we get into this state, but for now
         force history back again so that `history.state.back !== currentPath`
       */

      if (history.state.back === route.fullPath) {
        router.back();
      }

@ionic/vue-router@^5.4.0
@ionic/vue@^5.4.0
vue-router@^4.0.0-0
vue@^3.0.0-0

Hard to say what the issue might be without being able to reproduce this on my end. Can you provide a GitHub repo with an example app?

I’ll throw one together @ldebeasi

I was looking at the Ionic router code last night and it may be a timing issue around when my backButtonDisabled method calls vs when the event listener for the router picks up a route change.

Will test.

After some testing, turns out to be a bug. Issue here:


and repro code here: