Add ability to disable setActiveHash (6b6d268)

[achendrick]

setActiveHash is causing issues on my site (#272) (6b6d268)
I just updated to 0.9.0 and this seems to be the only issue I've run into. 👍

I have several non sidebar links, and I also have a media player that updates the hash and scroll position based on the timestamp of the player.
This new default capability breaks this functionality.

It's a nice default in probably >90% of use cases, so just the ability to disable would be awesome.

[achendrick]

Happy to make a PR if this is an acceptable change.

[ulivz]

setActiveHash is causing issues on my site...

Would you please provide the details about these issues?

[ulivz]

Maybe we can add option to disable the default hash active behaviors.

[achendrick]

Ya, my thought was to have a theme config that would allow for disabling this feature.

I didn't look too closely at it, but I think the issue lies in if the URL has an existing hash that isn't in the sidebar links or the header anchors the auto scrolling behavior seems to freak out. (bounce back and forth and default to no hash set, leaving you stuck at the top of the page)

My site has a vue-plyr component, and as the player plays, it updates the hash in the url w/ the players timestamp (allows for easily sharing the exact spot the listener was at). There are also links (bookmarks) in the page that can jump to sections in the player.

Anyways, without it being a complete re-thinking of what instances to scroll, and observing hash changes, other anchors, etc. I think just allowing for disabling of this feature seems to be the shortest path forward.

[achendrick]

Still trying to find other paths forward, you can kind of see an issue doing these steps:

1. Make a really short window (450px should do it)
2. Go to https://vuepress.vuejs.org/guide/#hexo
3. Scroll

Observe that the #hexo hash gets changed to the nearest h2 anchor's hash (#why-not) rather than preserving the h3's anchor's hash. In fact, clicking one of the anchors for the h3 doesn't even preserve the hash for that anchor at all, so you'd end up just sharing a deep link to the h2 instead (#why-not).

So again, I think the issue lies in the assumption in this logic that the only valid anchor links must be in the sidebar and have the .header-anchor class in the page, all things my site doesn't perfectly adhere to ie. no sidebar deep links and lots of other deep link anchors on the page that don't have an <h123456> as a parentElement (anchor.parentElement.offsetTop)

[ulivz]

I cannot find the point, so I don't think I can fully understand your problem, but PR welcome.

[ulivz]

Close by #489