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

- `onload` -- successful load,

- `onerror` -- an error occurred.

...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.

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

// the script creates a helper function "_"

alert(_); // the function is available

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 or the server is down (unavailable).

Errors that occur during the loading of the script can be tracked on `error` event.

script.src = "https://example.com/404.js"; // no such script

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 was it error 404 or 500 or something else. Just that the loading failed.

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

For example:

```js run

let img = document.createElement('img');

img.src = "https://js.cx/clipart/train.gif"; // (*)

img.onload = function() {

alert(`Image loaded, size ${img.width}x${img.height}`);

};

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 `<img>` is an exception. It starts loading when it gets an src `(*)`.

- For `<iframe>`, 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.

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, 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 with a single (bad) function call:

noSuchFunction();

Now load it from our domain:

```html run height=0

<script>

</script>

<script src="/article/onload-onerror/crossorigin/error.js"></script>

We can see a good error report, like this:

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

```html run height=0

<script>

</script>

<script src="https://cors.javascript.info/article/onload-onerror/crossorigin/error.js"></script>

The report is different, like this:

There are many services (and we can build our own) that listen to `window.onerror`, save errors at the server and provide an interface to access and analyze them. That's great, as we can see real errors, triggered by our users. But we can't see any error information for scripts from other domains.

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

**To allow cross-origin access, we need `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.

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 a way to go:

```html run height=0

<script>

</script>

<script *!*crossorigin="anonymous"*/!* src="https://cors.javascript.info/article/onload-onerror/crossorigin/error.js"></script>

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

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

- `load` triggers on a successful load,

- `error` triggers on a failed load.

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