It's a regression introduced in 6.1
see https://github.com/storybookjs/storybook/issues/11677#issuecomment-707709420
Hash should remain there
@Hypnosphi are you sure this wasn't in 6.0?
Maybe it was, but for some reason it didn't manifest itself in our case cc @andrey-skl
Sorry everybody for misleading. I checked again and found that:
Yes, the hash was stripping in 6.0 (6.0.28). But it did not affect our case because it was stripped a little bit after sroty initialization.
For example, if I open http://localhost:9999/iframe.html?id=components-button--basic#test with [email protected] and log window.location in the first line of the story, it is: http://localhost:9999/iframe.html?id=components-button--basic#test
With 6.1.0-rc.0 it logs: http://localhost:9999/iframe.html?id=components-button--basic&viewMode=story
Ahh, ok. My guess is the difference is the new loaders feature which adds an await into the story render process (awaiting nothing usually), which probably rearranges the execution of some code.
Huzzah!! I just released https://github.com/storybookjs/storybook/releases/tag/v6.1.8 containing PR #13308 that references this issue. Upgrade today to the @latest NPM tag to try it out!
npx sb upgrade
Closing this issue. Please re-open if you think there's still more to do.
@shilman @Hypnosphi thanks a lot for a quick fix, our case works perfect so far!
Most helpful comment
Sorry everybody for misleading. I checked again and found that:
Yes, the hash was stripping in 6.0 (6.0.28). But it did not affect our case because it was stripped a little bit after sroty initialization.
For example, if I open
http://localhost:9999/iframe.html?id=components-button--basic#testwith [email protected] and log window.location in the first line of the story, it is:http://localhost:9999/iframe.html?id=components-button--basic#testWith 6.1.0-rc.0 it logs:
http://localhost:9999/iframe.html?id=components-button--basic&viewMode=story