gatsby: [v2] Gatsby attempts to reload a page infinitely if the canonical path doesn't match window.location.pathname

This is mainly a problem when the hosting rewrites uppercase URLs as lowercase, and would also occur e.g. if an external link points to a page on a Gatsby site with different casing. To test locally, after running gatsby build and before gatsby serve, copy a page folder to another location (e.g. cp -r public/about public/about-test).

Analysis so far: replacing window.location.pathname with window.page.path in production-app.js (around lines 85) prevents the A page wasn't found for... warning displaying in the console, and loader.getPage(window.page.path) returns true:

(In the future I’ll also perform checks to make sure it still uses window.location.pathname if the canonical path points to the offline app shell, otherwise it would just render a blank page without no-cache=1.)

However, the RouteHandler element’s props.location still use the actual window’s location, and these props are used to determine which page to actually load. I believe they get passed to PageRenderer which then checks if the pageResources exist, and this check fails due to the actual pathname for which Gatsby doesn’t have resources. Thus we have the infinite reload, where &no-cache=1 keeps getting added to the URL: (while testing I returned null before this happens to make things easier, but normally that line wouldn’t exist so it would keep reloading)

So what we need to do is set change the RouteHandler’s props.location.pathname to match the canonical path, to allow Gatsby to find the resources. This is what I’m currently stuck on, I’ll just copy my last commend from #7355 over here

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 18 (18 by maintainers)

Most upvoted comments

All tests are passing! PR incoming

/cc @dfmarulanda @ssmith-wombatweb

Tests (now 68)

configurations:

- 1) online without gatsby-plugin-offline
- 2) online with gatsby-plugin-offline
- 3) offline with gatsby-plugin-offline
- 4) online in develop

- x.1) with a custom 404 page
- x.2) without a custom 404 page


tests:

- 1) 404s are handled correctly from internal links - custom 404 or server 404
  if custom is unavailable, or offline error, but no blank pages

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]

- 2) 404s are handled correctly when entering a URL directly - as above, and
  the URL fetched contains the original query parameters (not just no-cache=1)

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]

- 3A) back button works properly after internal link 404 (navigates to the
  expected page)

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]

- 3B) back button works properly after external link 404 (navigates to the
  expected page)

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]

- 4) pages which fail to load display a native offline error (no blank pages)

  requires: [3.1, 3.2]
  passed:   [3.1, 3.2]

- 5) the service worker remains installed after a 404/offline error

  requires: [3.1, 3.2]
  passed:   [3.1, 3.2]

- 6) Netlify CMS /admin/ loads or displays an offline error (no 404/blank page)

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]

- 7) going to a page by entering the URL directly works

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2]

- 8) clicking the "mismatching canonical URL" link works with JS, and goes
  backwards and forwards correctly (or shows offline)

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2]

- 9) directly entering the mismatching canonical URL works with JS, and goes
  backwards and forwards correctly (or shows offline)

  requires: [1.1, 1.2, 2.1, 2.2, 3.1, 3.2]
  passed:   [1.1, 1.2, 2.1, 2.2, 3.1, 3.2]

- 10) going to a page with a mismatching canonical URL always shows a 404 in
  development

  requires: [4.1, 4.2]
  passed:   [4.1, 4.2]

valin4tor on Aug 31, 2018

Nearly finished manual testing (after fixing a few problems it picked up) - all is looking good, so I should be able to create the PR soon!

valin4tor on Aug 31, 2018