Uncaught (in promise) DOMException: The source image cannot be decoded.

[gitlabisbetterthangithub]

Uncaught (in promise) DOMException: The source image cannot be decoded.
Any idea why? It works for other images.

Thank you for making this JavaScript script.
I am using the yall-2.0.1.min.js file.

[malchata]

Can you provide the image (or image set) that ran into decoding issues? Do you have an example of this in the wild, currently?

Thanks for raising this!

Also, please be aware that 2.0.1 is not a supported release yet. :) 2.0.0 is the latest official release over on the releases page.

[gitlabisbetterthangithub]

It's a jpg image. Unfortunately I can't provide the image.

I am using the 2.0.1 version because I have my own classes on some of my img elements (#18).

Generally, what would be the cause of the decoding error? Some other images give me this error as well depending on how fast I scroll (but not all the time). I should also note that the image I am using is very large and is resized to a smaller size using CSS.

[malchata]

Fixed in the 2.0.2 release.

[gitlabisbetterthangithub]

I'm reopening this issue as version 2.0.2 has not fixed this issue. I am getting the same error as before.

Upon inspecting the element, the src isn't being replaced with the image in data-src.

I downloaded version 2.0.2 from the releases page.

Uncaught (in promise) DOMException: The source image cannot be decoded. Promise.then (async) o @ yall-2.0.2.min.js:1 (anonymous) @ yall-2.0.2.min.js:1 IntersectionObserver.rootMargin @ yall-2.0.2.min.js:1

Does the src have to have a valid image? I am referencing in the src a non existing image that I haven't created yet.

If I set the src to an image that exists, it is able to load alright. I thought yall.js didn't care about what was in the src attribute?

Edit: I just realised that commenting does not reopen the issue, could you please reopen it as I believe it is still an issue?

[gitlabisbetterthangithub]

Unminified version error. Much more useful compared to the other error I gave above.

Uncaught (in promise) DOMException: The source image cannot be decoded.
Promise.then (async)
yallLoad @ yall.js:24
entries.forEach.entry @ yall.js:157
IntersectionObserver @ yall.js:148

[gitlabisbetterthangithub]

I also want to say that there is nothing wrong with the image I am using because it loads fine without yall.js. I don't really want to use another library so it would be really great if this could be fixed. 🤞😀

[malchata]

The crux of the issue appears to be this:

Does the src have to have a valid image? I am referencing in the src a non existing image that I haven't created yet.

If I set the src to an image that exists, it is able to load alright. I thought yall.js didn't care about what was in the src attribute?

If I don't set an src attribute on an image, or set that src to an image that exists, yall.js has no apparent issues. But then again, I'm not able to trigger this issue in any case, and it's not apparent to me what's going on.

I'm not saying you're not having a problem. You clearly are, and I believe you at your word. But what I'll need from you in order to continue is a concrete use case from you that reproduces the error, preferably in the form of a Codepen or other test page.

Let me know when you have that up, and I'll be happy to take a look at what's going on! 😊

[gitlabisbetterthangithub]

I tried creating a new page with yall.js and images but it works for that page.

I don't really know why it sometimes works on the website I am developing. I can't share the code for that website just yet. It may be because of the actual image that I am using or because of other code.

I might revisit this later on once the website is completed and see if yall.js works and if it doesn't, I'll share you the code at that stage.

tl;dr When the website I am working on goes live, I'll send you some code.

[malchata]

I'm sorry you're having this kind of trouble. It's starting to make me wonder if async decoding is worth the trouble. 🤕

If at any point you could share the code, let me know. I haven't received this error, but just because no one else has said anything doesn't make me think this isn't a potential problem.

I'll keep this issue open for the foreseeable future in case anyone else is having trouble. In the meantime, try this unofficial build which removes async image decoding: yall-2.0.3.min.js.zip

Best of luck!

[octoxalis]

Same exception with Yall-2.0.2.min.js and 2.1.0.min.js.
Yall-2.0.3.min.js is the only version working.

Tested with <picture> element:

    <picture>
      <source
        data-srcset="full/1-image.jpg"
        type="image/jpeg">
      <img
        class="lazy"
        src="geo/1-image.jpg"
        data-src="full/1-image.jpg"
        alt="Image # 1.">
    </picture>

[SHerms]

I ran in to this issue when using a src image that returned a 400 error. I have an onerror event that is firing when an image can not load. This was not working when the image gets hung up on the decode.
A simple catch seems to work. db24252

[malchata]

To be honest, I think I'm going to be much more likely to just drop Image.decode() from yall.js altogether rather than trying to fix the issues surrounding it. Since browsers are looking to implement lazy loading themselves, I want to move toward making this release feature complete and call it a day. My hope is that no one really needs to use a JS solution a year or two from now to solve this problem (unless it's for legacy platforms, of course).

[SHerms]

maybe allow overriding env so users can disable env.asyncDecodeSupport?

[malchata]

That's a possibility. The only issue is that I worry about the side effects of decodes on imgs within <picture> tags or those with srcsets. I try to get around some of this by checking for an srcset first, but there's other things to consider that influence how images load (e.g., sizes).

I personally believe the complexity of trying to lazy load with Image.decode warrants dropping it. I think there's too much that could go awry. If we go with your proposed solution, I would say env.asyncDecodeSupport should be opt-in. I don't think the benefits in most cases are worth an async decode, except perhaps for very large and/or animated images.

[SHerms]

Thank you for merging that in.

I think you are right about removing image decode. I saw this:
"Decoding of large images can block the main thread for hundreds of milliseconds or more, interrupting fluid animations and user interaction. Currently, there's no way for a web author to specify that they want an image to be decoded asynchronously, so there are scenarios where it is impossible to avoid UI stalls."
whatwg/html#1920

[malchata]

No worries. I think there are distinct use cases for Image.decode, and I've been able to see it at work in Chrome, which sends the decode to a background thread. It's super useful, but really hard to do when lazy loading responsive images.

Other approaches involve your env variable. Or possibly only use Image.decode on img elements when no srcset or sizes attribute is available. This would confine the async decode to the simplest of use cases—which is very typical of animated images!

[AlgirdasM]

Hello, you forgot to update distribution version.

[gitlabisbetterthangithub]

My apologies @malchata for not sending you the code where the issue was caused. It looks like you have this under control however if you really do need some source code to debug, I might be able to find the old code somewhere on my Gitlab repo.

[malchata]

No problem @octoxalis. To be honest, I think I'm going to simply remove use of Image.decode(), as it's introducing some edge cases that are difficult to track down.

My focus isn't really on this script at this time, as I have some writeups I need to finish first, but I'm aiming to get these issues addressed and do a final feature complete release (per #29) and limit future releases to bugfixes only.