Javascript onerror this src

Resource loading: onload and onerror

The browser allows us to track the loading of external resources – scripts, iframes, pictures and so on.

There are two events for it:

Loading a script

Let’s say we need to load a third-party script and call a function that resides there.

We can load it dynamically, like this:

let script = document.createElement('script'); script.src = "my.js"; document.head.append(script);

…But how to run the function that is declared inside that script? We need to wait until the script loads, and only then we can call it.

For our own scripts we could use JavaScript modules here, but they are not widely adopted by third-party libraries.

script.onload

The main helper is the load event. It triggers after the script was loaded and executed.

let script = document.createElement('script'); // can load any script, from any domain script.src = "https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.3.0/lodash.js" document.head.append(script); script.onload = function() < // the script creates a variable "_" alert( _.VERSION ); // shows library version >;

So in onload we can use script variables, run functions etc.

…And what if the loading failed? For instance, there’s no such script (error 404) or the server is down (unavailable).

script.onerror

Errors that occur during the loading of the script can be tracked in an error event.

For instance, let’s request a script that doesn’t exist:

let script = document.createElement('script'); script.src = "https://example.com/404.js"; // no such script document.head.append(script); script.onerror = function() < alert("Error loading " + this.src); // Error loading https://example.com/404.js >;

Please note that we can’t get HTTP error details here. We don’t know if it was an error 404 or 500 or something else. Just that the loading failed.

Events onload / onerror track only the loading itself.

Errors that may occur during script processing and execution are out of scope for these events. That is: if a script loaded successfully, then onload triggers, even if it has programming errors in it. To track script errors, one can use window.onerror global handler.

Other resources

The load and error events also work for other resources, basically for any resource that has an external src .

let img = document.createElement('img'); img.src = "https://js.cx/clipart/train.gif"; // (*) img.onload = function() < alert(`Image loaded, size $x$`); >; img.onerror = function() < alert("Error occurred while loading image"); >;

There are some notes though:

• Most resources start loading when they are added to the document. But is an exception. It starts loading when it gets a src (*) .
• For , the iframe.onload event triggers when the iframe loading finished, both for successful load and in case of an error.

That’s for historical reasons.

Crossorigin policy

There’s a rule: scripts from one site can’t access contents of the other site. So, e.g. a script at https://facebook.com can’t read the user’s mailbox at https://gmail.com .

Or, to be more precise, one origin (domain/port/protocol triplet) can’t access the content from another one. So even if we have a subdomain, or just another port, these are different origins with no access to each other.

This rule also affects resources from other domains.

If we’re using a script from another domain, and there’s an error in it, we can’t get error details.

For example, let’s take a script error.js that consists of a single (bad) function call:

Now load it from the same site where it’s located:

We can see a good error report, like this:

Uncaught ReferenceError: noSuchFunction is not defined https://javascript.info/article/onload-onerror/crossorigin/error.js, 1:1

Now let’s load the same script from another domain:

The report is different, like this:

Details may vary depending on the browser, but the idea is the same: any information about the internals of a script, including error stack traces, is hidden. Exactly because it’s from another domain.

Why do we need error details?

There are many services (and we can build our own) that listen for global errors using window.onerror , save errors and provide an interface to access and analyze them. That’s great, as we can see real errors, triggered by our users. But if a script comes from another origin, then there’s not much information about errors in it, as we’ve just seen.

Similar cross-origin policy (CORS) is enforced for other types of resources as well.

To allow cross-origin access, the tag needs to have the crossorigin attribute, plus the remote server must provide special headers.

There are three levels of cross-origin access:

1. No crossorigin attribute – access prohibited.
2. crossorigin=»anonymous» – access allowed if the server responds with the header Access-Control-Allow-Origin with * or our origin. Browser does not send authorization information and cookies to remote server.
3. crossorigin=»use-credentials» – access allowed if the server sends back the header Access-Control-Allow-Origin with our origin and Access-Control-Allow-Credentials: true . Browser sends authorization information and cookies to remote server.

You can read more about cross-origin access in the chapter Fetch: Cross-Origin Requests. It describes the fetch method for network requests, but the policy is exactly the same.

Such thing as “cookies” is out of our current scope, but you can read about them in the chapter Cookies, document.cookie.

In our case, we didn’t have any crossorigin attribute. So the cross-origin access was prohibited. Let’s add it.

We can choose between «anonymous» (no cookies sent, one server-side header needed) and «use-credentials» (sends cookies too, two server-side headers needed).

If we don’t care about cookies, then «anonymous» is the way to go:

Now, assuming that the server provides an Access-Control-Allow-Origin header, everything’s fine. We have the full error report.

Summary

Images , external styles, scripts and other resources provide load and error events to track their loading:

The only exception is : for historical reasons it always triggers load , for any load completion, even if the page is not found.

The readystatechange event also works for resources, but is rarely used, because load/error events are simpler.

Tasks

Load images with a callback

Normally, images are loaded when they are created. So when we add to the page, the user does not see the picture immediately. The browser needs to load it first.

To show an image immediately, we can create it “in advance”, like this:

let img = document.createElement('img'); img.src = 'my.jpg';

The browser starts loading the image and remembers it in the cache. Later, when the same image appears in the document (no matter how), it shows up immediately.

Create a function preloadImages(sources, callback) that loads all images from the array sources and, when ready, runs callback .

For instance, this will show an alert after the images are loaded:

function loaded() < alert("Images loaded") >preloadImages(["1.jpg", "2.jpg", "3.jpg"], loaded);

In case of an error, the function should still assume the picture “loaded”.

In other words, the callback is executed when all images are either loaded or errored out.

The function is useful, for instance, when we plan to show a gallery with many scrollable images, and want to be sure that all images are loaded.

In the source document you can find links to test images, and also the code to check whether they are loaded or not. It should output 300 .

1. Make img for every source.
2. Add onload/onerror for every image.
3. Increase the counter when either onload or onerror triggers.
4. When the counter value equals to the sources count – we’re done: callback() .

Источник

Javascript onerror this src

Частная коллекция качественных материалов для тех, кто делает сайты

• Creativo.one2000+ уроков по фотошопу
• Фото-монстр300+ уроков для фотографов
• Видео-смайл200+ уроков по видеообработке
• Жизнь в стиле «Кайдзен» Техники и приемы для гармоничной и сбалансированной жизни

В этой рубрике Вы найдете уроки по Javascript библиотеке jQuery.

• 

Анимация набора текста на jQuery

Сегодня мы бы хотели вам рассказать о библиотеке TypeIt — бесплатном jQuery плагине. С её помощью можно имитировать набор текста. Если всё настроить правильно, то можно добиться очень реалистичного эффекта.

Временная шкала на jQuery

Заметка: Перезагрузка и редирект на JavaScript

Быстрая заметка, где вы сможете найти парочку JS сниппетов для перезагрузки и перенаправления пользователей через JavaScript.

Рисуем диаграмму Ганта

AJAX и PHP: загрузка файла

Stimed — стили в зависимости от времени суток

Интересная библиотека с помощью которой можно задать определённым элементам страницы особые стили в зависимости от времени суток.

Источник

How to set a default image when an image fails to load

Image loading in websites fail for many reasons. It could be that the src of the image contains a broken link. Or, the internet connection may be poor, and not enough to fetch the image from an external source. Or, the image’s server (which may be external) may be down.

When images don’t load, the alt text is displayed in the container with a tiny icon signifying a broken image, like so:

This view can affect UX especially when the text begins to exceed the image container.

We can display default iamges (instead of alt texts) when an image is not fetched correctly for whatever reason. And in this article, we’ll see how.

According to [MDN](How to set a default image when an image fails to load),

The error event is fired on an Element object when a resource failed to load, or can’t be used. For example, if a script has an execution error or an image can’t be found or is invalid.

When an image fails to load due to connection, broken link, or whatever reason, the onerror event is fired. And this is where we set the default image.

The idea here is, we declare a callback function such that when the error event is fired, that function with the event object as the argument will be invoked. In that callback function, we can change the src of the image to a default link that we’re sure is not broken, and also maybe exists on the same server.

Now, let’s look at the code side of things.

In Plain HTML and JS:

 img id="image" src="https://broken-link-goes-here" />

// js file const img = document.getElementById("image") img.addEventListener("error", function(event)  event.target.src = "https://default-image-link-goes-here" event.onerror = null >)

function Component()  return ( div> img src="https://broken-link-goes-here" alt="A house with two children standing in front of it" onError=event =>  event.target.src = "https://default-image-link-goes-here" event.onerror = null >> /> div> ) >

The same idea goes for other frameworks. In the callback, you reassign a different image link (which will be used as the default) to the src attribute.

One extra thing I did was add event.onerror = null . The relevance of that line is, if for any reasons the newly assigned image link is broken or the image not fetched, the onerror event will be triggered again. And if the image doesn’t load again, another trigger. And there you have an infinite loooooooop 🥵.

Assignining null to the event prevents that. If the new image link doesn’t work, the error event does not call a callback function and then the alt text will be displayed.

And that’s how to set a default image when an image fails to load.

Articles written with ❤ by
Dillion Megida

Источник