Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a entry page with no trailing slash will break back button behaviour for that page #8357

Closed
tony1377 opened this issue Sep 20, 2018 · 30 comments
Labels
type: bug An issue or pull request relating to a bug in Gatsby

Comments

@tony1377
Copy link

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

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

@kakadiadarpan kakadiadarpan added type: bug An issue or pull request relating to a bug in Gatsby status: confirmed Issue with steps to reproduce the bug that’s been verified by at least one reviewer. status: inkteam to review labels Sep 21, 2018
@kakadiadarpan
Copy link
Contributor

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

@chrisbuttery
Copy link
Contributor

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

@kylealwyn
Copy link

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

@LekoArts LekoArts added status: needs reproduction This issue needs a simplified reproduction of the bug for further troubleshooting. status: confirmed Issue with steps to reproduce the bug that’s been verified by at least one reviewer. and removed status: confirmed Issue with steps to reproduce the bug that’s been verified by at least one reviewer. status: needs reproduction This issue needs a simplified reproduction of the bug for further troubleshooting. labels Dec 14, 2018
@LekoArts
Copy link
Contributor

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.

@gurpreetatwal
Copy link

gurpreetatwal commented Jan 11, 2019

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)

const { page, location: browserLoc } = window
if (
// Make sure the window.page object is defined
page &&
// The canonical path doesn't match the actual path (i.e. the address bar)
__PATH_PREFIX__ + page.path !== browserLoc.pathname &&
// ...and if matchPage is specified, it also doesn't match the actual path
(!page.matchPath ||
!match(__PATH_PREFIX__ + page.matchPath, browserLoc.pathname)) &&
// Ignore 404 pages, since we want to keep the same URL
page.path !== `/404.html` &&
!page.path.match(/^\/404\/?$/) &&
// Also ignore the offline shell (since when using the offline plugin, all
// pages have this canonical path)
!page.path.match(/^\/offline-plugin-app-shell-fallback\/?$/)
) {
navigate(
__PATH_PREFIX__ + page.path + browserLoc.search + browserLoc.hash,
{ replace: true }
)
}

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

@gurpreetatwal
Copy link

gurpreetatwal commented Jan 11, 2019

@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)

@gurpreetatwal
Copy link

gurpreetatwal commented Jan 11, 2019

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();
}

@Simon-Tang
Copy link
Contributor

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?

@GarrettJMU
Copy link
Contributor

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

@GarrettJMU
Copy link
Contributor

GarrettJMU commented Feb 16, 2019

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

@dotlouis
Copy link
Contributor

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.

@gatsbot
Copy link

gatsbot bot commented Mar 9, 2019

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!

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

@gatsbot gatsbot bot added the stale? Issue that may be closed soon due to the original author not responding any more. label Mar 9, 2019
@Simon-Tang Simon-Tang added not stale and removed stale? Issue that may be closed soon due to the original author not responding any more. labels Mar 9, 2019
@Simon-Tang
Copy link
Contributor

@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.

@supermoos
Copy link

I'm seeing the same issue, uncommenting these lines seems to have worked for now:

navigate(
__PATH_PREFIX__ + page.path + browserLoc.search + browserLoc.hash,
{ replace: true }
)

@jalada
Copy link

jalada commented Apr 11, 2019

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...

@a-botermans
Copy link

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

@leonardodino
Copy link
Contributor

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

gatsby develop is working correctly.

@robthompsonweb
Copy link

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.

@lexishanson
Copy link
Contributor

lexishanson commented Aug 9, 2019

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.

@Jimmydalecleveland
Copy link

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).

@t2ca
Copy link
Contributor

t2ca commented Sep 26, 2019

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

@a-botermans
Copy link

@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

@aaayumi
Copy link

aaayumi commented Oct 29, 2019

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.

kristianfreeman added a commit to cloudflare/workers.cloudflare.com that referenced this issue Nov 25, 2019
This isn't an ideal fix, but this bug is apparently a known thing in Gatsby and the suggested solution [here](gatsbyjs/gatsby#8357 (comment)) has resolved #35. We considered fixing this in our Workers script but we generally want the Workers part of this to be as out of the box as possible, so we're resolving on the Gatsby side instead.

Closes #35
adamschwartz pushed a commit to cloudflare/workers.cloudflare.com that referenced this issue Nov 25, 2019
This isn't an ideal fix, but this bug is apparently a known thing in Gatsby and the suggested solution [here](gatsbyjs/gatsby#8357 (comment)) has resolved #35. We considered fixing this in our Workers script but we generally want the Workers part of this to be as out of the box as possible, so we're resolving on the Gatsby side instead.

Closes #35
@rodrigogiraudo
Copy link

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>

@bernharduw
Copy link

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

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

@a-botermans
Copy link

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

@wardpeet
Copy link
Contributor

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

@a-botermans
Copy link

For me yes :)

@wardpeet
Copy link
Contributor

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! 💜

@GizmoMKD-zz
Copy link

v2.19.15

i can confirm the fix is working fine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug An issue or pull request relating to a bug in Gatsby
Projects
None yet
Development

No branches or pull requests