Gatsby: a entry page with no trailing slash will break back button behaviour for that page

Created on 20 Sep 2018  路  30Comments  路  Source: gatsbyjs/gatsby

Description

When a users first page on the site is a page which has been created with no trailing slash.
Then that page will be skipped if the user uses the back button on the next page they view

Steps to reproduce

in the examples/no-trailing-slashes gatsby folder

  • run the build, then gatsby serve
  • load up - http://localhost:9000/a as the first page you view on the site
  • click on the link for http://localhost:9000/b
  • press back button

Expected result

You should be on http://localhost:9000/a

Actual result

If you opened the entry page in a new tab then you'll probably see whatever is the default starting page for a new browser tab

Environment

System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 8.10.0 - /usr/bin/node
Yarn: 1.9.4 - /usr/bin/yarn
npm: 3.5.2 - /usr/bin/npm
Browsers:
Chrome: 69.0.3497.81
Firefox: 62.0
npmPackages:
gatsby: ^2.0.0 => 2.0.4
gatsby-plugin-google-analytics: ^2.0.5 => 2.0.6
gatsby-plugin-offline: ^2.0.5 => 2.0.5
npmGlobalPackages:
gatsby-cli: 1.1.58

bug

Most helpful comment

Here's a kind of workaround anyone can use for now, place the following code in gatsby-browser.js

import {globalHistory} from '@reach/router';

export const onInitialClientRender = () => {
  /**
   * This is a workaround for a bug in Gatsby
   *
   * See https://github.com/gatsbyjs/gatsby/issues/8357 for more details
   */
  globalHistory._onTransitionComplete();
}

All 30 comments

@tony1377 Thanks for reporting this issue. We'll look into this.

Hey folks, just wondered if anyone has had a chance to look into this issue?

Also wondering ^ encountering same issue. I can provide our production site with the issue if helpful

I can't reproduce this, e.g. with this repository: https://github.com/a-botermans/test-case-history-bug

However the steps described in this repo are confirmed. But this line is important:

Change URL manually into /blog

You don't mention that. And what you describe has no issue as far as I can tell.

I believe the problem is caused by the following code (please take this with a grain of salt as I don't have much react experience)

https://github.com/gatsbyjs/gatsby/blob/bbeae87ef12d8beebd391c3d8c8c4f584db36c67/packages/gatsby/cache-dir/production-app.js#L64-L84

this causes reach router to set transitioning to true (which causes reach to do a history.replaceState instead of .pushState for the next navigation) until _onTransitionComplete is called

https://github.com/reach/router/blob/b60e6dd781d5d3a4bdaaf4de665649c0f6a7e78d/src/lib/history.js#L45-L62

but onTransitionComplete is only called in the componentDidUpdate method of reach

https://github.com/reach/router/blob/b60e6dd781d5d3a4bdaaf4de665649c0f6a7e78d/src/index.js#L86-L90

since componentDidUpdate does not get called before the next navigation in most cases, transitioning is set to true and reach router does a replacement of the history

@LekoArts here are the reproduction steps based on that repo:

assuming base url is: https://confident-goldstine-20bc0e.netlify.com/

  1. navigate to https://confident-goldstine-20bc0e.netlify.com/blog/ (note the trailing slash which is opposite of how the route is configured)
  2. Click on any other route
  3. Use your browser's back button and you will be on the page you were on prior to step 1

This is more noticeable when you have the site configured to have trailing slashes as the user will most likely not add the trailing slash for a well known route. In my case the route is https://smartcar.com/docs (which also exhibits the above behavior)

Here's a kind of workaround anyone can use for now, place the following code in gatsby-browser.js

import {globalHistory} from '@reach/router';

export const onInitialClientRender = () => {
  /**
   * This is a workaround for a bug in Gatsby
   *
   * See https://github.com/gatsbyjs/gatsby/issues/8357 for more details
   */
  globalHistory._onTransitionComplete();
}

The above workaround by @gurpreetatwal worked for my own project. Does anyone know if the fix for this issue should be done in Gatsby or in Reach Router?

Also commenting on here - seeing the same issue using Netlify & Gatsby.

@gurpreetatwal 's solution did not work for my site - Has anyone found other solutions?

I did suffer from a similar bug: when navigating around my app clicking links, all went well, but when pressing the back button or using window.location.back it was sending me to the root path (Not only skipping one history state as others have mentioned).
Anyway I found that I had a replaceState() call in a onpopstate event listener. I removed it and my problem went away.

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鈥檚 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!

Thanks for being a part of the Gatsby community! 馃挭馃挏

@kakadiadarpan Are there any team members who'll have time to look into this? It looks like there may be some good hints at a proper solution based on what @gurpreetatwal posted above.

I'm seeing the same issue, uncommenting these lines seems to have worked for now: https://github.com/gatsbyjs/gatsby/blob/bbeae87ef12d8beebd391c3d8c8c4f584db36c67/packages/gatsby/cache-dir/production-app.js#L80-L83

I have got some mileage out of @gurpreetatwal's workaround, but I'm not sure why.

I had this problem with a site running on Netlify. Sometimes (and it's difficult to know exactly how to reliably reproduce) clicking a link wouldn't seem to increase the length of window.history, meaning when you pressed back you'd skip a page. But sometimes it would be fine. It's difficult to know how to pin down whether this is due to trailing slashes, or something else, but @gurpreetatwal's fix seems to help.

I also didn't seem to have an issue in Firefox...

I don't think it's linked to Netlify because I can reproduce locally

@jalada can reproduce in firefox, and also locally, when built.

gatsby develop is working correctly.

Having the same issue. Only occurs with gatsby build (not develop) and locally as well as on Netlify.
@gurpreetatwal 's fix above seems to fix it. disabling gatsby-plugin-remove-trailing-slashes plugin appears to have no effect.

I had the same issue. Our app is deployed on Heroku. @gurpreetatwal's fixed worked, but only after this issue cost of days of pain. Hoping this gets resolved soon.

We are having this issue regardless of host (it's reproduce-able with gatsby serve locally). Placing trailing slashes fixes the issue, but without them we get the same issue of skipping a history location (going back 2).

I don't currently have this issue with the latest version of Gatsby, maybe it's fixed?

@t2ca I have updated my test repo : https://github.com/a-botermans/test-case-history-bug
and it still fails so I doubt it was fixed

I have the same issue, back button doesn't work and typing manual pathname doesn't redirect to the page. @gurpreetatwal's solution didn't work for our app.
I doubt that it is not working due to our gatsby version which is v2.13.39.

I had the same problem in my project but not for every link. I tried to apply the solutions here mentioned but it had the drawback that when going back it reloaded everything. I continued researching and found something, crazy, but worked.

Let me know if this worked for you.

I am using a WordPress site as a source. I was doing:

<Link to={/help/${node.slug}/}>{node.title || null}</Link>

It was fixed removing the las "/". Like this:

<Link to={/help/${node.slug}}>{node.title || null}</Link>

This is now fixed with the Gatsby v2.19.15 release! 馃帀

@reach/router v1.3.1 has the corresponding fix.

I confirm that it is fixed in the test case I created with latest Gatsby Release https://github.com/a-botermans/test-case-history-bug

@bernharduw @a-botermans this means we can close this issue?

For me yes :)

We're marking this issue as answered and closing it for now but please feel free to reopen this and comment if you would like to continue this discussion. We hope we managed to help and thank you for using Gatsby! 馃挏

v2.19.15

i can confirm the fix is working fine!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kalinchernev picture kalinchernev  路  3Comments

jimfilippou picture jimfilippou  路  3Comments

mikestopcontinues picture mikestopcontinues  路  3Comments

andykais picture andykais  路  3Comments

theduke picture theduke  路  3Comments