Freecodecamp: Unable to use browser "back" button to return to previous page

[Sky020]

Describe the bug
Within the _learn_ section of fCC, I am unable to use the browser's _back_ button to return to an earlier point in the page history. This is a minor issue, and only occurs under specific circumstances, but I wonder if it is indicative of another error in the matrix.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://www.freecodecamp.org/ or any other fCC page.
2. Right click on the _/learn_ button in the nav.
3. Open link in new tab.
4. Click on any other link pertaining to the curriculum.
5. Be shocked and horrified that navigation history is not available.

Expected behavior
Once in the curriculum page, after navigating to any lesson within the same tab, the navigation history should be available to make use of the browser's _back_ button to return to the curriculum.

Screenshots
GIF can be made available, if requested.

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Chrome
• Version: 80.0.3987.100

Additional context
Please note: I am aware that opening a page within a new tab causes the navigation history to reset with that tab. This error occurs within the same tab.

[raisedadead]

Please note: I am aware that opening a page within a new tab causes the navigation history to reset with that tab. This error occurs within the same tab.

Thanks for this additional detail.

[hassaanp]

I have been trying to work on this but I have not been able to reproduce this on my local setup.

It is easily reproducible on the live site though.

[ojeytonwilliams]

@hassaanp I needed to build the site before I could see it locally. To replicate the production environment you can use npm run build:client. Then copy serve.json into client and finally run npx serve -c ../serve.json client/public

It should say

INFO: Discovered configuration in `../serve.json`

   ┌─────────────────────────────────────────────────┐
   │                                                 │
   │   Serving!                                      │
   │                                                 │
   │   - Local:            http://localhost:5000     │

which means it's working.

[hassaanp]

Thanks, @ojeytonwilliams.
I was able to reproduce it locally. I am going to give a shot at fixing this. I believe this issue is similar to using the <a> tag in React (causes the entire app to rerender and lose state). I think there should be some workaround for this.

[ojeytonwilliams]

That's interesting!

It may not be relevant, and I don't want to distract you, but I noticed that gatsby serve does not have this problem, while zeit/serve (what npx serve calls) does.

[raisedadead]

I am more and more inclined on moving away from the zeit/serve and actually doing a docker based approach from the Gatsby docker image.

Thanks for all your investigations Oliver and Hassaan

[hassaanp]

@ojeytonwilliams

Thanks for the information. Should we configure npx to use gatsby instead?
I have been trying to go through the React Tree and the network tab and diff-ing it for the direct link and the new tab link. Also going through the code as well. So far, nothing promising has shown up. I wonder perhaps this has got to do with mixing client-side and server-side rendering. This may be relevant.

@raisedadead, That sounds interesting. Let me know if I can help with that.

[ojeytonwilliams]

Should we configure npx to use gatsby instead?

We don't use npx in production, it's just a convenient way to run serve locally. Also, according to their docs gatsby serve is only intended for testing a production build, so probably should not be used in practice.

[moT01]

Is this still an issue for you @Sky020? I cannot reproduce this after a quick test.

[Sky020]

@moT01 No. Seems to magically have gone away. Thanks, for checking.