Gatsby: BlurUp effect gets stuck on

Created on 10 Apr 2018  ·  29Comments  ·  Source: gatsbyjs/gatsby

Description

On some devices, iphone at least, the blurup effect does not clear after image has loaded.
This happens on the first time image is shown, if user navigates to another page and then back the blur disappears.

Steps to reproduce

Load basic page with an gatsby-image Img-tag on iphone.

Expected result

Blur should clear when the image has been loaded

Actual result

Blur stays

Environment

  • Gatsby version (npm list gatsby):
  • gatsby-cli version (gatsby --version): [email protected]
  • Node.js version: v6.10.3
  • Operating System: macOS 10.12.6

File contents (if changed):

gatsby-config.js:
package.json:
gatsby-node.js:
gatsby-browser.js:
gatsby-ssr.js:

question or discussion

Most helpful comment

I'm experiencing this consistently in Safari on macOS as well as iOS. Trashing .cache and public and re-running the build does not change the behavior for me. No errors are shown in the web console, unlike some other reports of this.

All 29 comments

Is there a way to disable the blurup effect?

You can choose a different graphql fragment without the small blurred image.

We should really fix the problem though :-)

Would you like to take a crack at fixing the problem? It looks like we're running afoul of this problem https://stackoverflow.com/questions/12354865/image-onload-event-and-browser-cache

https://stackoverflow.com/questions/39777833/image-onload-event-in-isomorphic-universal-react-register-event-after-image-is looks like it might have a solution you could try.

Sorry, I don't quite understand. You mean these fragments?
GatsbyImageSharpResolutions
GatsbyImageSharpResolutions_noBase64
GatsbyImageSharpResolutions_tracedSVG
GatsbyImageSharpResolutions_withWebp
GatsbyImageSharpResolutions_withWebp_noBase64
GatsbyImageSharpResolutions_withWebp_tracedSVG

There is no "GatsbyImageSharpResolutions_NOtracedSVG", I have tried some of these and finally "GatsbyImageSharpResolutions_noBase64" seems to not to have the blurring effect.

Maybe the problem was not traced svg, I don't know. I don't understand this plugin or gatsby that well yet.

The _noBase64 option will remove the blurUp feature.

The base64 part of the query is a very small, low quality JPG version of your image, encoded in base64 so it can be inlined into the document without sending any requests (and thus, loads instantly).

_tracedSVG is an alternative to blurUp, adding in an SVG placeholder instead of the base64 inlined image, so the non tracedSVG options are NOtracedSVG by default. You have to opt in to the tracedSVG feature.

Using GraphiQL to have a look at the individual parts (instead of using the fragments) helped me to understand it a bit better:

image

Thank you for explanation.

So I was able to fix my problem but the blur-stuck is still an issue. It is quite horrible looking with partially transparent images (the blurs peek out under the correct image) and I had problems with non-transparent images as well (the blurred image just stayed on top).

I won't close this by myself since it sounds like there is a real problem although I was able to avoid it.

Having this same issue. Mine comes with a 404 for the image that is stuck as blurred, and also disappears if navigating to another page and back.

screen shot 2018-04-14 at 12 00 45 am

Blurred image

screen shot 2018-04-14 at 12 01 11 am

Same file listed above is showing a 404 in the console.

Does anyone have a way to reliably reproduce this?

I have seen the issue when the image file in public/static is deleted. It
isn't recreated if we rebuild Gatsby.

A delete of the cache followed with a Gatsby clean resolves the issue as
the images are regenerated.

On Sat 14 Apr, 2018, 10:19 AM Kyle Mathews, notifications@github.com
wrote:

Does anyone have a way to reliably reproduce this?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gatsbyjs/gatsby/issues/4926#issuecomment-381303335,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADT8tV2qAsLCO9TQBZV1Jk7lVdT12H08ks5toX_2gaJpZM4TO8QG
.

Hm, I see the 404'd image in my Github repo, and in my file system. Definitely there. Thinking it is something to do with this:

https://stackoverflow.com/questions/12354865/image-onload-event-and-browser-cache

https://stackoverflow.com/questions/39777833/image-onload-event-in-isomorphic-universal-react-register-event-after-image-is

But not sure why it would happen on some projects and not others.

Okay, so cleared public and rebuilt, still an issue 🤷‍♂️ . Here's the repo where its happening, with my best testing instructions if anyone wants to try and reproduce:

https://github.com/graysonhicks/react-scrolltop-button

Set Up

  1. fork https://github.com/graysonhicks/react-scrolltop-button
  2. git clone it
  3. cd react-scrolltop-button
  4. Top level of repo is for the npm package so can cd straight into docs/
  5. npm install

Start Gatsby

  1. gatsby develop
  2. Check on local to make sure it works.

Build and Serve Locally (works, image blurs in)

  1. run gatsby build && gatsby serve
  2. Check public/static folder for logo.png
  3. Check on the local production build to make sure it works

Build and Test on gh-pages (doesn't work, image stuck on blur)

  1. npm run build:gh runs rm -rf public gatsby build --prefix-paths and gh-pages -d public
  2. Check gh-pages of your forked repo.
  3. See if image is stuck on blur and/or if it exists in the public/static folder.

So... why are are you deleting the public folder?

I only did that based on what @Jaikant said above. I then immediately rebuilt. The public/static folder was empty before and after.

Edit: Oh, maybe you mean because it's not in the repo (master)? It is in the .gitignore of the start I used.

The problem it seems is that we use the public folder as a cache for built static files and people don't know that and then delete it and then they're left with an inconsistent cache.

I can see us not storing image thumbnails, etc. that we generate there and copying them over on builds but we'd need to figure an efficient way to do that. Ideally rsync if that were possible — https://twitter.com/kylemathews/status/985244819864760320

Anyways, you should never routinely delete the public folder (nor do you need to check it in). Gatsby takes care of deleting any files that need removed in between builds. If you do need to delete it for some reason, also delete .cache.

I think the best solution is to a) figure out a fast copy solution so we can store image thumbnails, etc. in .cache so people don't mess up their site by deleting public.

Understood. But note that touching public was trying to fix the original missing/stuck blur image. I've done the testing process I put above on a separate machine and got the same bug. Still curious how to fix that.

Welp! Deleting .cache and public and rebuilding seems to have fixed it. 🤷‍♂️

I just began toying around with Gatsby a day ago and at some point I noticed images were not working in the deployed version of the project - the blur image would remain stuck. I hadn't touched the public or .cache folder at all. Got the images working by deleting both and rebuilding and redeploying.

@arggh Same situation here. I don't think it's an ideal fix, but works for now until the cause is narrowed down.

Did you manage to fix that issue? The problem still persists.

RE: It happens on Chrome on iOS. The first time works fine and every time after that the blur stays there.

Any progress on this? The issue still exists on iOS/Safari. Had to use GatsbyImageSharpSizes_noBase64

Clearing Gatsby cache or browser cache worked when I did have this issue, but I have not had this issue in a quite a while.

I'm experiencing this consistently in Safari on macOS as well as iOS. Trashing .cache and public and re-running the build does not change the behavior for me. No errors are shown in the web console, unlike some other reports of this.

Why issue is closed? The problem is still actual.

@kodemi Looks like my fault! I mentioned the issue in a totally separate private repo pull request and Github mistakenly took it as a fix. 😳

For me, the IntersectionObserver polyfill is fixing this. More on this: https://github.com/gatsbyjs/gatsby/issues/8323

--edit--
I think there are two different problem in this issue. One is not loading image at all and the second one is when Safari doesn't hide placeholder. The second one is the one I (and I think @coreyward) experienced - and this one can be fixed by using polyfill.

This should be fixed in [email protected], see #7539 for details! I'm going to close this, please re-open or create a new issue if it's not fixed for you.

TracedSVG effect still gets stuck in Chrome/Safari in iOS, if using WEBP format.
Example query in simple Gatsby page:

        fluid (
          traceSVG: {
            color: "#333",
          }
          quality: 85
          toFormat: WEBP
        ) {
          ...GatsbyImageSharpFluid_tracedSVG
        }

Anyone can help with this issue?

@goodok21 Safari and Chrome for iOS do not have support for WebP images. Since you're forcing the format there's nothing to blur-up to. The fragment GatsbyImageSharpFluid_withWebp_tracedSVG will do what you're looking for while providing the default image format as a fallback for browsers that don't yet support WebP.

This as closed but - I upgraded from gatsby-images 2.0.23 => 2.2.14, and all of my images with loading="eager" set on them got stuck on BlurUp. Removing loading="eager" fixed the issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

benstr picture benstr  ·  3Comments

brandonmp picture brandonmp  ·  3Comments

kalinchernev picture kalinchernev  ·  3Comments

andykais picture andykais  ·  3Comments

ferMartz picture ferMartz  ·  3Comments