you probably wanna place a breakpoint wherever it does goBack() and examine why it decides to do so with nothing on the in-app history stack. maybe it reads some stale variable
fwiw i found it structured pretty well. but id maybe start at the opposite end and override history.back and history.go with { debugger } and work backwards
aha - createMemoryHistory thinks there are 4 items in the stack, because it's counting /notifications twice. whereas the browser (and interestingly the devtools) correctly thinks there are 3
ok when the back button is intercepted, it finds the matching state in the history and resets to that point. however, seems like it pushes an item to memoryHistory rather than resetting to it. now to find out how resetRoot works
ah ok so it's calling history.replace, making on back button press it goes from
/
/notifications
/profile/etc/post/etc
to
/
/notifications
/notifications
Hmm this is an interesting bug. Handling browser navigation is basically just a guess as to where in the history it lands, so keeping the internal history and browser history synced is really hard. I wonder how react-router handles this