Images don't appear the first time the user loads a page on gatsbyjs.org

[calcsam]

Description

Images don't appear the first time a site is loaded on gatsbyjs.org.

Seems like an offline-plugin issue -- perhaps @davidbailey00 could take a look?

Steps to reproduce

Visit a post you haven't visited before, that has images, such as https://www.gatsbyjs.org/blog/2018-10-04-journey-to-the-content-mesh/, that has images.

Expected result

Actual result

Environment

iPhone XS, Chrome
2015 Macbook Pro, Chrome incognito

[KyleAMathews]

It happens in an incognito window so it's not an offline problem.

[gpetrioli]

Additional info:

The problem manifests in https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-remark-images/src/index.js#L181-L183.
When the image is not cached this somehow breaks and renders as

  style="...;background-image: url('data:image/png;background-size:cover;display:block;}"

So inside the background-image the url is abruptly/wrongfully ended and it results in wrong css where the background-size and display:block are not getting applied causing the container to have 0 dimensions and thus the nested image does not appear.

So the actual problem seems to be with what gets returned by fluidResult.base64 which is the result of fluid from gatsby-plugin-sharp plugin.

[pieh]

This is more nuanced - building locally or on netlify we don't get this issue - it only show up when we build on our custom build runner

[gpetrioli]

More info: This is the same as [gatsby-remark-images] new images 404 or end up being 0x0 pixels and is explained in detail in Rewrite parseStyle parser to correctly transform parenthesis and quotes.

Locally (the developer build) works correctly but the live site (gatsbyjs.org) still has the problem.

Not sure if the live version is built with the latest versions, or if a different version of the hast-to-hyperscript is used.

A quick fix/hack (temporary as it only works around the actual problem) would be to move the background-position: ... as the last property in the code so that when it breaks it will not affect the following properties (namely display:block and background-size:cover)

[pieh]

That's interesting and really looks like the same issue, but www uses rehype-react@^3.0.3 which should contain hast-to-hyperscript version with the fix ( rehypejs/rehype-react@106ffb5 ). Maybe there is more going on there and there is some dependency weirdness happening that make build runner use older version?

[gpetrioli]

Not very well versed in build systems and yarn, but i see in the root yarn.lock https://github.com/gatsbyjs/gatsby/blob/master/yarn.lock#L9238-L9249) that it references 3.1.0 version of hast-to-hyperscript.
Could that be an issue ?

[pieh]

@gpetrioli Yeah, seems like transitive dependency of gatsby-transformer-remark there, so my bad here - let's hope #9219 will fix it

[pieh]

It seems like it was fixed with this upgrade. Thanks @gpetrioli for providing context for that! I owe you!

I'm still baffled why it wasn't manifesting locally for me

[danielhusar]

Im having the same issue, has the fix been released?

[calcsam]

Yep! Closing.