Definitions

This specification describes three kinds of JavaScript global environments: the document environment, the dedicated worker environment, and the shared worker environment. The dedicated worker environment and the shared worker environment are both types of worker environments.

Except where otherwise specified, a JavaScript global environment is a document environment.

A script has:

A code entry-point

A code entry-point represents a block of executable code that the script exposes to other scripts and to the user agent. Typically, the code corresponding to the code entry-point is executed immediately after the script is parsed, but for event handlers, it is called each time the handler is invoked.

In JavaScript script blocks, this corresponds to the execution context of the global code.

Optionally, a muted errors flag

A flag which, if set, means that error information will not be provided for errors in this script (used to mute errors for cross-origin scripts, since that can leak private information).

A settings object

An environment settings object, various settings that are shared with other scripts in the same context.

An environment settings object specifies algorithms for obtaining the following:

A script execution environment for each language supported by the user agent

The characteristics of the script execution environment depend on the language, and are not defined by this specification.

In JavaScript, the script execution environment consists of the interpreter, the stack of execution contexts, the global code and function code and the Function objects resulting, and so forth.

A global object

An object that provides the APIs that can be called by the code in scripts that use this settings object.

This is typically a Window object or a WorkerGlobalScope object. When a global object is an empty object, it can't do anything that interacts with the environment.

If the global object is a Window object, then, in JavaScript, the ThisBinding of the global execution context for this script must be the Window object's WindowProxy object, rather than the global object. [[!ECMA262]]

This is a willful violation of the JavaScript specification current at the time of writing (ECMAScript edition 5, as defined in section 10.4.1.1 Initial Global Execution Context, step 3). The JavaScript specification requires that the this keyword in the global scope return the global object, but this is not compatible with the security design prevalent in implementations as specified herein. [[!ECMA262]]

A responsible browsing context

A browsing context that is assigned responsibility for actions taken by the scripts that use this environment settings object.

When a script creates and navigates a new top-level browsing context, the opener attribute of the new browsing context's Window object will be set to the responsible browsing context's WindowProxy object.

A responsible event loop

An event loop that is used when it would not be immediately clear what event loop to use.

A responsible document

A Document that is assigned responsibility for actions taken by the scripts that use this environment settings object.

For example, the address of the responsible document is used to set the address of the Document after it has been reset using document.open().

If the responsible event loop is not a browsing context event loop, then the environment settings object has no responsible document.

A referrer source

Either a Document (specifically, the responsible document), or a URL, which is used by some APIs to determine what value to use for the Referer (sic) header in calls to the fetching algorithm.

An API URL character encoding

A character encoding used to encode URLs by APIs called by scripts that use this environment settings object.

An API base URL

An absolute URL used by APIs called by scripts that use this environment settings object to resolve relative URLs.

An origin and an effective script origin

An instrument used in security checks.

The relevant settings object for a global object o is the environment settings object whose global object is o. (There is always a 1:1 mapping of global objects to environment settings objects.)

The relevant settings object for a script s is the settings object of s.

Script settings for browsing contexts

Whenever a new Window object is created, it must also create an environment settings object whose algorithms are defined as follows:

The script execution environments

When the environment settings object is created, for each language supported by the user agent, create an appropriate execution environment as defined by the relevant specification.

When a script execution environment is needed, return the appropriate one from those created when the environment settings object was created.

The global object

Return the Window object itself.

The responsible browsing context

Return the browsing context with which the Window object is associated.

The responsible event loop

Return the event loop that is associated with the unit of related similar-origin browsing contexts to which the Window object's browsing context belongs.

The responsible document

Return the Document with which the Window is currently associated.

The referrer source

Return the Document with which the Window is currently associated.

The API URL character encoding

Return the current character encoding of the Document with which the Window is currently associated.

The API base URL

Return the current base URL of the Document with which the Window is currently associated.

The origin

Return the origin of the Document with which the Window is currently associated.

The effective script origin

Return the effective script origin of the Document with which the Window is currently associated.

Calling scripts

Each unit of related similar-origin browsing contexts has a stack of script settings objects, which must be initially empty. When a new environment settings object is pushed onto this stack, the specified environment settings object is to be added to the stack; when the environment settings object on this stack that was most recently pushed onto it is to be popped from the stack, it must be removed. Entries on this stack can be labeled as candidate entry settings objects.

When a user agent is to jump to a code entry-point for a script s, the user agent must run the following steps:

1. Let context be the settings object of s.

2. Prepare to run a callback with context as the environment settings object. If this returns "do not run" then abort these steps.

3. Make the appropriate script execution environment specified by context execute the s's code entry-point.

4. Clean up after running a callback.

The steps to prepare to run a callback with an environment settings object o are as follows. They return either "run" or "do not run".

1. If the global object specified by o is a Window object whose Document object is not fully active, then return "do not run" and abort these steps.

2. If scripting is disabled for the responsible browsing context specified by o, then return "do not run" and abort these steps.

3. Push o onto the stack of script settings objects, and label it as a candidate entry settings object.

4. Return "run".

The steps to clean up after running a callback are as follows:

1. Pop the current incumbent settings object from the stack of script settings objects.

2. If the stack of script settings objects is now empty, run the global script clean-up jobs. (These cannot run scripts.)

3. If the stack of script settings objects is now empty, perform a microtask checkpoint. (If this runs scripts, these algorithms will be invoked reentrantly.)

These algorithms are not invoked by one script directly calling another, but they can be invoked reentrantly in an indirect manner, e.g. if a script dispatches an event which has event listeners registered.

When a JavaScript SourceElements production is to be evaluated, the settings object of the script corresponding to that SourceElements must be pushed onto the stack of script settings objects before the evaluation begins, and popped when the evaluation ends (regardless of whether it's an abrupt completion or not).

The entry settings object is the most-recently added environment settings object in the stack of script settings objects that is labeled as a candidate entry settings object. If the stack is empty, or has no entries labeled as such, then there is no entry settings object. It is used to obtain, amongst other things, the API base URL to resolve relative URLs used in scripts running in that unit of related similar-origin browsing contexts.

The incumbent settings object is the environment settings object in the stack of script settings objects that was most-recently added (i.e. the last one on the stack). If the stack is empty, then there is no incumbent settings object. It is used in some security checks.

The Web IDL specification also uses these algorithms. [[!WEBIDL]]

<!-- a/a.html -->
<!DOCTYPE HTML>
<title>Outer page</title>
<iframe src="../b/b.html"></iframe>
<input type=button onclick="frames[0].hello()" value="Hello">

<!-- b/b.html -->
<!DOCTYPE HTML>
<title>Inner page</title>
<script>
 function hello() {
   location.assign('c.html');
 }
</script>

Each unit of related similar-origin browsing contexts has a global script clean-up jobs list, which must initially be empty. A global script clean-up job cannot run scripts, and cannot be sensitive to the order in which other clean-up jobs are executed. The File API uses this to release blob: URLs. [[!FILEAPI]]

When the user agent is to run the global script clean-up jobs, the user agent must perform each of the jobs in the global script clean-up jobs list and then empty the list.

Creating scripts

When the specification says that a script is to be created, given some script source, a script source URL, its scripting language, an environment settings object, and optionally a muted errors flag, the user agent must run the following steps:

1. Let script be a new script that this algorithm will subsequently initialise.

2. If scripting is disabled for browsing context passed to this algorithm, then abort these steps, as if the script source described a program that did nothing but return void.

3. Obtain the appropriate script execution environment for the given scripting language from the environment settings object provided.

4. Parse/compile/initialise the source of the script using the script execution environment, as appropriate for the scripting language, and thus obtain script's code entry-point.

5. Let script's settings object be the environment settings object provided.

6. If the muted errors flag was set, then set script's muted errors flag.

7. If all the steps above succeeded (in particular, if the script was compiled successfully), Jump to script's code entry-point.

   Otherwise, report the error for script, with the problematic position (line number and column number), using the global object specified by the environment settings object as the target. If the error is still not handled after this, then the error may be reported to the user.

Killing scripts

User agents may impose resource limitations on scripts, for example CPU quotas, memory limits, total execution time limits, or bandwidth limitations. When a script exceeds a limit, the user agent may either throw a QuotaExceededError exception, abort the script without an exception, prompt the user, or throttle script execution.

<script>
 while (true) { /* loop */ }
</script>

User agents are encouraged to allow users to disable scripting whenever the user is prompted either by a script (e.g. using the window.alert() API) or because of a script's actions (e.g. because it has exceeded a time limit).

If scripting is disabled while a script is executing, the script should be terminated immediately.

User agents may allow users to specifically disable scripts just for the purposes of closing a browsing context.

For example, the prompt mentioned in the example above could also offer the user with a mechanism to just close the page entirely, without running any unload event handlers.

Runtime script errors

When the user agent is required to report an error for a particular script script with a particular position line:col, using a particular target target, it must run these steps, after which the error is either handled or not handled:

1. If target is in error reporting mode, then abort these steps; the error is not handled.

2. Let target be in error reporting mode.

3. Let message be a user-agent-defined string describing the error in a helpful manner.

4. Let error object be the object that represents the error: in the case of an uncaught exception, that would be the object that was thrown; in the case of a JavaScript error that would be an Error object. If there is no corresponding object, then the null value must be used instead.

5. Let location be an absolute URL that corresponds to the resource from which script was obtained.

   The resource containing the script will typically be the file from which the Document was parsed, e.g. for inline script elements or event handler content attributes; or the JavaScript file that the script was in, for external scripts. Even for dynamically-generated scripts, user agents are strongly encouraged to attempt to keep track of the original source of a script. For example, if an external script uses the document.write() API to insert an inline script element during parsing, the URL of the resource containing the script would ideally be reported as being the external script, and the line number might ideally be reported as the line with the document.write() call or where the string passed to that call was first constructed. Naturally, implementing this can be somewhat non-trivial.

   User agents are similarly encouraged to keep careful track of the original line numbers, even in the face of document.write() calls mutating the document as it is parsed, or event handler content attributes spanning multiple lines.

6. If script has muted errors, then set message to "Script error.", set location to the empty string, set line and col to 0, and set error object to null.

7. Let event be a new trusted ErrorEvent object that does not bubble but is cancelable, and which has the event name error.

8. Initialise event's message attribute to message.

9. Initialise event's filename attribute to location.

10. Initialise event's lineno attribute to line.

11. Initialise event's colno attribute to col.

12. Initialise event's error attribute to error object.

13. Dispatch event at target.

14. Let target no longer be in error reporting mode.

15. If event was canceled, then the error is handled. Otherwise, the error is not handled.

[Constructor(DOMString type, optional ErrorEventInit eventInitDict), Exposed=(Window,Worker)]
interface ErrorEvent : Event {
  readonly attribute DOMString message;
  readonly attribute DOMString filename;
  readonly attribute unsigned long lineno;
  readonly attribute unsigned long colno;
  readonly attribute any error;
};

dictionary ErrorEventInit : EventInit {
  DOMString message;
  DOMString filename;
  unsigned long lineno;
  unsigned long colno;
  any error;
};

Definitions

To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as described in this section. There are two kinds of event loops: those for browsing contexts, and those for workers.

There must be at least one browsing context event loop per user agent, and at most one per unit of related similar-origin browsing contexts.

When there is more than one event loop for a unit of related browsing contexts, complications arise when a browsing context in that group is navigated such that it switches from one unit of related similar-origin browsing contexts to another. This specification does not currently describe how to handle these complications.

A browsing context event loop always has at least one browsing context. If such an event loop's browsing contexts all go away, then the event loop goes away as well. A browsing context always has an event loop coordinating its activities.

Worker event loops are simpler: each worker has one event loop, and the worker processing model manages the event loop's lifetime.

An event loop has one or more task queues. A task queue is an ordered list of tasks, which are algorithms that are responsible for such work as:

Events

Dispatching an Event object at a particular EventTarget object is often done by a dedicated task.

Not all events are dispatched using the task queue, many are dispatched during other tasks.

Parsing

The HTML parser tokenizing one or more bytes, and then processing any resulting tokens, is typically a task.

Callbacks

Calling a callback is often done by a dedicated task.

Using a resource

When an algorithm fetches a resource, if the fetching occurs in a non-blocking fashion then the processing of the resource once some or all of the resource is available is performed by a task.

Reacting to DOM manipulation

Some elements have tasks that trigger in response to DOM manipulation, e.g. when that element is inserted into the document.

Each task in a browsing context event loop is associated with a Document; if the task was queued in the context of an element, then it is the element's node document; if the task was queued in the context of a browsing context, then it is the browsing context's active document at the time the task was queued; if the task was queued by or for a script then the document is the responsible document specified by the script's settings object.

A task is intended for a specific event loop: the event loop that is handling tasks for the task's associated Document or worker.

When a user agent is to queue a task, it must add the given task to one of the task queues of the relevant event loop.

Each task is defined as coming from a specific task source. All the tasks from one particular task source and destined to a particular event loop (e.g. the callbacks generated by timers of a Document, the events fired for mouse movements over that Document, the tasks queued for the parser of that Document) must always be added to the same task queue, but tasks from different task sources may be placed in different task queues.

For example, a user agent could have one task queue for mouse and key events (the user interaction task source), and another for everything else. The user agent could then give keyboard and mouse events preference over other tasks three quarters of the time, keeping the interface responsive but not starving other task queues, and never processing events from any one task source out of order.

Each event loop has a currently running task. Initially, this is null. It is used to handle reentrancy. Each event loop also has a performing a microtask checkpoint flag, which must initially be false. It is used to prevent reentrant invocation of the perform a microtask checkpoint algorithm.

A user agent may have one storage mutex. This mutex is used to control access to shared state like cookies. At any one point, the storage mutex is either free, or owned by a particular event loop or instance of the fetching algorithm.

If a user agent does not implement a storage mutex, it is exempt from implementing the requirements that require it to acquire or release it.

User agent implementors have to make a choice between two evils. On the one hand, not implementing the storage mutex means that there is a risk of data corruption: a site could, for instance, try to read a cookie, increment its value, then write it back out, using the new value of the cookie as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects. On the other hand, implementing the storage mutex has potentially serious performance implications: whenever a site uses Web Storage or cookies, all other sites that try to use Web Storage or cookies are blocked until the first site finishes.

So far, all browsers faced with this decision have opted to not implement the storage mutex.

Whenever a script calls into a plugin, and whenever a plugin calls into a script, the user agent must release the storage mutex.

Processing model

An event loop must continually run through the following steps for as long as it exists:

1. Select the oldest task on one of the event loop's task queues, if any, ignoring, in the case of a browsing context event loop, tasks whose associated Documents are not fully active. The user agent may pick any task queue. If there is no task to select, then jump to the microtasks step below.

2. Set the event loop's currently running task to the task selected in the previous step.

3. Run: Run the selected task.

4. Set the event loop's currently running task back to null.

5. If the storage mutex is now owned by the event loop, release it so that it is once again free.

6. Remove the task that was run in the run step above from its task queue.

7. Microtasks: Perform a microtask checkpoint.

8. Update the rendering: If this event loop is a browsing context event loop (as opposed to a worker event loop), then run the following substeps.

   1. Let now be the value that would be returned by the Performance object's now() method. [[!HRT]]

   2. Let docs be the list of Document objects associated with the event loop in question, sorted arbitrarily except that the following conditions must be met:

      • Any Document B that is nested through a Document A must be listed after A in the list.

      • If there are two documents A and B whose browsing contexts are both nested browsing contexts and their browsing context containers are both elements in the same Document C, then the order of A and B in the list must match the relative tree order of their respective browsing context containers in C.

      In the steps below that iterate over docs, each Document must be processed in the order it is found in the list.

   3. If there is a top-level browsing context B that the user agent believes would not benefit from having its rendering updated at this time, then remove from docs all Document objects whose browsing context's top-level browsing context is B.

      Whether a top-level browsing context would benefit from having its rendering updated depends on various factors, such as the update frequency. For example, if the browser is attempting to achieve a 60 Hz refresh rate, then these steps are only necessary every 60th of a second (about 16.7ms). If the browser finds that a top-level browsing context is not able to sustain this rate, it might drop to a more sustainable 30Hz for that set of Documents, rather than occasionally dropping frames. (This specification does not mandate any particular model for when to update the rendering.) Similarly, if a top-level browsing context is in the background, the user agent might decide to drop that page to a much slower 4Hz, or even less.

   4. For each fully active Document in docs, run the resize steps for that Document, passing in now as the timestamp. [[!CSSOMVIEW]]

   5. For each fully active Document in docs, run the scroll steps for that Document, passing in now as the timestamp. [[!CSSOMVIEW]]

   6. For each fully active Document in docs, evaluate media queries and report changes for that Document, passing in now as the timestamp. [[!CSSOMVIEW]]

   7. For each fully active Document in docs, run CSS animations and send events for that Document, passing in now as the timestamp. [[!CSSANIMATIONS]]

   8. For each fully active Document in docs, run the fullscreen rendering steps for that Document, passing in now as the timestamp. [[!FULLSCREEN]]

   9. For each fully active Document in docs, run the animation frame callbacks for that Document, passing in now as the timestamp.

   10. For each fully active Document in docs, update the rendering or user interface of that Document and its browsing context to reflect the current state.

9. If this is a worker event loop (i.e. one running for a WorkerGlobalScope), but there are no tasks in the event loop's task queues and the WorkerGlobalScope object's closing flag is true, then destroy the event loop, aborting these steps, resuming the run a worker steps described in the Web Workers section below.

10. Return to the first step of the event loop.

Each event loop has a microtask queue. A microtask is a task that is originally to be queued on the microtask queue rather than a task queue. There are two kinds of microtasks: solitary callback microtasks, and compound microtasks.

This specification only has solitary callback microtasks. Specifications that use compound microtasks have to take extra care to wrap callbacks to handle spinning the event loop.

When an algorithm requires a microtask to be queued, it must be appended to the relevant event loop's microtask queue; the task source of such a microtask is the microtask task source.

It is possible for a microtask to be moved to a regular task queue, if, during its initial execution, it spins the event loop. In that case, the microtask task source is the task source used. Normally, the task source of a microtask is irrelevant.

When a user agent is to perform a microtask checkpoint, if the performing a microtask checkpoint flag is false, then the user agent must run the following steps:

1. Let the performing a microtask checkpoint flag be true.

2. Microtask queue handling: If the event loop's microtask queue is empty, jump to the done step below.

3. Select the oldest microtask on the event loop's microtask queue.

4. Set the event loop's currently running task to the task selected in the previous step.

5. Run: Run the selected task.

   This might involve invoking scripted callbacks, which eventually calls the clean up after running a callback steps, which call this perform a microtask checkpoint algorithm again, which is why we use the performing a microtask checkpoint flag to avoid reentrancy.

6. Set the event loop's currently running task back to null.

7. If the storage mutex is now owned by the event loop, release it so that it is once again free.

8. Remove the microtask run in the step above from the microtask queue, and return to the microtask queue handling step.

9. Done: Let the performing a microtask checkpoint flag be false.

If, while a compound microtask is running, the user agent is required to execute a compound microtask subtask to run a series of steps, the user agent must run the following steps:

1. Let parent be the event loop's currently running task (the currently running compound microtask).

2. Let subtask be a new task that consists of running the given series of steps. The task source of such a microtask is the microtask task source. This is a compound microtask subtask.

3. Set the event loop's currently running task to subtask.

4. Run subtask.

5. Set the event loop's currently running task back to parent.

When an algorithm running in parallel is to await a stable state, the user agent must queue a microtask that runs the following steps, and must then stop executing (execution of the algorithm resumes when the microtask is run, as described in the following steps):

1. Run the algorithm's synchronous section.

2. Resumes execution of the algorithm in parallel, if appropriate, as described in the algorithm's steps.

Steps in synchronous sections are marked with ⌛.

When an algorithm says to spin the event loop until a condition goal is met, the user agent must run the following steps:

1. Let task be the event loop's currently running task.

   This might be a microtask, in which case it is a solitary callback microtask. It could also be a compound microtask subtask, or a regular task that is not a microtask. It will not be a compound microtask.

2. Let task source be task's task source.

3. Let old stack of script settings objects be a copy of the stack of script settings objects.

4. Empty the stack of script settings objects.

5. Run the global script clean-up jobs.

6. Perform a microtask checkpoint.

7. Stop task, allowing whatever algorithm that invoked it to resume, but continue these steps in parallel.

   This causes one of the following algorithms to continue: the event loop's main set of steps, the perform a microtask checkpoint algorithm, or the execute a compound microtask subtask algorithm to continue.

8. Wait until the condition goal is met.

9. Queue a task to continue running these steps, using the task source task source. Wait until this new task runs before continuing these steps.

10. Replace the stack of script settings objects with the old stack of script settings objects.

11. Return to the caller.

Some of the algorithms in this specification, for historical reasons, require the user agent to pause while running a task until a condition goal is met. This means running the following steps:

1. If necessary, update the rendering or user interface of any Document or browsing context to reflect the current state.

2. Wait until the condition goal is met. While a user agent has a paused task, the corresponding event loop must not run further tasks, and any script in the currently running task must block. User agents should remain responsive to user input while paused, however, albeit in a reduced capacity since the event loop will not be doing anything.

When a user agent is to obtain the storage mutex as part of running a task, it must run through the following steps:

1. If the storage mutex is already owned by this task's event loop, then abort these steps.

2. Otherwise, pause until the storage mutex can be taken by the event loop.

3. Take ownership of the storage mutex.

Generic task sources

The following task sources are used by a number of mostly unrelated features in this and other specifications.

The DOM manipulation task source

This task source is used for features that react to DOM manipulations, such as things that happen in a non-blocking fashion when an element is inserted into the document.

The user interaction task source

This task source is used for features that react to user interaction, for example keyboard or mouse input.

Events sent in response to user input (e.g. click events) must be fired using tasks queued with the user interaction task source. [[!DOMEVENTS]]

The networking task source

This task source is used for features that trigger in response to network activity.

The history traversal task source

This task source is used to queue calls to history.back() and similar APIs.

Event handlers

Many objects can have event handlers specified. These act as non-capture event listeners for the object on which they are specified. [[!DOM]]

An event handler has a name, which always starts with "on" and is followed by the name of the event for which it is intended.

An event handler can either have the value null, or be set to a callback object, or be set to an internal raw uncompiled handler. The EventHandler callback function type describes how this is exposed to scripts. Initially, event handlers must be set to null.

Event handlers are exposed in one of two ways.

The first way, common to all event handlers, is as an event handler IDL attribute.

The second way is as an event handler content attribute. Event handlers on HTML elements and some of the event handlers on Window objects are exposed in this way.

An event handler IDL attribute is an IDL attribute for a specific event handler. The name of the IDL attribute is the same as the name of the event handler.

Event handler IDL attributes, on setting, must set the corresponding event handler to their new value, and on getting, must return the result of getting the current value of the event handler in question (this can throw an exception, in which case the getting propagates it to the caller, it does not catch it).

If an event handler IDL attribute exposes an event handler of an object that doesn't exist, it must always return null on getting and must do nothing on setting.

This can happen in particular for event handler IDL attribute on body elements that do not have corresponding Window objects.

Certain event handler IDL attributes have additional requirements, in particular the onmessage attribute of MessagePort objects.

An event handler content attribute is a content attribute for a specific event handler. The name of the content attribute is the same as the name of the event handler.

Event handler content attributes, when specified, must contain valid JavaScript code which, when parsed, would match the FunctionBody production after automatic semicolon insertion. [[!ECMA262]]

When an event handler content attribute is set, the user agent must set the corresponding event handler to an internal raw uncompiled handler consisting of the attribute's new value and the script location where the attribute was set to this value

When an event handler content attribute is removed, the user agent must set the corresponding event handler to null.

When an event handler H of an element or object T implementing the EventTarget interface is first set to a non-null value, the user agent must append an event listener to the list of event listeners associated with T with type set to the event handler event type corresponding to H, capture set to false, and listener set to the event handler processing algorithm defined below. [[!DOM]]

The listener is emphatically not the event handler itself. Every event handler ends up registering the same listener, the algorithm defined below, which takes care of invoking the right callback, and processing the callback's return value.

This only happens the first time the event handler's value is set. Since listeners are called in the order they were registered, the order of event listeners for a particular event type will always be first the event listeners registered with addEventListener() before the first time the event handler was set to a non-null value, then the callback to which it is currently set, if any, and finally the event listeners registered with addEventListener() after the first time the event handler was set to a non-null value.

<button id="test">Start Demo</button>
<script>
 var button = document.getElementById('test');
 button.addEventListener('click', function () { alert('ONE') }, false);
 button.setAttribute('onclick', "alert('NOT CALLED')"); // event handler listener is registered here
 button.addEventListener('click', function () { alert('THREE') }, false);
 button.onclick = function () { alert('TWO'); };
 button.addEventListener('click', function () { alert('FOUR') }, false);
</script>

The interfaces implemented by the event object do not influence whether an event handler is triggered or not.

The event handler processing algorithm for an event handler H and an Event object E is as follows:

1. Let callback be the result of getting the current value of the event handler H.

2. If callback is null, then abort these steps.

3. Process the Event object E as follows:

   If E is an ErrorEvent object and the event handler IDL attribute's type is OnErrorEventHandler

   Invoke callback with five arguments, the first one having the value of E's message attribute, the second having the value of E's filename attribute, the third having the value of E's lineno attribute, the fourth having the value of E's colno attribute, the fifth having the value of E's error attribute, and with the callback this value set to E's currentTarget. Let return value be the callback's return value. [[!WEBIDL]]

   Otherwise

   Invoke callback with one argument, the value of which is the Event object E, with the callback this value set to E's currentTarget. Let return value be the callback's return value. [[!WEBIDL]]

   In this step, invoke means to invoke the Web IDL callback function.

   If an exception gets thrown by the callback, end these steps and allow the exception to propagate. (It will propagate to the DOM event dispatch logic, which will then report the exception.)

4. Process return value as follows:

   If the event type is mouseover

   If the event type is error and E is an ErrorEvent object

   If return value is a Web IDL boolean true value, then cancel the event.

   If the event type is beforeunload

   The event handler IDL attribute's type is OnBeforeUnloadEventHandler, and the return value will therefore have been coerced into either the value null or a DOMString.

   If the return value is null, then cancel the event.

   Otherwise, If the Event object E is a BeforeUnloadEvent object, and the Event object E's returnValue attribute's value is the empty string, then set the returnValue attribute's value to return value.

   Otherwise

   If return value is a Web IDL boolean false value, then cancel the event.

The EventHandler callback function type represents a callback used for event handlers. It is represented in Web IDL as follows:

[TreatNonObjectAsNull]
callback EventHandlerNonNull = any (Event event);
typedef EventHandlerNonNull? EventHandler;

In JavaScript, any Function object implements this interface.

<body onload="alert(this)" onclick="alert(this)">

The return value of the function affects whether the event is canceled or not: as described above, if the return value is false, the event is canceled (except for mouseover events, where the return value has to be true to cancel the event). With beforeunload events, the value is instead used to determine the message to show the user.

For historical reasons, the onerror handler has different arguments:

[TreatNonObjectAsNull]
callback OnErrorEventHandlerNonNull = any ((Event or DOMString) event, optional DOMString source, optional unsigned long lineno, optional unsigned long column, optional any error);
typedef OnErrorEventHandlerNonNull? OnErrorEventHandler;

Similarly, the onbeforeunload handler has a different return value:

[TreatNonObjectAsNull]
callback OnBeforeUnloadEventHandlerNonNull = DOMString? (Event event);
typedef OnBeforeUnloadEventHandlerNonNull? OnBeforeUnloadEventHandler;

An internal raw uncompiled handler is a tuple with the following information:

• An uncompiled script body
• A location where the script body originated, in case an error needs to be reported

When the user agent is to get the current value of the event handler H, it must run these steps:

1. If H's value is an internal raw uncompiled handler, run these substeps:

   1. If H is an element's event handler, then let element be the element, and document be the element's node document.

      Otherwise, H is a Window object's event handler: let element be null, and let document be the Document most recently associated with that Window object.

   2. If document is not in a browsing context, or if scripting is enabled for document's browsing context, then return null and abort the algorithm for getting the current value of the event handler.

   3. Let body be the uncompiled script body in the internal raw uncompiled handler.

   4. Let location be the location where the script body originated, as given by the internal raw uncompiled handler.

   5. If element is not null and element has a form owner, let form owner be that form owner. Otherwise, let form owner be null.

   6. Let script settings be the environment settings object created for the Window object with which document is currently associated.

   7. Obtain the script execution environment for JavaScript from script settings.

   8. If body is not parsable as FunctionBody or if parsing detects an early error, then follow these substeps:

      1. Set H's value to null.

      2. Report the error for the appropriate script and with the appropriate position (line number and column number) given by location, using the global object specified by script settings as the target. If the error is still not handled after this, then the error may be reported to the user.

      3. Jump to the step labeled end below.

      FunctionBody is defined in ECMAScript edition 5 section 13 Function Definition. Early error is defined in ECMAScript edition 5 section 16 Errors. [[!ECMA262]]

   9. If body begins with a Directive Prologue that contains a Use Strict Directive then let strict be true, otherwise let strict be false.

      The terms "Directive Prologue" and "Use Strict Directive" are defined in ECMAScript edition 5 section 14.1 Directive Prologues and the Use Strict Directive. [[!ECMA262]]

   10. Using the script execution environment obtained above, create a function object (as defined in ECMAScript edition 5 section 13.2 Creating Function Objects), with:

       Parameter list FormalParameterList

       If H is an onerror event handler of a Window object

       Let the function have five arguments, named event, source, lineno, colno, and error.

       Otherwise

       Let the function have a single argument called event.

       Function body FunctionBody

       The result of parsing body above.

       Lexical Environment Scope

       1. If H is an element's event handler, then let Scope be the result of NewObjectEnvironment(document, the global environment).

          Otherwise, H is a Window object's event handler: let Scope be the global environment.

       2. If form owner is not null, let Scope be the result of NewObjectEnvironment(form owner, Scope).

       3. If element is not null, let Scope be the result of NewObjectEnvironment(element, Scope).

       NewObjectEnvironment() is defined in ECMAScript edition 5 section 10.2.2.3 NewObjectEnvironment (O, E). [[!ECMA262]]

       Boolean flag Strict

       The value of strict.

       Let function be this new function.

   11. Let script be a new script.

   12. Let script's code entry-point be function.

   13. Let script's settings object be script settings.

   14. Set H to function.

2. End: Return H's value.

Event handlers on elements, Document objects, and Window objects

The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements, as both event handler content attributes and event handler IDL attributes; and that must be supported by all Document and Window objects, as event handler IDL attributes:

The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements other than body and frameset elements, as both event handler content attributes and event handler IDL attributes; that must be supported by all Document objects, as event handler IDL attributes; and that must be supported by all Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's Documents:

The following are the event handlers (and their corresponding event handler event types) that must be supported by Window objects, as event handler IDL attributes on the Window objects themselves, and with corresponding event handler content attributes and event handler IDL attributes exposed on all body and frameset elements that are owned by that Window object's Documents:

The following are the event handlers (and their corresponding event handler event types) that must be supported on Document objects as event handler IDL attributes:

[NoInterfaceObject]
interface GlobalEventHandlers {
  attribute EventHandler onabort;
  attribute EventHandler onautocomplete;
  attribute EventHandler onautocompleteerror;
  attribute EventHandler onblur;
  attribute EventHandler oncancel;
  attribute EventHandler oncanplay;
  attribute EventHandler oncanplaythrough;
  attribute EventHandler onchange;
  attribute EventHandler onclick;
  attribute EventHandler onclose;
  attribute EventHandler oncontextmenu;
  attribute EventHandler oncuechange;
  attribute EventHandler ondblclick;
  attribute EventHandler ondrag;
  attribute EventHandler ondragend;
  attribute EventHandler ondragenter;
  attribute EventHandler ondragexit;
  attribute EventHandler ondragleave;
  attribute EventHandler ondragover;
  attribute EventHandler ondragstart;
  attribute EventHandler ondrop;
  attribute EventHandler ondurationchange;
  attribute EventHandler onemptied;
  attribute EventHandler onended;
  attribute OnErrorEventHandler onerror;
  attribute EventHandler onfocus;
  attribute EventHandler oninput;
  attribute EventHandler oninvalid;
  attribute EventHandler onkeydown;
  attribute EventHandler onkeypress;
  attribute EventHandler onkeyup;
  attribute EventHandler onload;
  attribute EventHandler onloadeddata;
  attribute EventHandler onloadedmetadata;
  attribute EventHandler onloadstart;
  attribute EventHandler onmousedown;
  [LenientThis] attribute EventHandler onmouseenter;
  [LenientThis] attribute EventHandler onmouseleave;
  attribute EventHandler onmousemove;
  attribute EventHandler onmouseout;
  attribute EventHandler onmouseover;
  attribute EventHandler onmouseup;
  attribute EventHandler onmousewheel;
  attribute EventHandler onpause;
  attribute EventHandler onplay;
  attribute EventHandler onplaying;
  attribute EventHandler onprogress;
  attribute EventHandler onratechange;
  attribute EventHandler onreset;
  attribute EventHandler onresize;
  attribute EventHandler onscroll;
  attribute EventHandler onseeked;
  attribute EventHandler onseeking;
  attribute EventHandler onselect;
  attribute EventHandler onshow;
  attribute EventHandler onsort;
  attribute EventHandler onstalled;
  attribute EventHandler onsubmit;
  attribute EventHandler onsuspend;
  attribute EventHandler ontimeupdate;
  attribute EventHandler ontoggle;
  attribute EventHandler onvolumechange;
  attribute EventHandler onwaiting;
};

[NoInterfaceObject]
interface WindowEventHandlers {
  attribute EventHandler onafterprint;
  attribute EventHandler onbeforeprint;
  attribute OnBeforeUnloadEventHandler onbeforeunload;
  attribute EventHandler onhashchange;
  attribute EventHandler onlanguagechange;
  attribute EventHandler onmessage;
  attribute EventHandler onoffline;
  attribute EventHandler ononline;
  attribute EventHandler onpagehide;
  attribute EventHandler onpageshow;
  attribute EventHandler onpopstate;
  attribute EventHandler onstorage;
  attribute EventHandler onunload;
};

Event firing

Certain operations and methods are defined as firing events on elements. For example, the click() method on the HTMLElement interface is defined as firing a click event on the element. [[!DOMEVENTS]]

Firing a simple event named e means that a trusted event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the Event interface, must be created and dispatched at the given target.

Firing a synthetic mouse event named e means that an event with the name e, which is trusted (except where otherwise stated), does not bubble (except where otherwise stated), is not cancelable (except where otherwise stated), and which uses the MouseEvent interface, must be created and dispatched at the given target. The event object must have its screenX, screenY, clientX, clientY, and button attributes initialised to 0, its ctrlKey, shiftKey, altKey, and metaKey attributes initialised according to the current state of the key input device, if any (false for any keys that are not available), its detail attribute initialised to 1, its relatedTarget attribute initialised to null (except where otherwise stated), and its view attribute initialised to the Window object of the Document object of the given target node, if any, or else null. The getModifierState() method on the object must return values appropriately describing the state of the key input device at the time the event is created.

Firing a click event means firing a synthetic mouse event named click, which bubbles and is cancelable.

The default action of these events is to do nothing except where otherwise stated.

Events and the Window object

When an event is dispatched at a DOM node in a Document in a browsing context, if the event is not a load event, the user agent must act as if, for the purposes of event dispatching, the Window object is the parent of the Document object. [[!DOM]]