GBI causing 404 null network requests

[EricSSartorius]

I realized that on pages that are using GBI in my app, there are null requests in my network tab. These return a 304 locally but in production return a 404 with an error in the console that says Failed to load resource: the server responded with a status of 404 ().

So for example if I were to have a background image at example.com/installation, I would see something that looks like the following:

This error only shows up when using GBI and disappears as soon as I comment out the code where the image is being used.

I was not able to reproduce this problem on the GBI test repo so I am wondering if I am possibly implementing things wrong?

I should also mention that visually everything is fine. GBI works as expected and the page loads fine.

(sorry to keep bugging you @timhagn )

[timhagn]

Every bug solved helps, so no problem @EricSSartorius ; ).

But right now I've no clue how this could come to pass. I should finally come around doing an issue template, as I'd at least need your gatsby-info again, as I bump all dependencies in the gbitest repo to their latest version with each release of gatsby-background-image (now @ v0.2.6 - soon the next). Edit: 0.2.61 now ^^.

[EricSSartorius]

Ah right, forgot about the info. Here it is:

  System:
    OS: macOS 10.14.3
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Shell: 2.7.1 - /usr/local/bin/fish
  Binaries:
    Node: 10.15.1 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.8.0 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 70.0.3538.102
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.1.9 => 2.1.9 
    gatsby-background-image: ^0.2.5 => 0.2.5 
    gatsby-image: ^2.0.10 => 2.0.13 
    gatsby-plugin-google-analytics: ^2.0.14 => 2.0.14 
    gatsby-plugin-google-fonts: 0.0.4 => 0.0.4 
    gatsby-plugin-layout: ^1.0.12 => 1.0.12 
    gatsby-plugin-manifest: ^2.0.18 => 2.0.18 
    gatsby-plugin-offline: ^2.0.22 => 2.0.24 
    gatsby-plugin-react-helmet: ^3.0.6 => 3.0.6 
    gatsby-plugin-robots-txt: ^1.4.0 => 1.4.0 
    gatsby-plugin-sharp: ^2.0.17 => 2.0.17 
    gatsby-plugin-sitemap: ^2.0.1 => 2.0.1 
    gatsby-plugin-styled-components: ^3.0.0 => 3.0.0 
    gatsby-source-filesystem: ^2.0.23 => 2.0.23 
    gatsby-source-shopify: ^2.0.17 => 2.0.17 
    gatsby-source-wordpress: ^3.0.35 => 3.0.36 
    gatsby-transformer-sharp: ^2.1.2 => 2.1.3 
  npmGlobalPackages:
    gatsby-cli: 2.4.15

I tried digging a bit and the 404 references the react-headroom plugin that I am also using so perhaps there is a conflict? Although I don't see how it could cause this error.

clicking the link in the console error directs me to this:

and hovering the red X says 'failed to load resource'.

I am not sure if it is an issue to bring up with react-headroom but it works fine unless GBI is also being used.

[timhagn]

Uffz, haven't worked with react-headroom myself, but measuring from their issue queue, there seem to be some problems with other packages as well... From the top of my head gatsby-background-image never touches the Heights or such of anything oO.

Cause the only times it touches the DOM in any way is when preloading images (you could put an onError callback prop on the BackgroundImage to see if it bails there), or when crawling external background-* styles...

One thing that just came to my mind (as I'm still working out why gatsby-image had it in it's package.json in the first place) is @babel/runtime as a dependency, but that's a far shot...

I'm a little flummoxed by the problem - and I guess you mightn't be able to share the projects repo if it's still the same as in #8?

[EricSSartorius]

After a bunch of digging, I finally found the problem. It actually has nothing to do with Headroom at all so I'm not sure why it came up.

I have a query that looks like:

export const query = graphql`
  query {
    myImg: file(relativePath: { eq: "images/image.jpg" }) {
      childImageSharp {
        fluid(maxWidth: 1440) {
          ...GatsbyImageSharpFluid_withWebp_noBase64
        }
      }
    }
 }
`;

on Gatsby Image this works perfectly fine but with GBI the _noBase64 is what is causing the null 404s to occur. If I change my fragment to ...GatsbyImageSharpFluid_withWebp then all of the errors go away.

Can you confirm that adding noBase64 to GBI fragments adds the error I described above? Again, visually everything works fine, the null calls only show up in the network tab. (I have been working in Chrome, not sure about other browsers)

[apaulau]

I also noticed this issue, when base64 is not available I found that on :before element background-image is set to url(null). That's the reason of failed requests.

[timhagn]

Ah, now I can relate! Thanks to the both of you @EricSSartorius & @apaulau! I can completely confirm your _noBase64 findings, they result in the same error here (FF & Chromium). I'm gonna dig into it, but feel free to open a PR I one of you is faster : ).

[timhagn]

With 0.2.7 when base64 is not available, no more null errors occur. But sadly the image is shown directly - cause although I was now tweaking at it for some hours, I couldn't get the fadeIn to work : /. With a backgroundColor set as a workaround, it sometimes(?) fades in... Hope it helps for the moment, though : )!

Edit: Ouch, however it happened, yarn publish used some old files oO. The working version is 0.2.71 Edit 2: Ouch again, forgot a console.log % |. Now at 0.2.72 ^^.

[EricSSartorius]

Thanks for getting that working! I was under the impression that _noBase64 is the option to load without a fade so I don't think that should be a problem. It is not as blocking as having 404s litter your console on every page haha

[timhagn]

lol Alas, methinks, it's meant to fade in from white / background-color. At least it looks this way in gbitest. One thing's for sure, with the work on this, gatsby-background-image is nearer on the "Original" gatsby-image, transition-wise ^^. But for the _noBase64 option gbi is one animation step short (that's why, my guess is, it sometimes works with a backgroundColor) - but I gather I have to review every animation once some gatsby-image issues thereof are under debate no more ; ). Is this one solved for the moment and might be closed?

[EricSSartorius]

Yeah I would call it solved, thanks a lot. I will have to check out the noBase64 animation and see if there is anything I can do to help with it. Thanks again for the quick responses and help!

On Sat, Mar 16, 2019, 16:44 Tim Hagn notifications@github.com wrote:

lol Alas, methinks, it's meant to fade in from white / background-color. At least it looks this way in gbitest. One thing's for sure, with the work on this, gatsby-background-image is nearer on the "Original" gatsby-image, transition-wise ^^. But for the _noBase64 option gbi is one animation step short (that's why, my guess is, it sometimes works with a backgroundColor) - but I gather I have to review every animation once some gatsby-image issues thereof are under debate no more ; ). Is this one solved for the moment and might be closed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/timhagn/gatsby-background-image/issues/13#issuecomment-473563742, or mute the thread https://github.com/notifications/unsubscribe-auth/AJoO4nynfXx6-vQuWvAJXTdsM1AIEEKfks5vXR9rgaJpZM4b0G7N .

[timhagn]

As I wrote before, no problem, every bug solved... If you wanna thank me, think of me, when you hear of an open (remote) gig ; ). But any help in solving the animation probs would be appreciated as well! Would you wanna have the honors of closing this (for the moment - there's a long way to go till v1.0 ^^), or shall I?

[EricSSartorius]

I got it =)