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.
Load basic page with an gatsby-image Img-tag on iphone.
Blur should clear when the image has been loaded
Blur stays
npm list gatsby
):gatsby --version
): [email protected]gatsby-config.js
:
package.json
:
gatsby-node.js
:
gatsby-browser.js
:
gatsby-ssr.js
:
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:
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.
Blurred image
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
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
fork
https://github.com/graysonhicks/react-scrolltop-buttongit clone
itcd react-scrolltop-button
cd
straight into docs/
npm install
gatsby develop
gatsby build && gatsby serve
public/static
folder for logo.png
npm run build:gh
runs rm -rf public
gatsby build --prefix-paths
and gh-pages -d public
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. 🤷♂️
Maybe these are useful:
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.
Most helpful comment
I'm experiencing this consistently in Safari on macOS as well as iOS. Trashing
.cache
andpublic
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.