Gatsby: When using paths with no trailing slashes, first page navigated to gets skipped over in history.

[phulin]

Description

If you use paths with no trailing slashes, the first page you navigate to on your site will be replaced when you click the first navigation Link. As a result, using the back button from the second page will take you back to e.g. the blank-tab page in Chrome.

This occurs because production-app.js triggers a navigate call in reach/router to fix the trailing slash. Normally, reach handles navigate as following (irrelevant details omitted): when you click a link, a transitioning variable is set to true in the reach history state (see https://github.com/reach/router/blob/master/src/lib/history.js#L59). That variable is then set to false when componentDidUpdate is called on the LocationProvider (see https://github.com/reach/router/blob/master/src/index.js#L86). As long as transitioning is true, reach will use replaceState instead of pushState (see https://github.com/reach/router/blob/master/src/lib/history.js#L49).

In this instance, because the Router component has not rendered yet, componentDidUpdate never gets called on the LocationProvider, and so the navigate call (again, triggered by lack of trailing slash) causes transitioning to be set to true for the entire time you are viewing the first page loaded. So when you click any link from that page, the state is replaced, and the back button will not work.

This could be fixed by having reach simply complete the transition in componentDidMount (maybe this issue should be posted there as well), or by making some change to Gatsby to use the navigate api at a different time or in a different way. I don't understand Gatsby well enough to make the PR for that particular change. For now, I've fixed my application simply by adding trailing slashes to every path.

Steps to reproduce

Example:

Open in new tab: https://5cd6f4df5ba08e1ca222654d--uscode-io.netlify.com/26/152

1. Click the link to "this subtitle" on the second line of text.
2. The back button will not be enabled, as the history is still only one element long.

Expected result

The back button should take you back to the first page.

Actual result

The back button does nothing.

Environment

System: OS: macOS High Sierra 10.13.6 CPU: (4) x64 Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz Shell: 3.2.57 - /bin/bash Binaries: Node: 11.10.0 - /usr/local/bin/node npm: 6.9.0 - /usr/local/bin/npm Languages: Python: 2.7.16 - /usr/local/bin/python Browsers: Chrome: 74.0.3729.131 Firefox: 52.0.2 Safari: 12.1 npmPackages: gatsby: ^2.4.3 => 2.4.3 gatsby-image: ^2.0.41 => 2.0.41 gatsby-plugin-emotion: ^4.0.6 => 4.0.6 gatsby-plugin-manifest: ^2.1.1 => 2.1.1 gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12 gatsby-plugin-robots-txt: ^1.4.0 => 1.4.0 gatsby-plugin-sharp: ^2.0.37 => 2.0.37 gatsby-plugin-sitemap: ^2.1.0 => 2.1.0 gatsby-source-filesystem: ^2.0.33 => 2.0.33 gatsby-transformer-sharp: ^2.1.19 => 2.1.19 npmGlobalPackages: gatsby-cli: 2.5.13

[phulin]

Just noticed this is a (nearly synchronous) duplicate of #13971

[freiksenet]

Thank you for taking time to make this issue! Do you want to make a PR to Gatsby to fix it? We would really appreciate that.

[phulin]

I'm not sure this problem can be resolved without an update to reach/router, but would be curious if anyone has thoughts. The fundamental issue is that reach/router doesn't expect gatsby to call navigate before it mounts. We could maybe call replaceState ourselves before the router gets created and encapsulates the history object - I think we can't afterwards. But that would have to be at a different place in the code.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[ahmattox]

We're experiencing this issue as well and would love to have this reopened.

[chrisrikli]

Seeing this as well.

[magnusarinell]

Also seeing this. I believe this should be reopened. It is a major bug for basic functionality.

[david-nossebro]

Also seeing this issue, would be good if it could be re-opened and addressed.

[dwb]

This is fixed (for me, at least) in https://github.com/reach/router/commit/4b1d8f28b245ba726c95edde98c97b4db74a205d which is currently released in 1.3.0-beta.0. I added this to my package.json (only works with yarn I think):

  "resolutions": {
    "@reach/router": "1.3.0-beta.0"
  }