Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[gatsby-image] Base64 version of image isn't hidden on first page load #9264

Closed
leolabs opened this issue Oct 19, 2018 · 8 comments
Closed
Labels
status: awaiting author response Additional information has been requested from the author

Comments

@leolabs
Copy link
Contributor

leolabs commented Oct 19, 2018

Description

I'm using gatsby-image to lazy-load some png images. Normally, after the image is loaded, the small base64 version is hidden. However, this doesn't happen when I load the built site. This leads to both images being visible at the same time which looks weird.

Upon inspecting the component, I see that imgLoaded is correctly set to true, but that doesn't seem to affect the base64 version's opacity.

Please find attached a screenshot of the bug:
Imgur

I've circumvented the issue temporarily by giving the high-resolution image a colored background so the base64 version isn't visible anymore.

Steps to reproduce

You can reproduce the issue on this page (I used Chrome to test this).

This issue only occurs when the page is initially loaded. When I navigate to this page from another page, everything works as expected.

Expected result

The base64 version should not be visible after the high-resolution version finished loading.

Actual result

The base64 version is still visible.

Environment

  System:
    OS: macOS 10.14
    CPU: x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.11.0 - /usr/local/bin/node
    Yarn: 1.10.1 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Firefox: 62.0
    Safari: 12.0
  npmPackages:
    gatsby: ^2.0.0 => 2.0.28 
    gatsby-image: ^2.0.10 => 2.0.15 
    gatsby-plugin-catch-links: ^2.0.3 => 2.0.5 
    gatsby-plugin-google-fonts: ^0.0.4 => 0.0.4 
    gatsby-plugin-manifest: ^2.0.2 => 2.0.5 
    gatsby-plugin-netlify: ^2.0.0 => 2.0.1 
    gatsby-plugin-nprogress: ^2.0.5 => 2.0.5 
    gatsby-plugin-offline: ^2.0.5 => 2.0.7 
    gatsby-plugin-react-helmet: ^3.0.0 => 3.0.0 
    gatsby-plugin-sass: ^2.0.1 => 2.0.1 
    gatsby-plugin-sharp: ^2.0.5 => 2.0.7 
    gatsby-plugin-typescript: ^2.0.0 => 2.0.0 
    gatsby-plugin-typography: ^2.2.0 => 2.2.0 
    gatsby-source-filesystem: ^2.0.3 => 2.0.5 
    gatsby-transformer-json: ^2.1.4 => 2.1.4 
    gatsby-transformer-sharp: ^2.1.2 => 2.1.4 
  npmGlobalPackages:
    gatsby-cli: 2.4.1
@stefanprobst
Copy link
Contributor

Possibly related: #8323

@leolabs
Copy link
Contributor Author

leolabs commented Oct 20, 2018

After digging around in the code, I think the problem lies in the caching system. It only occurs when an image is used twice on the page. The check (index.js, L126-138) only sets IOSupported to true if the image hasn't been seen before, which might cause problems. However, I don't know if that is the root of this bug.

@leolabs
Copy link
Contributor Author

leolabs commented Oct 20, 2018

The issue could also be fixed by #7539.

@stefanprobst
Copy link
Contributor

Would you be able to test locally if #7539 fixes it for you? If you're adventurous you could also try this very unofficial drop-in replacement.

@leolabs
Copy link
Contributor Author

leolabs commented Oct 20, 2018

It's hard to merge #7539 with the current codebase as the current code base has changed in the meantime. However, I'll try out your drop-in replacement. That looks promising 👍

@kakadiadarpan kakadiadarpan added the status: awaiting author response Additional information has been requested from the author label Oct 23, 2018
@stefanprobst
Copy link
Contributor

Have you managed to solve the issue?

@leolabs
Copy link
Contributor Author

leolabs commented Nov 1, 2018

Finishing the project was a higher priority the last few days, so we used the workaround, but I'll see if I can try out your drop-in replacement tomorrow.

@m-allanson
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: awaiting author response Additional information has been requested from the author
Projects
None yet
Development

No branches or pull requests

4 participants