Images failing to load in IE with DOM: 7009 error (unable to decode) in console

Question

When loading many images on a single page in IE (reproduced in IE11), some of them begin to fail to load, and have something similar to the following warning in the console:

DOM7009: Unable to decode image at URL: '[some unique url]'.

When I look at the network traffic, there does appear to valid responses received for each of these images from the server. It's not always the same images each time. If I use the dev tools to force the image to reload (example: I update the url to include some some extraneous url parameter "&test=1"), it loads/renders normally without error. I've reproduced this behavior with different types of images (jpegs/pngs; example png included below). It seems to happen more frequently as the number of images go up, and may also have some correlation with the size of each image.

Any thoughts as to what might be causing this? Potential work-arounds? Any help is appreciated.

Solution 1

It looks like the actual problem is addressed in another Stack Overflow question. All of the answers here get around the issue in various ways, but this is likely happening because the file is not the format it claims to be. Because nosniff is enabled, the browser is unable to work around this issue, and attempts to decode the wrong image type.

In other words: Your file extension does not match the actual encoding

Solution 2

I had this problem in a site hosted in IIS due the X-Content-Type-Options header being set in a parent applications web.config like this:

<system.webServer>   
 <httpProtocol>    
  <customHeaders>    
   <add name="X-Content-Type-Options" value="nosniff" />    
  </customHeaders>    
 </httpProtocol> 
</system.webServer>  

Removing it in the applications web.config fixed it:

<remove name="X-Content-Type-Options" />  

Solution 3

I had a similar problem where a file was reported in the HTTP headers as a JPEG but was in fact a PNG. Changing the filetype to match the file or removing the "X-Content-Type-Options" header fixed the problem.

Solution 4

The problem I was facing off was similar. I have a Java web application which shows pages and thumbnails of a document through Servlet requests, which responds to the browser sending PNG images. Like @user1069816 said, the responses were arriving with a header that was causing the problem "Unable to decode image":

X-Content-Type-Options: nosniff

In my case, this header were introduced by Spring Security. Besides this is a security mechanism for Internet Explorer to avoid XSS attacks, the fastest solution to disable this header on response were putting the following line on the application context file of Spring Security, headers section:

<http use-expressions="true" create-session="never" auto-config="true">
    <headers>
        <!-- this section disable put the header 'X-Content-Type-Options' -->
        <content-type-options disabled="true"/>
    </headers>

This problem were only happening on Internet Explorer 11. Not in Chrome or Firefox.

Solution 5

I've encountered this error as well — IE 11.0.9600.18059. According to my testing, it was almost certainly due to the amount of memory consumed by the tab (eg: adding extra DOM elements increases the memory usage) — not to be confused with the amount of data loaded over the network.

Using the memory profiler, I found that errors occurred once memory usage hit a ceiling around 1.5GB. This caused the following weirdness:

1. Some images would be loaded, but wouldn't render. They'd show up as an empty space in the page (with the correct dimensions), as though the image had been set to visibility: hidden.
2. Some images would be loaded, but would fail to decode. They'd show up as a small black box with an X. These images would also show a DOM7009 error in the console.
3. Flash SWFs would show up as black boxes.
4. Other random weirdness.

Different images/SWFs would be affected each time I reloaded the page.

The solution for me was to simply adjust the way the page is designed, so it's not causing IE to consume as much memory.

View more solutions

Comments

[Martin]

Had the same png/jpg mixup but instead of the headers it was the actual file ending that was wrong. Turns out Chrome allows foo.jpg to be called by using foo.png (and vice versa) and it will be displayed correctly, but IE (and possibly other browsers) doesn't allow it and hence won't find the image.

[felickz]

Wow! Someone on this thread that actually has a valid answer for how to FIX rather than INSECURE workaround! have your first upvote!

[greg]

The bottom line is: always check the actual type files you're given! Thanks!

[user958802]

Is there is any other way to achieve the same. If we disable, it will disable the security.