-1

Generally, the image fails to load for 2 reasons:

  1. An invalid src.
  2. A poor internet connection.

How to handle that using the onerror event?

Edit: More details:

So, to be more specific, I made a function for my markdown renderer which can render embeds using the image syntax ![caption](https://example.com).

The output will be: 

<img src="https://example.com" alt="caption" onerror="renderEmbed(this)"></img>

Since the invalid src url will be used to render embeds, a poor connection with a valid url will be a mess.

  • 1
    What do you exactly mean? I’m saying: are you looking for a fallback to show an alternate version of the image in case of poor connection, etc.? – Federico Moretti Mar 09 '20 at 11:09
  • 1
    Please be more specific and provide context for error handling. Why do you want to handle an image error? Do you want to know how to use the `error` event or respectively want to know how to bind a js function to it? – Niklas E. Mar 09 '20 at 11:09
  • So, to be more specific, I made a function for my markdown rendered which can render embeds using the image syntax `[caption](https://example.com)`. The output will be: `caption`. –  Mar 09 '20 at 11:14
  • Since the invalid src url will be used to render embeds, a poor connection with a valid url will be a mess. –  Mar 09 '20 at 11:16
  • 1
    So basically you want to distinguish an "invalid src"-error from a "poor connection"-error in the `renderEmbed`-function? Am I right? – Niklas E. Mar 09 '20 at 11:29
  • yes exactly, but a "poor connection"-error should be handled too (to reload the img). –  Mar 09 '20 at 11:32

1 Answers1

0

Apart that your question is not "How to handle the image loading error reason?", but rather "How to get the image loading error reason?", the answer to that is very unsatisfying and was already been answered in a more general way (see JavaScript img.src onerror event - get reason of error).

You could extend your code to generate onerror="renderEmbed(this, window.event)" to get the error event, but that object does not provide any information about the actual reason. You could use jQuery.ajax(...) and checks if it loads or returns something hat is not an image (content type header doesn't start with image/). But that can give you false results because to images applies another CSRF handling system (see the top answer to the linked question).

The best solution would might be to change your hole system to do a server-side check, by requesting the url to verify if it's valid and an image, and then guess that the image error on the client side is not an error because of an invalid url.

I don't know... hope I could help you anyway.

Niklas E.
  • 1,848
  • 4
  • 13
  • 25
  • I don't really use jQuery (I prefer vanilla js), and I'm trying to reduce the requests. Can I get the content type header with fetch? –  Mar 09 '20 at 13:51
  • I wouldn't do that. fetch (like ajax) has a different CORS policy than img tags. e.g.: `` will load but `fetch('https://www.w3schools.com/images/compatible_chrome.gif')` will throw an access error (`No 'Access-Control-Allow-Origin' header is present on the requested resource. net::ERR_FAILED`) because you cannot read resources from other sites because of multiple security reasons. – Niklas E. Mar 09 '20 at 14:10
  • what about the old one? xmlhttprequest –  Mar 09 '20 at 14:14
  • `window.event` is undefined by default, but not in an event context. (see [Window.event](https://developer.mozilla.org/en-US/docs/Web/API/Window/event)) You shouldn't use it (it's kind of bad code), it doesn't provide any information you need anyway. – Niklas E. Mar 09 '20 at 14:14
  • yeah now I tried this and its useless `document.body.innerHTML = 'caption` –  Mar 09 '20 at 14:16
  • Same thing with xmlhttprequest (that is ajax btw.). you cannot read data (headers, body, etc.) from other sites by default. img is an exception, because they do not provide much of information to the requestor (as we see when we look at your problem). (see [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)) – Niklas E. Mar 09 '20 at 14:19
  • 1
    I think this discussion leads us nowhere. If I where you, *I would ask the question again* with a better title and also pointing out the problems with the information provided by the ErrorEvent object and the CORS policy of the browser. May somebody has a better idea than going server-side... but I don't think so. – Niklas E. Mar 09 '20 at 14:26