Processing of technologies like XBL or SVG that have their own
scripting features.

6.1.2 Enabling and disabling scripting

Scripting is enabled in a
browsing context when all of the
following conditions are true:

The user agent supports scripting.

The user has not disabled scripting for this browsing
context at this time. (User agents may provide users with
the option to disable scripting globally, or in a finer-grained
manner, e.g. on a per-origin basis.)

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 relationship with the script's browsing context

A browsing context that is assigned responsibility
for actions taken by the script.

A URL, set when the script is created, used to
resolve relative URLs. If the
base URL is set from another source, e.g. a document base
URL, then the script's base URL must follow
the source, so that if the source's changes, so does the
script's.

6.1.3.2 Calling scripts

When a user agent is to jump to a code entry-point for
a script, for example to invoke
an event listener defined in that script, the user agent must run the
following steps:

Set the entry script back to whatever it was
when this algorithm started.

This algorithm is not invoked by one script calling another.

6.1.3.3 Creating scripts

When the specification says that a script is to be created, given some script source, its scripting
language, a global object, a browsing context, a URL character
encoding, and a base URL, the user agent must run the following
steps:

Parse/compile/initialize the source of the script using the
script execution environment, as appropriate for the
scripting language, and thus obtain the list of code
entry-points for the script. If the semantics of the
scripting language and the given source code are such that there is
executable code to be immediately run, then the initial code
entry-point is the entry-point for that code.

When the user agent is to create an impotent script,
given some script source, its scripting language, and a browsing
context, the user agent must create a script, using the
given script source and scripting language, using a new empty object
as the global object, and using the given browsing context as the
browsing context. The URL character encoding and base URL for the
resulting script are not
important as no APIs are exposed to the script.

6.1.3.4 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 QUOTA_EXCEEDED_ERR exception, abort
the script without an exception, prompt the user, or throttle script
execution.

For example, the following script never terminates. A user agent
could, after waiting for a few seconds, prompt the user to either
terminate the script or let it continue.

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

6.1.4 Event loops

6.1.4.1 Definitions

To coordinate events, user interaction, scripts, rendering,
networking, and so forth, user agents must use event loops as described in this section.

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. All the tasks from one
particular task source (e.g. the callbacks generated by
timers, the events dispatched for mouse movements, the tasks queued
for the parser) 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.

A user agent is required to 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.

Stop the currently running task, allowing the event
loop to resume, but continue these steps
asynchronously.

Wait until the condition goal is
met.

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

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 some condition has been
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:

If the result of executing the script is void (there is no
return value), then the URL must be treated in a manner equivalent
to an HTTP resource with an HTTP 204 No Content response.

Otherwise, the URL must be treated in a manner equivalent to an
HTTP resource with a 200 OK response whose Content-Type metadata is
text/html and whose response body is the return value
converted to a string value.

So for example a javascript: URL for a
src attribute of an
img element would be evaluated in the context of an
empty object as soon as the attribute is set; it would then be
sniffed to determine the image type and decoded as an image.

A javascript: URL in an href attribute of an a
element would only be evaluated when the link was followed.

Event handler IDL attributes, on setting, must set the
corresponding event handler to their new value, and on
getting, must return whatever the current value of the corresponding
event handler is (possibly null).

All event handlers on an object, whether an element
or some other object, and whether set to null or to a
Function object, must be registered as event listeners
on the object when it is created, as if the addEventListener()
method on the object's EventTarget interface had been
invoked, with the event type (type
argument) equal to the type corresponding to the event handler (the
event handler event type), the listener set to be a
target and bubbling phase listener (useCapture argument set to
false), and the event listener itself (listener argument) set to do
nothing while the event handler's value is not a
Function object, and set to invoke the call() callback of the
Function object associated with the event handler
otherwise.

If the Function object is a JavaScript Function, then when it is invoked by the user agent,
the user agent must set the thisArg (as defined
by ECMAScript edition 5 section 10.4.3 Entering Function Code) to
the event handler's object. [ECMA262]

For example, the following document fragment:

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

...leads to an alert saying "[object Window]" when the document is loaded,
and an alert saying "[object HTMLBodyElement]" whenever the user
clicks something in the page.

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.

6.1.6.3 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 an 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 dispatched at
the given target.

Firing a synthetic
mouse event named e means that an 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 MouseEvent
interface, must be dispatched at the given target. The event object
must have its screenX, screenY, clientX, clientY, and button attributes
set to 0, its ctrlKey, shiftKey, altKey, and metaKey attributes set according to the current
state of the key input device, if any (false for any keys that are
not available), its detail attribute set to 1,
and its relatedTarget attribute set to 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.

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 also dispatch the event to the Window, as
follows:

In the capture phase, the event must propagate to the
Window object before propagating to any of the nodes,
as if the Window object was the parent of the
Document in the dispatch chain.

In the bubble phase, the event must propagate up to the
Window object at the end of the phase, unless bubbling
has been prevented, again as if the Window object was
the parent of the Document in the dispatch chain.

6.1.6.5 Runtime script errors

This section only applies to user agents that support
scripting in general and JavaScript in particular.

The function must be invoked with three arguments. The three
arguments passed to the function are all DOMStrings;
the first must give the message that the UA is considering
reporting, the second must give the absolute URL of
the resource in which the error occurred, and the third must give
the line number in that resource on which the error occurred.

If the function returns false, then the error is handled. Otherwise, the error is
not handled.

Any uncaught exceptions thrown or errors caused by this
function may be reported to the user immediately after the error
that the function was called for; the report an error algorithm must not be used to handle
exceptions thrown or errors caused by this function.