search

aFarkas / lazysizes

High performance and SEO friendly lazy loader for images (responsive and normal), iframes and more, that detects any visibility changes triggered through user interaction, CSS or JavaScript without configuration.
MIT License
17.52k stars 1.73k forks source link

Mozilla Firefox and Microsoft Edge image caching bug #748

Open zhrance opened 4 years ago

zhrance commented 4 years ago

Describe the bug ls-is-cached will not be set on a image

To Reproduce See your own demo: https://afarkas.github.io/lazysizes/

What is the expected behavior Adding the ls-is-cached class and making the browser cache the image

In what environment (browser/device etc.) does this bug happen/not happen: Mozilla Firefox and Microsoft Edge image caching bug

aaronstezycki commented 4 years ago

I can also confirm @zhrance issue with ls-is-cached class is also not working. Im currently testing in chrome, with a simple pattern...

<img class="img lazyload" data-src="SRC.jpg" />

And this pattern inconsistently applies the cached class. Sometimes it works, mostly it does not.

aaronstezycki commented 4 years ago

@aFarkas @zhrance A little more testing, reveals that the class does not get added to the IMG element when the element loads in view of the browser.

If the img element has not loaded, and you scroll down to the element, it adds `lazyloaded' and 'ls-is-cached' consistently. But not when the img is in view upon refresh. Its quite tricky to debug, but its definitely an inconsistent behaviour.

aaronstezycki commented 3 years ago

Bumped!

@aFarkas Can you look into this at all?

aFarkas commented 3 years ago

To be honest not really. Currently my macbook is broken and I currently wait and wait to get it fixed or a new one. About this issue itself it was a big mistake to add a) add this into core and b) name it like this.

The class is simply added if an image is loaded during one rAF cycle. You would expect that all browsers are able to deliver that fast. Probably during the onload phase FF is doing so much that it can not handle it as fast but later it can.

The original reason for this "feature" was that someone wanted to apply CSS transitions on loading images but not if someone uses back button or similar things here also the BFCache comes into play. It worked and I was ok with it.

For me I can look into it but I don't plan to write a lot of code to fix it. There is a reason why this was never documented.... What is your use case for this?

aFarkas commented 3 years ago

@aaronstezycki

I hope from my explanation above it is clear, that everything is fine with the browser caching. The only problem is that class is called like this.

What is your use case for this (meaning the class)?

aaronstezycki commented 3 years ago

I suppose it's just a feature that I had possibly intended to bind onto and initially seemed like a super helpful addition to tell the DOM and CSS that a particular image had been loaded from the cache. I do intend to use one of LQIP techniques to fade in images on load/view, so thats a better road to go down.

Initially I only wanted to highlight that the class did not work as expected, as I was showcasing it to the rest of the team, and someone asked why the class application was not consistent. I would not be opposed to removing this, as you could use something like this instead ... https://www.darrenlester.com/blog/instantly-loading-cached-images