scrollBehavior doesn't work for initial route in Firefox

[hworld]

Version

2.7.0

Reproduction link

https://github.com/vuejs/vue-router/tree/dev/examples/scroll-behavior

Steps to reproduce

Sorry, because this requires history navigation I can't give too great of a link. This manifests itself in the scroll-behavior example of the vue-router repo, though.

Basically, open a new tab to the scroll behavior example: http://localhost:8080/scroll-behavior/bar

Scroll just a little bit down and click on the "bar" link. It will correctly scroll to the top again. When you press back it will stay at the top, though, and not go to the previous scroll. By the way, for me this doesn't manifest in Chrome. I believe they are doing their own scrolling by default for history navigation through this: https://developers.google.com/web/updates/2015/09/history-api-scroll-restoration

Firefox should manifest the issue, though.

What is expected?

I expect it to be able to scroll properly even for initial route.

What is actually happening?

It doesn't scroll correctly.

---

The reason it happens is since the first request wasn't done through a pushState there is no state object stored. It needs the state object to store the scroll position.

This issue is probably known, however I think we may be able to fix it by doing a replaceState right away with a new state object, yeah?

[hworld]

hmm, maybe you can take a look at this @posva ? should be fairly straightforward i hope

[posva]

Yes, sorry, I'll take a look

[posva]

I'm really sorry for the delay, this could have been looked up the same day you made the issue and pr.
Thanks a lot 🙂

[hworld]

Thanks for taking a look at it! 🥇

[hworld]

Hey @posva Don't mean to be annoying, just curious if that was still planned on getting pulled in some time?

[posva]

Don't worry, it's ok to ping people when it takes time 🙂
I'm waiting for the review of Evan, I pinged him again

[jafri]

Still an issue, scrollBehavior doesn't work for initial route in latest chrome

[ghost]

Hi, the fix associated works probably well for firefox, but fails for ie9.

According to the rest of the code, the history.replaceState should be encapsulated in a try catch, falling back to do nothing probably, in the catch.

May a raise a PR about this?

[posva]

it was already fixed but not released yet (#1835)