W3C

HTML 5

A vocabulary and associated APIs for HTML and XHTML

← 4.11 Interactive elementsTable of contents5.8 Offline Web applications →

5 Web browsers

This section describes features that apply most directly to Web browsers. Having said that, unless specified elsewhere, the requirements defined in this section do apply to all user agents, whether they are Web browsers or not.

5.1 Browsing contexts

A browsing context is an environment in which Document objects are presented to the user. At any time, one Document is designated the active document. The collection of Documents is the browsing context's session history.

Each browsing context has a corresponding WindowProxy object.

Each Document has a collection of one or more views.

A view is a user agent interface tied to a particular media used for the presentation of a particular Document object in some media. A view may be interactive. Each view is represented by an AbstractView object. [DOM2VIEWS]

The main view through which a user primarily interacts with a user agent is the default view. The AbstractView object that represents this view must also implement the Window interface, and is referred to as the Document's Window object.

The default view of a Document is given by the defaultView attribute on the Document object's DocumentView interface. [DOM3VIEWS]

The document attribute of an AbstractView object representing a view gives the view's corresponding Document object. [DOM2VIEWS]

Events that use the UIEvent interface are related to a specific view (the view in which the event happened); the AbstractView of that view is given in the event object's view attribute. [DOM3EVENTS]

A typical Web browser has one obvious view per Document: the browser's window (screen media). This is typically the default view. If a page is printed, however, a second view becomes evident, that of the print media. The two views always share the same underlying Document object, but they have a different presentation of that object. A speech browser might have a different default view, using the speech media.

A Document does not necessarily have a browsing context associated with it. In particular, data mining tools are likely to never instantiate browsing contexts.


A browsing context can have a creator browsing context, the browsing context that was responsible for its creation. Unless otherwise specified, a browsing context has no creator browsing context.

If a browsing context A has a creator browsing context, then the Document that was the active document of that creator browsing context at the time A was created is the creator Document.

When a browsing context is first created, it must be created with a single Document in its session history, whose address is about:blank, which is marked as being an HTML document, and whose character encoding is UTF-8. The Document must have a single child html node, which itself has a single child body node. If the browsing context is created specifically to be immediately navigated, then that initial navigation will have replacement enabled.

The origin of the about:blank Document is set when the Document is created. If the new browsing context has a creator browsing context, then the origin of the about:blank Document is the origin of the creator Document. Otherwise, the origin of the about:blank Document is a globally unique identifier assigned when the new browsing context is created.

5.1.1 Nested browsing contexts

Certain elements (for example, iframe elements) can instantiate further browsing contexts. These are called nested browsing contexts. If a browsing context P has an element E in one of its Documents D that nests another browsing context C inside it, then P is said to be the parent browsing context of C, C is said to be a child browsing context of P, C is said to be nested through D, and E is said to be the browsing context container of C.

A browsing context A is said to be an ancestor of a browsing context B if there exists a browsing context A' that is a child browsing context of A and that is itself an ancestor of B, or if there is a browsing context P that is a child browsing context of A and that is the parent browsing context of B.

The browsing context with no parent browsing context is the top-level browsing context of all the browsing contexts nested within it (either directly or indirectly through other nested browsing contexts).

The transitive closure of parent browsing contexts for a nested browsing context gives the list of ancestor browsing contexts.

A Document is said to be fully active when it is the active document of its browsing context, and either its browsing context is a top-level browsing context, or the Document through which that browsing context is nested is itself fully active.

Because they are nested through an element, child browsing contexts are always tied to a specific Document in their parent browsing context. User agents must not allow the user to interact with child browsing contexts of elements that are in Documents that are not themselves fully active.

A nested browsing context can have a seamless browsing context flag set, if it is embedded through an iframe element with a seamless attribute.

The top DOM attribute on the Window object of a Document in a browsing context b must return the WindowProxy object of its top-level browsing context (which would be its own WindowProxy object if it was a top-level browsing context itself).

The parent DOM attribute on the Window object of a Document in a browsing context b must return the WindowProxy object of the parent browsing context, if there is one (i.e. if b is a child browsing context), or the WindowProxy object of the browsing context b itself, otherwise (i.e. if it is a top-level browsing context).

The frameElement DOM attribute on the Window object of a Document d, on getting, must run the following algorithm:

  1. If d is not a Document in a child browsing context, return null and abort these steps.

  2. If the parent browsing context's active document does not have the same effective script origin as the script that is accessing the frameElement attribute, then throw a SECURITY_ERR exception.

  3. Otherwise, return the browsing context container for b.

5.1.2 Auxiliary browsing contexts

It is possible to create new browsing contexts that are related to a top level browsing context without being nested through an element. Such browsing contexts are called auxiliary browsing contexts. Auxiliary browsing contexts are always top-level browsing contexts.

An auxiliary browsing context has an opener browsing context, which is the browsing context from which the auxiliary browsing context was created, and it has a furthest ancestor browsing context, which is the top-level browsing context of the opener browsing context when the auxiliary browsing context was created.

The opener DOM attribute on the Window object must return the WindowProxy object of the browsing context from which the current browsing context was created (its opener browsing context), if there is one and it is still available.

5.1.3 Secondary browsing contexts

User agents may support secondary browsing contexts, which are browsing contexts that form part of the user agent's interface, apart from the main content area.

5.1.4 Security

A browsing context A is allowed to navigate a second browsing context B if one of the following conditions is true:

5.1.5 Groupings of browsing contexts

Each browsing context is defined as having a list of zero or more directly reachable browsing contexts. These are:

The transitive closure of all the browsing contexts that are directly reachable browsing contexts forms a unit of related browsing contexts.

Each unit of related browsing contexts is then further divided into the smallest number of groups such that every member of each group has an effective script origin that, through appropriate manipulation of the document.domain attribute, could be made to be the same as other members of the group, but could not be made the same as members of any other group. Each such group is a unit of related similar-origin browsing contexts.

Each unit of related similar-origin browsing contexts can have a first script which is used to obtain, amongst other things, the script's base URL to resolve relative URLs used in scripts running in that unit of related similar-origin browsing contexts. Initially there is no first script.

5.1.6 Browsing context names

Browsing contexts can have a browsing context name. By default, a browsing context has no name (its name is not set).

A valid browsing context name is any string with at least one character that does not start with a U+005F LOW LINE character. (Names starting with an underscore are reserved for special keywords.)

A valid browsing context name or keyword is any string that is either a valid browsing context name or that is an ASCII case-insensitive match for one of: _blank, _self, _parent, or _top.

The rules for choosing a browsing context given a browsing context name are as follows. The rules assume that they are being applied in the context of a browsing context.

  1. If the given browsing context name is the empty string or _self, then the chosen browsing context must be the current one.

  2. If the given browsing context name is _parent, then the chosen browsing context must be the parent browsing context of the current one, unless there isn't one, in which case the chosen browsing context must be the current browsing context.

  3. If the given browsing context name is _top, then the chosen browsing context must be the most top-level browsing context of the current one.

  4. If the given browsing context name is not _blank and there exists a browsing context whose name is the same as the given browsing context name, and the current browsing context is allowed to navigate that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related.

  5. Otherwise, a new browsing context is being requested, and what happens depends on the user agent's configuration and/or abilities:

    If the current browsing context has the sandboxed navigation browsing context flag set.
    The user agent may offer to create a new top-level browsing context or reuse an existing top-level browsing context. If the user picks one of those options, then the designated browsing context must be the chosen one (the browsing context's name isn't set to the given browsing context name). Otherwise (if the user agent doesn't offer the option to the user, or if the user declines to allow a browsing context to be used) there must not be a chosen browsing context.
    If the user agent has been configured such that in this instance it will create a new browsing context, and the browsing context is being requested as part of following a hyperlink whose link types include the noreferrer keyword
    A new top-level browsing context must be created. If the given browsing context name is not _blank, then the new top-level browsing context's name must be the given browsing context name (otherwise, it has no name). The chosen browsing context must be this new browsing context. If it is immediately navigated, then the navigation will be done with replacement enabled.
    If the user agent has been configured such that in this instance it will create a new browsing context, and the noreferrer keyword doesn't apply
    A new auxiliary browsing context must be created, with the opener browsing context being the current one. If the given browsing context name is not _blank, then the new auxiliary browsing context's name must be the given browsing context name (otherwise, it has no name). The chosen browsing context must be this new browsing context. If it is immediately navigated, then the navigation will be done with replacement enabled.
    If the user agent has been configured such that in this instance it will reuse the current browsing context
    The chosen browsing context is the current browsing context.
    If the user agent has been configured such that in this instance it will not find a browsing context
    There must not be a chosen browsing context.

    User agent implementors are encouraged to provide a way for users to configure the user agent to always reuse the current browsing context.

5.2 The WindowProxy object

As mentioned earlier, each browsing context has a WindowProxy object. This object is unusual in that it must proxy all operations to the Window object of the browsing context's active document. It is thus indistinguishable from that Window object in every way, except that it is not equal to it.

5.3 The Window object

[IndexGetter, NameGetter=OverrideBuiltins]
interface Window {
  // the current browsing context
  readonly attribute WindowProxy window;
  readonly attribute WindowProxy self;
           attribute DOMString name;
  [PutForwards=href] readonly attribute Location location;
  readonly attribute History history;
  readonly attribute UndoManager undoManager;
  Selection getSelection();
  [Replaceable] readonly attribute BarProp locationbar;
  [Replaceable] readonly attribute BarProp menubar;
  [Replaceable] readonly attribute BarProp personalbar;
  [Replaceable] readonly attribute BarProp scrollbars;
  [Replaceable] readonly attribute BarProp statusbar;
  [Replaceable] readonly attribute BarProp toolbar;
  void close();
  void focus();
  void blur();

  // other browsing contexts
  readonly attribute WindowProxy frames;
  readonly attribute unsigned long length;
  readonly attribute WindowProxy top;
  [Replaceable] readonly attribute WindowProxy opener;
  readonly attribute WindowProxy parent;
  readonly attribute Element frameElement;
  WindowProxy open([Optional] in DOMString url, [Optional] in DOMString target, [Optional] in DOMString features, [Optional] in DOMString replace);

  // the user agent
  readonly attribute Navigator navigator; 
  readonly attribute Storage localStorage;
  readonly attribute Storage sessionStorage;
  Database openDatabase(in DOMString name, in DOMString version, in DOMString displayName, in unsigned long estimatedSize);
  readonly attribute ApplicationCache applicationCache;

  // user prompts
  void alert(in DOMString message);
  boolean confirm(in DOMString message);
  DOMString prompt(in DOMString message, [Optional] in DOMString default);
  void print();
  any showModalDialog(in DOMString url, [Optional] in any argument);

  // cross-document messaging
  void postMessage(in any message, in DOMString targetOrigin);
  void postMessage(in any message, in MessagePort messagePort, in DOMString targetOrigin);

  // event handler DOM attributes
           attribute Function onabort;
           attribute Function onbeforeunload;
           attribute Function onblur;
           attribute Function onchange;
           attribute Function onclick;
           attribute Function oncontextmenu;
           attribute Function ondblclick;
           attribute Function ondrag;
           attribute Function ondragend;
           attribute Function ondragenter;
           attribute Function ondragleave;
           attribute Function ondragover;
           attribute Function ondragstart;
           attribute Function ondrop;
           attribute any      onerror;
           attribute Function onfocus;
           attribute Function onhashchange;
           attribute Function onkeydown;
           attribute Function onkeypress;
           attribute Function onkeyup;
           attribute Function onload;
           attribute Function onmessage;
           attribute Function onmousedown;
           attribute Function onmousemove;
           attribute Function onmouseout;
           attribute Function onmouseover;
           attribute Function onmouseup;
           attribute Function onmousewheel;
           attribute Function ononline;
           attribute Function onoffline;
           attribute Function onpopstate;
           attribute Function onresize;
           attribute Function onscroll;
           attribute Function onselect;
           attribute Function onstorage;
           attribute Function onsubmit;
           attribute Function onunload;
};

The Window object must also implement the EventTarget interface.

The window, frames, and self DOM attributes must all return the Window object's browsing context's WindowProxy object.

5.3.1 Security

User agents must raise a SECURITY_ERR exception whenever any of the members of a Window object are accessed by scripts whose effective script origin is not the same as the Window object's Document's effective script origin, with the following exceptions:

User agents must not allow scripts to override the location object's setter.

5.3.2 APIs for creating and navigating browsing contexts by name

The open() method on Window objects provides a mechanism for navigating an existing browsing context or opening and navigating an auxiliary browsing context.

The method has four arguments, though they are all optional.

The first argument, url, must be a valid URL for a page to load in the browsing context. If no arguments are provided, or if the first argument is the empty string, then the url argument defaults to "about:blank". The argument must be resolved to an absolute URL (or an error), relative to the first script's base URL, when the method is invoked.

The second argument, target, specifies the name of the browsing context that is to be navigated. It must be a valid browsing context name or keyword. If fewer than two arguments are provided, then the name argument defaults to the value "_blank".

The third argument, features, has no effect and is supported for historical reasons only.

The fourth argument, replace, specifies whether or not the new page will replace the page currently loaded in the browsing context, when target identifies an existing browsing context (as opposed to leaving the current page in the browsing context's session history). When three or fewer arguments are provided, replace defaults to false.

When the method is invoked, the user agent must first select a browsing context to navigate by applying the rules for choosing a browsing context given a browsing context name using the target argument as the name and the browsing context of the script as the context in which the algorithm is executed, unless the user has indicated a preference, in which case the browsing context to navigate may instead be the one indicated by the user.

For example, suppose there is a user agent that supports control-clicking a link to open it in a new tab. If a user clicks in that user agent on an element whose onclick handler uses the window.open() API to open a page in an iframe, but, while doing so, holds the control key down, the user agent could override the selection of the target browsing context to instead target a new tab.

Then, the user agent must navigate the selected browsing context to the absolute URL (or error) obtained from resolving url earlier. If the replace is true, then replacement must be enabled; otherwise, it must not be enabled unless the browsing context was just created as part of the the rules for choosing a browsing context given a browsing context name. The navigation must be done with the browsing context of the script that invoked the method as the source browsing context.

The method must return the WindowProxy object of the browsing context that was navigated, or null if no browsing context was navigated.


The name attribute of the Window object must, on getting, return the current name of the browsing context, and, on setting, set the name of the browsing context to the new value.

The name gets reset when the browsing context is navigated to another domain.


The close() method on Window objects should, if the corresponding browsing context A is an auxiliary browsing context that was created by a script (as opposed to by an action of the user), and if the browsing context of the script that invokes the method is allowed to navigate the browsing context A, close the browsing context A (and may discard it too).

5.3.3 Accessing other browsing contexts

The length DOM attribute on the Window interface must return the number of child browsing contexts of the Document.

The indices of the supported indexed properties on the Window object at any instant are the numbers in the range 0 .. n-1, where n is the number of child browsing contexts of the Document. If n is zero then there are no supported indexed properties.

When a Window object is indexed to retrieve an indexed property index, the value returned must be the indexth child browsing context of the Document, sorted in the tree order of the elements nesting those browsing contexts.

These properties are the dynamic nested browsing context properties.

5.3.4 Garbage collection and browsing contexts

A browsing context has a strong reference to each of its Documents and its WindowProxt object, and the user agent itself has a strong reference to its top-level browsing contexts.

A Document has a strong reference to each of its views and their AbstractView objects.

When a browsing context is to discard a Document, that means that it is to lose the strong reference from the Document's browsing context to the Document.

The browsing context's default view's Window object has a strong reference of its own to its Document object.

When a browsing context is discarded, the strong reference from the user agent itself to the browsing context must be severed, and all the Document objects for all the entries in the browsing context's session history must be discarded as well.

User agents may discard top-level browsing contexts at any time (typically, in response to user requests, e.g. when a user closes a window containing one or more top-level browsing contexts). Other browsing contexts must be discarded once their WindowProxy object is eligible for garbage collection.

5.3.5 Named access on the Window object

The Window interface supports named properties. The names of the supported named properties at any moment consist of:

When the Window object is indexed for property retrieval using a name name, then the user agent must return the value obtained using the following steps:

  1. Let elements be the list of named elements with the name name in the active document.

    There will be at least one such element, by definition.

  2. If elements contains an iframe element, then return the WindowProxy object of the nested browsing context represented by the first such iframe element in tree order, and abort these steps.

  3. Otherwise, if elements has only one element, return that element and abort these steps.

  4. Otherwise return an HTMLCollection rooted at the Document node, whose filter matches only named elements with the name name.

Named elements with the name name, for the purposes of the above algorithm, are those that are either:

5.3.6 Browser interface elements

To allow Web pages to integrate with Web browsers, certain Web browser interface elements are exposed in a limited way to scripts in Web pages.

Each interface element is represented by a BarProp object:

interface BarProp {
           attribute boolean visible;
};

The visible attribute, on getting, must return either true or a value determined by the user agent to most accurately represent the visibility state of the user interface element that the object represents, as described below. On setting, the new value must be discarded.

The following BarProp objects exist for each Document object in a browsing context. Some of the user interface elements represented by these objects might have no equivalent in some user agents; for those user agents, unless otherwise specified, the object must act as if it was present and visible (i.e. its visible attribute must return true).

The location bar BarProp object
Represents the user interface element that contains a control that displays the URL of the active document, or some similar interface concept.
The menu bar BarProp object
Represents the user interface element that contains a list of commands in menu form, or some similar interface concept.
The personal bar BarProp object
Represents the user interface element that contains links to the user's favorite pages, or some similar interface concept.
The scrollbar BarProp object
Represents the user interface element that contains a scrolling mechanism, or some similar interface concept.
The status bar BarProp object
Represents a user interface element found immediately below or after the document, as appropriate for the default view's media. If the user agent has no such user interface element, then the object may act as if the corresponding user interface element was absent (i.e. its visible attribute may return false).
The tool bar BarProp object
Represents the user interface element found immediately above or before the document, as appropriate for the default view's media. If the user agent has no such user interface element, then the object may act as if the corresponding user interface element was absent (i.e. its visible attribute may return false).

The locationbar attribute must return the location bar BarProp object.

The menubar attribute must return the menu bar BarProp object.

The personalbar attribute must return the personal bar BarProp object.

The scrollbars attribute must return the scrollbar BarProp object.

The statusbar attribute must return the status bar BarProp object.

The toolbar attribute must return the tool bar BarProp object.

5.4 Origin

The origin of a resource and the effective script origin of a resource are both either opaque identifiers or tuples consisting of a scheme component, a host component, a port component, and optionally extra data.

The extra data could include the certificate of the site when using encrypted connections, to ensure that if the site's secure certificate changes, the origin is considered to change as well.

These characteristics are defined as follows:

For URLs

The origin and effective script origin of the URL is whatever is returned by the following algorithm:

  1. Let url be the URL for which the origin is being determined.

  2. Parse url.

  3. If url does not use a server-based naming authority, or if parsing url failed, or if url is not an absolute URL, then return a new globally unique identifier.

  4. Let scheme be the <scheme> component of url, converted to lowercase.

  5. If the UA doesn't support the protocol given by scheme, then return a new globally unique identifier.

  6. If scheme is "file", then the user agent may return a UA-specific value.

  7. Let host be the <host> component of url.

  8. Apply the IDNA ToASCII algorithm to host, with both the AllowUnassigned and UseSTD3ASCIIRules flags set. Let host be the result of the ToASCII algorithm.

    If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then return a new globally unique identifier. [RFC3490]

  9. Let host be the result of converting host to lowercase.

  10. If there is no <port> component, then let port be the default port for the protocol given by scheme. Otherwise, let port be the <port> component of url.

  11. Return the tuple (scheme, host, port).

In addition, if the URL is in fact associated with a Document object that was created by parsing the resource obtained from fetching URL, and this was done over a secure connection, then the server's secure certificate may be added to the origin as additional data.

For scripts

The origin and effective script origin of a script are determined from another resource, called the owner:

If a script is in a script element
The owner is the Document to which the script element belongs.
If a script is in an event handler content attribute
The owner is the Document to which the attribute node belongs.
If a script is a function or other code reference created by another script
The owner is the script that created it.
If a script is a javascript: URL that was returned as the location of an HTTP redirect (or equivalent in other protocols)
The owner is the URL that redirected to the javascript: URL.
If a script is a javascript: URL in an attribute
The owner is the Document of the element on which the attribute is found.
If a script is a javascript: URL in a style sheet
The owner is the URL of the style sheet.
If a script is a javascript: URL to which a browsing context is being navigated, the URL having been provided by the user (e.g. by using a bookmarklet)
The owner is the Document of the browsing context's active document.
If a script is a javascript: URL to which a browsing context is being navigated, the URL having been declared in markup
The owner is the Document of the element (e.g. an a or area element) that declared the URL.
If a script is a javascript: URL to which a browsing context is being navigated, the URL having been provided by script
The owner is the script that provided the URL.

The origin of the script is then equal to the origin of the owner, and the effective script origin of the script is equal to the effective script origin of the owner.

For Document objects and images
If a Document is in a browsing context whose sandboxed origin browsing context flag is set
The origin is a globally unique identifier assigned when the Document is created.
If a Document or image was returned by the XMLHttpRequest API
The origin and effective script origin are equal to the origin and effective script origin of the Document object of the Window object from which the XMLHttpRequest constructor was invoked. (That is, they track the Document to which the XMLHttpRequest object's Document pointer pointed when it was created.) [XHR]
If a Document or image was generated from a javascript: URL
The origin is equal to the origin of the script of that javascript: URL.
If a Document or image was served over the network and has an address that uses a URL scheme with a server-based naming authority
The origin is the origin of the address of the Document or the URL of the image, as appropriate.
If a Document or image was generated from a data: URL that was returned as the location of an HTTP redirect (or equivalent in other protocols)
The origin is the origin of the URL that redirected to the data: URL.
If a Document or image was generated from a data: URL found in another Document or in a script
The origin is the origin of the Document or script in which the data: URL was found.
If a Document has the address "about:blank"
The origin of the Document is the origin it was assigned when its browsing context was created.
If a Document or image was obtained in some other manner (e.g. a data: URL typed in by the user, a Document created using the createDocument() API, a data: URL returned as the location of an HTTP redirect, etc)
The origin is a globally unique identifier assigned when the Document or image is created.

When a Document is created, unless stated otherwise above, its effective script origin is initialized to the origin of the Document. However, the document.domain attribute can be used to change it.

The Unicode serialization of an origin is the string obtained by applying the following algorithm to the given origin:

  1. If the origin in question is not a scheme/host/port tuple, then return the literal string "null" and abort these steps.

  2. Otherwise, let result be the scheme part of the origin tuple.

  3. Append the string "://" to result.

  4. Apply the IDNA ToUnicode algorithm to each component of the host part of the origin tuple, and append the results — each component, in the same order, separated by U+002E FULL STOP characters (".") — to result.

  5. If the port part of the origin tuple gives a port that is different from the default port for the protocol given by the scheme part of the origin tuple, then append a U+003A COLON character (":") and the given port, in base ten, to result.

  6. Return result.

The ASCII serialization of an origin is the string obtained by applying the following algorithm to the given origin:

  1. If the origin in question is not a scheme/host/port tuple, then return the literal string "null" and abort these steps.

  2. Otherwise, let result be the scheme part of the origin tuple.

  3. Append the string "://" to result.

  4. Apply the IDNA ToASCII algorithm the host part of the origin tuple, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, and append the results result.

    If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then return the empty string and abort these steps. [RFC3490]

  5. If the port part of the origin tuple gives a port that is different from the default port for the protocol given by the scheme part of the origin tuple, then append a U+003A COLON character (":") and the given port, in base ten, to result.

  6. Return result.

Two origins are said to be the same origin if the following algorithm returns true:

  1. Let A be the first origin being compared, and B be the second origin being compared.

  2. If A and B are both opaque identifiers, and their value is equal, then return true.

  3. Otherwise, if either A or B or both are opaque identifiers, return false.

  4. If A and B have scheme components that are not identical, return false.

  5. If A and B have host components that are not identical, return false.

  6. If A and B have port components that are not identical, return false.

  7. If either A or B have additional data, but that data is not identical for both, return false.

  8. Return true.

5.4.1 Relaxing the same-origin restriction

The domain attribute on Document objects must be initialized to the document's domain, if it has one, and the empty string otherwise. On getting, the attribute must return its current value, unless the document was created by XMLHttpRequest, in which case it must throw an INVALID_ACCESS_ERR exception. On setting, the user agent must run the following algorithm:

  1. If the document was created by XMLHttpRequest, throw an INVALID_ACCESS_ERR exception and abort these steps.

  2. Apply the IDNA ToASCII algorithm to the new value, with both the AllowUnassigned and UseSTD3ASCIIRules flags set. Let new value be the result of the ToASCII algorithm.

    If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then throw a SECURITY_ERR exception and abort these steps. [RFC3490]

  3. If new value is not exactly equal to the current value of the document.domain attribute, then run these substeps:

    1. If the current value is an IP address, throw a SECURITY_ERR exception and abort these steps.

    2. If new value, prefixed by a U+002E FULL STOP ("."), does not exactly match the end of the current value, throw a SECURITY_ERR exception and abort these steps.

    3. If new value matches a suffix in the Public Suffix List, or, if new value, prefixed by a U+002E FULL STOP ("."), matches the end of a suffix in the Public Suffix List, then throw a SECURITY_ERR exception and abort these steps. [PSL]

      Suffixes must be compared after applying the IDNA ToASCII algorithm to them, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, in an ASCII case-insensitive manner. [RFC3490]

  4. Set the attribute's value to new value.

  5. Set the host part of the effective script origin tuple of the Document to new value.

  6. Set the port part of the effective script origin tuple of the Document to "manual override" (a value that, for the purposes of comparing origins, is identical to "manual override" but not identical to any other value).

The domain of a Document is the host part of the document's origin, if that is a scheme/host/port tuple. If it isn't, then the document does not have a domain.

The domain attribute is used to enable pages on different hosts of a domain to access each others' DOMs.

5.5 Scripting

5.5.1 Introduction

Various mechanisms can cause author-provided executable code to run in the context of a document. These mechanisms include, but are probably not limited to:

5.5.2 Enabling and disabling scripting

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

Scripting is disabled in a browsing context when any of the above conditions are false (i.e. when scripting is not enabled).


Scripting is enabled for a node if the Document object of the node (the node itself, if it is itself a Document object) has an associated browsing context, and scripting is enabled in that browsing context.

Scripting is disabled for a node if there is no such browsing context, or if scripting is disabled in that browsing context.

5.5.3 Processing model

5.5.3.1 Definitions

A script has:

A script execution environment

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 list of code entry-points

Each code entry-point represents a block of executable code that the script exposes to other scripts and to the user agent.

Each Function object in a JavaScript script execution environment has a corresponding code entry-point, for instance.

The main program code of the script, if any, is the initial code entry-point. Typically, the code corresponding to this entry-point is executed immediately after the script is parsed.

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

A relationship with the script's global object

An object that provides the APIs that the code can use.

This is typically a Window object. In JavaScript, this corresponds to the global object.

When a script's global object is an empty object, it can't do anything that interacts with the environment.

A relationship with the script's browsing context

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

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 script's browsing context's Window object.

A character encoding

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

A base URL

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.

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

  1. If the script's global object is a Window object whose Document object is not fully active, then abort these steps without doing anything. The callback is not fired.

  2. Set the first script to be the script being invoked.

  3. Make the script execution environment for the script execute the code for the given code entry-point.

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

This algorithm is not invoked by one script calling another.

5.5.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 character encoding, and a base URL, the user agent must run the following steps:

  1. Set up a script execution environment as appropriate for the scripting language.

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

  3. Set up the script's global object, the script's browsing context, the script's character encoding, and the script's base URL from the settings passed to this algorithm.

  4. Jump to the script's initial code entry-point.


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 character encoding and base URL for the resulting script are not important as no APIs are exposed to the script.


When the specification says that a script is to be created from a node node, given some script source and its scripting language, the user agent must create a script, using the given script source and scripting language, and using the script settings determined from the node node.

The script settings determined from the node node are computed as follows:

  1. Let document be the Document of node (or node itself if it is a Document).

  2. The browsing context is the browsing context of document.

  3. The global object is the Window object of document.

  4. The character encoding is the character encoding of document. (This is a reference, not a copy.)

  5. The base URL is the base URL of document. (This is a reference, not a copy.)

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

5.5.4 Event loops

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

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

An event loop always has at least one browsing context. If 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.

Other specifications can define new kinds of event loops that aren't associated with browsing contexts.

An event loop has one or more task queues. A task queue is an ordered list of tasks, which can be:

Events

Asynchronously dispatching an Event object at a particular EventTarget object is a task.

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

Parsing

The HTML parser tokenising a single byte, and then processing any resulting tokens, is a task.

Callbacks

Calling a callback asynchronously is a task.

Using a resource

When an algorithm fetches a resource, if the fetching occurs asynchronously then the processing of the resource once some or all of the resource is available is 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 is associated with a Document; if the task was queued in the context of an element, then it is the element's 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 script's script's browsing context's active document at the time the task was queued.

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.

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

  1. Run the oldest task on one of the event loop's task queues, ignoring tasks whose associated Documents are not fully active. The user agent may pick any task queue.

  2. Remove that task from its task queue.

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

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

5.5.4.1 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 asynchronously when an element is inserted into the document.

Asynchronous mutation events must be dispatched using tasks queued with the DOM manipulation task source. [DOMEVENTS]

The user interaction task source

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

Asynchronous events sent in response to user input (e.g. click events) must be dispatched 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.

5.5.5 The javascript: protocol

When a URL using the javascript: protocol is dereferenced, the user agent must run the following steps:

  1. Let the script source be the string obtained using the content retrieval operation defined for javascript: URLs. [JSURL]

  2. Use the appropriate step from the following list:

    If a browsing context is being navigated to a javascript: URL, and the active document of that browsing context has the same origin as the script given by that URL

    Let address be the address of the active document of the browsing context being navigated.

    If address is about:blank, and the browsing context being navigated has a creator browsing context, then let address be the address of the creator Document instead.

    Create a script from the Document node of the active document, using the aforementioned script source, and assuming the scripting language is JavaScript.

    Let result be the return value of the initial code entry-point of this script. If an exception was raised, let result be void instead.

    When it comes time to set the document's address in the navigation algorithm, use address as the override URL.

    If the Document object of the element, attribute, or style sheet from which the javascript: URL was reached has an associated browsing context

    Create an impotent script using the aforementioned script source, with the scripting language set to JavaScript, and with the Document's object's browsing context as the browsing context.

    Let result be the return value of the initial code entry-point of this script. If an exception was raised, let result be void instead.

    Otherwise

    Let result be void.

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

    Certain contexts, in particular img elements, ignore the Content-Type metadata.

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.

The src attribute of an iframe element would be evaluated in the context of the iframe's own browsing context; once evaluated, its return value (if it was not void) would replace that browsing context's document, thus changing the variables visible in that browsing context.

The rules for creating a script include making the script not execute (and just return void) in certain cases, e.g. in a sandbox or when the user has disabled scripting altogether.

5.5.6 Events

5.5.6.1 Event handler attributes

Many objects can have event handler attributes specified. These act as bubbling event listeners for the element on which they are specified.

An event handler attribute, unless otherwise specified, can either have the value null or be set to a Function object. Initially, unless otherwise specified, an event handler attribute must be set to null.

Some event handler attributes allow other values and have other initial values, in particular the onerror event handler attribute on the Window object.

Event handler attributes are exposed in one or two ways.

The first way, common to all event handler attributes, is as an event handler DOM 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.


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

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


Event handler content attributes, when specified, must contain valid ECMAScript code matching the ECMAScript FunctionBody production. [ECMA262]

When an event handler content attribute is set, if the element is owned by a Document that is in a browsing context, the user agent must run the following steps to create a script after setting the content attribute to its new value:

  1. Set up a script execution environment for JavaScript.

  2. Using this script execution environment, interpret the attribute's new value as the body of an anonymous function, with the function's arguments set as follows:

    If the attribute is the onerror attribute of the Window object
    Let the function have three arguments, named event, source, and fileno.
    Otherwise
    Let the function have a single argument called event.

    Link the new function's scope chain from the activation object of the handler, to the element's object, to the element's form owner, if it has one, to the element's Document object, to the Window object of that Document. Set the function's this parameter to the Element object representing the element. Let this function be the only entry in the script's list of code entry-points.

    See ECMA262 Edition 3, sections 10.1.6 and 10.2.3, for more details on activation objects. [ECMA262]

  3. If the previous steps failed to compile the script, then set the corresponding event handler attribute to null and abort these steps.

  4. Set up the script's global object, the script's browsing context, the script's character encoding, and the script's base URL from the script settings determined from the node on which the attribute is being set.

  5. Set the corresponding event handler attribute to the aforementioned function.

When an event handler content attribute is set on an element owned by a Document that is not in a browsing context, the corresponding event handler attribute is not changed.

Removing an event handler content attribute does not reset the corresponding event handler attribute.

How do we allow non-JS event handlers?


All event handler attributes on an element, whether set to null or to a Function object, must be registered as event listeners on the element, as if the addEventListenerNS() method on the Element object's EventTarget interface had been invoked when the event handler attribute's element or object was created, with the event type (type argument) equal to the type described for the event handler attribute in the list above, the namespace (namespaceURI argument) set to null, the listener set to be a target and bubbling phase listener (useCapture argument set to false), the event group set to the default group (evtGroup argument set to null), and the event listener itself (listener argument) set to do nothing while the event handler attribute's value is not a Function object, and set to invoke the call() callback of the Function object associated with the event handler attribute otherwise.

The listener argument is emphatically not the event handler attribute itself.

When an event handler attribute's Function objectw is invoked, its call() callback must be invoked with one argument, set to the Event object of the event in question.

The handler's return value must then be processed as follows:

If the event type is mouseover

If the return value is a boolean with the value true, then the event must be canceled.

If the event object is a BeforeUnloadEvent object

If the return value is a string, and the event object's returnValue attribute's value is the empty string, then set the returnValue attribute's value to the return value.

Otherwise

If the return value is a boolean with the value false, then the event must be canceled.


The Function interface represents a function in the scripting language being used. It is represented in IDL as follows:

[Callback=FunctionOnly, NoInterfaceObject]
interface Function {
  any call([Variadic] in any arguments);
};

The call(...) method is the object's callback.

In JavaScript, any Function object implements this interface.

5.5.6.2 Event handler attributes on elements and on Window objects

The following are the event handler attributes that must be supported by all HTML elements, as both content attributes and DOM attributes, and on Window objects, as DOM attributes:

onabort

Must be invoked whenever an abort event is targeted at or bubbles through the element or object.

onblur

Must be invoked whenever a blur event is targeted at or bubbles through the element or object.

onchange

Must be invoked whenever a change event is targeted at or bubbles through the element or object.

onclick

Must be invoked whenever a click event is targeted at or bubbles through the element or object.

oncontextmenu

Must be invoked whenever a contextmenu event is targeted at or bubbles through the element or object.

ondblclick

Must be invoked whenever a dblclick event is targeted at or bubbles through the element or object.

ondrag

Must be invoked whenever a drag event is targeted at or bubbles through the element or object.

ondragend

Must be invoked whenever a dragend event is targeted at or bubbles through the element or object.

ondragenter

Must be invoked whenever a dragenter event is targeted at or bubbles through the element or object.

ondragleave

Must be invoked whenever a dragleave event is targeted at or bubbles through the element or object.

ondragover

Must be invoked whenever a dragover event is targeted at or bubbles through the element or object.

ondragstart

Must be invoked whenever a dragstart event is targeted at or bubbles through the element or object.

ondrop

Must be invoked whenever a drop event is targeted at or bubbles through the element or object.

onfocus

Must be invoked whenever a focus event is targeted at or bubbles through the element or object.

onkeydown

Must be invoked whenever a keydown event is targeted at or bubbles through the element or object.

onkeypress

Must be invoked whenever a keypress event is targeted at or bubbles through the element or object.

onkeyup

Must be invoked whenever a keyup event is targeted at or bubbles through the element or object.

onmousedown

Must be invoked whenever a mousedown event is targeted at or bubbles through the element or object.

onmousemove

Must be invoked whenever a mousemove event is targeted at or bubbles through the element or object.

onmouseout

Must be invoked whenever a mouseout event is targeted at or bubbles through the element or object.

onmouseover

Must be invoked whenever a mouseover event is targeted at or bubbles through the element or object.

onmouseup

Must be invoked whenever a mouseup event is targeted at or bubbles through the element or object.

onmousewheel

Must be invoked whenever a mousewheel event is targeted at or bubbles through the element or object.

onscroll

Must be invoked whenever a scroll event is targeted at or bubbles through the element or object.

onselect

Must be invoked whenever a select event is targeted at or bubbles through the element or object.

onsubmit

Must be invoked whenever a submit event is targeted at or bubbles through the element or object.


The following are the event handler attributes that must be supported by all HTML elements other than body, as both content attributes and DOM attributes:

onerror

Must be invoked whenever a error event is targeted at or bubbles through the element.

onload

Must be invoked whenever a load event is targeted at or bubbles through the element.

onmessage

Must be invoked whenever a message event is targeted at or bubbles through the element.


The following are the event handler attributes that must be supported by Window objects, as DOM attributes on the Window object, and with corresponding content attributes and DOM attributes exposed on the body element:

onbeforeunload

Must be invoked whenever a beforeunload event is targeted at or bubbles through the object.

onerror

Must be invoked whenever an error event is targeted at or bubbles through the object.

Unlike other event handler attributes, the onerror event handler attribute can have any value. The initial value of onerror must be undefined.

The onerror handler is also used for reporting script errors.

onhashchange

Must be invoked whenever a hashchange event is targeted at or bubbles through the object.

onload

Must be invoked whenever a load event is targeted at or bubbles through the object.

onmessage

Must be invoked whenever a message event is targeted at or bubbles through the object.

onoffline

Must be invoked whenever a offline event is targeted at or bubbles through the object.

ononline

Must be invoked whenever a online event is targeted at or bubbles through the object.

onpopstate

Must be invoked whenever a popstate event is targeted at or bubbles through the object.

onresize

Must be invoked whenever a resize event is targeted at or bubbles through the object.

onstorage

Must be invoked whenever a storage event is targeted at or bubbles through the object.

onunload

Must be invoked whenever an unload event is targeted at or bubbles through the object.

5.5.6.3 Event firing

maybe this should be moved higher up (terminology? conformance? DOM?) Also, the whole terminology thing should be changed so that we don't define any specific events here, we only define 'simple event', 'progress event', 'mouse event', 'key event', and the like, and have the actual dispatch use those generic terms when firing events.

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. [DOM3EVENTS]

Firing a click event means that a click event with no namespace, which bubbles and is cancelable, 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.

Firing a contextmenu event means that a contextmenu event with no namespace, which bubbles and is cancelable, and which uses the Event interface, must be dispatched at the given target.

Firing a simple event called e means that an event with the name e, with no namespace, which does not bubble but is cancelable (unless otherwise stated), and which uses the Event interface, must be dispatched at the given target.

Firing a show event means firing a simple event called show. Actually this should fire an event that has modifier information (shift/ctrl etc), as well as having a pointer to the node on which the menu was fired, and with which the menu was associated (which could be an ancestor of the former).

Firing a load event means firing a simple event called load. Firing an error event means firing a simple event called error.

Firing a progress event called e means something that hasn't yet been defined, in the [PROGRESS] spec.

The default action of these event is to do nothing unless otherwise stated.

If you dispatch a custom "click" event at an element that would normally have default actions, should they get triggered? If so, we need to go through the entire spec and make sure that any default actions are defined in terms of any event of the right type on that element, not those that are dispatched in expected ways.

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

  1. In the capture phase, the event must be dispatched to the Window object before being dispatched to any of the nodes.
  2. In the bubble phase, the event must be dispatched to the Window object at the end of the phase, unless bubbling has been prevented.
5.5.6.5 Runtime script errors

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

Whenever a runtime script error occurs in one of the scripts associated with a Document, the user agent must report the error using the onerror event handler attribute of the script's global object. If the error is still not handled after this, then the error should be reported to the user.


When the user agent is required to report an error error using the event handler attribute onerror, it must run these steps, after which the error is either handled or not handled:

If the value of onerror is a Function

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 exceptions thrown or errors caused by this function must be reported to the user immediately after the error that the function was called for, without using the report an error algorithm again.

If the value is null

The error is handled.

If the value is anything else

The error is not handled.

5.6 User prompts

5.6.1 Simple dialogs

The alert(message) method, when invoked, must show the given message to the user. The user agent may make the method wait for the user to acknowledge the message before returning; if so, the user agent must pause while the method is waiting.

The confirm(message) method, when invoked, must show the given message to the user, and ask the user to respond with a positive or negative response. The user agent must then pause as the method waits for the user's response. If the user responds positively, the method must return true, and if the user responds negatively, the method must return false.

The prompt(message, default) method, when invoked, must show the given message to the user, and ask the user to either respond with a string value or abort. The user agent must then pause as the method waits for the user's response. The second argument is optional. If the second argument (default) is present, then the response must be defaulted to the value given by default. If the user aborts, then the method must return null; otherwise, the method must return the string that the user responded with.

5.6.2 Printing

The print() method, when invoked, must run the printing steps.

User agents should also run the printing steps whenever the user asks for the opportunity to obtain a physical form (e.g. printed copy), or the representation of a physical form (e.g. PDF copy), of a document.

The printing steps are as follows:

  1. The user agent may display a message to the user and/or may abort these steps.

    For instance, a kiosk browser could silently ignore any invocations of the print() method.

    For instance, a browser on a mobile device could detect that there are no printers in the vicinity and display a message saying so before continuing to offer a "save to PDF" option.

  2. The user agent must fire a simple event called beforeprint at the Window object of the Document that is being printed, as well as any nested browsing contexts in it.

    The beforeprint event can be used to annotate the printed copy, for instance adding the time at which the document was printed.

  3. The user agent should offer the user the opportunity to obtain a physical form (or the representation of a physical form) of the document. The user agent may wait for the user to either accept or decline before returning; if so, the user agent must pause while the method is waiting. Even if the user agent doesn't wait at this point, the user agent must use the state of the relevant documents as they are at this point in the algorithm if and when it eventually creates the alternate form.

  4. The user agent must fire a simple event called afterprint at the Window object of the Document that is being printed, as well as any nested browsing contexts in it.

    The afterprint event can be used to revert annotations added in the earlier event, as well as showing post-printing UI. For instance, if a page is walking the user through the steps of applying for a home loan, the script could automatically advance to the next step after having printed a form or other.

5.6.3 Dialogs implemented using separate documents

The showModalDialog(url, argument) method, when invoked, must cause the user agent to run the following steps:

  1. Resolve url relative to the first script's base URL.

    If this fails, then throw a SYNTAX_ERR exception and abort these steps.

  2. If the user agent is configured such that this invocation of showModalDialog() is somehow disabled, then the method returns the empty string; abort these steps.

    User agents are expected to disable this method in certain cases to avoid user annoyance (e.g. as part of their popup blocker feature). For instance, a user agent could require that a site be white-listed before enabling this method, or the user agent could be configured to only allow one modal dialog at a time.

  3. Let the list of background browsing contexts be a list of all the browsing contexts that:

    ...as well as any browsing contexts that are nested inside any of the browsing contexts matching those conditions.

  4. Disable the user interface for all the browsing contexts in the list of background browsing contexts. This should prevent the user from navigating those browsing contexts, causing events to to be sent to those browsing context, or editing any content in those browsing contexts. However, it does not prevent those browsing contexts from receiving events from sources other than the user, from running scripts, from running animations, and so forth.

  5. Create a new auxiliary browsing context, with the opener browsing context being the browsing context of the Window object on which the showModalDialog() method was called. The new auxiliary browsing context has no name.

    This browsing context's Documents' Window objects all implement the WindowModal interface.

  6. Let the dialog arguments of the new browsing context be set to the value of argument, or the 'undefined' value if the argument was omitted.

  7. Let the dialog arguments' origin be the origin of the script that called the showModalDialog() method.

  8. Navigate the new browsing context to the absolute URL that resulted from resolving url earlier, with replacement enabled, and with the browsing context of the script that invoked the method as the source browsing context.

  9. Wait for the browsing context to be closed. (The user agent must allow the user to indicate that the browsing context is to be closed.)

  10. Reenable the user interface for all the browsing contexts in the list of background browsing contexts.

  11. Return the auxiliary browsing context's return value.

The Window objects of Documents hosted by browsing contexts created by the above algorithm must all implement the WindowModal interface:

Really I want the Window object to just gain these attributes, as if they were on the Window prototype. That's the XXX below.

[NoInterfaceObject, ImplementedOn=Window, XXX] interface WindowModal {
  readonly attribute any dialogArguments;
           attribute DOMString returnValue;
};

Such browsing contexts have associated dialog arguments, which are stored along with the dialog arguments' origin. These values are set by the showModalDialog() method in the algorithm above, when the browsing context is created, based on the arguments provided to the method.

The dialogArguments DOM attribute, on getting, must check whether its browsing context's active document's origin is the same as the dialog arguments' origin. If it is, then the browsing context's dialog arguments must be returned unchanged. Otherwise, if the dialog arguments are an object, then the empty string must be returned, and if the dialog arguments are not an object, then the stringification of the dialog arguments must be returned.

These browsing contexts also have an associated return value. The return value of a browsing context must be initialized to the empty string when the browsing context is created.

The returnValue DOM attribute, on getting, must return the return value of its browsing context, and on setting, must set the return value to the given new value.

The window.close() method can be used to close the browsing context.

5.7 System state and capabilities

The navigator attribute of the Window interface must return an instance of the Navigator interface, which represents the identity and state of the user agent (the client), and allows Web pages to register themselves as potential protocol and content handlers:

interface Navigator {
  // objects implementing this interface also implement the interfaces given below
};

[NoInterfaceObject, ImplementedOn=Navigator] interface NavigatorID {
  readonly attribute DOMString appName;
  readonly attribute DOMString appVersion;
  readonly attribute DOMString platform;
  readonly attribute DOMString userAgent;
};

[NoInterfaceObject, ImplementedOn=Navigator] interface NavigatorOnLine {
  readonly attribute boolean onLine;
};

[NoInterfaceObject, ImplementedOn=Navigator] interface NavigatorAbilities {
  // content handler registration
  void registerProtocolHandler(in DOMString protocol, in DOMString url, in DOMString title);
  void registerContentHandler(in DOMString mimeType, in DOMString url, in DOMString title);
};

Objects implementing the Navigator interface must also implement the NavigatorID, NavigatorOnLine, and NavigatorAbilities interfaces. (These interfaces are defined separately so that other specifications can re-use parts of the Navigator interface.)

5.7.1 Client identification

In certain cases, despite the best efforts of the entire industry, Web browsers have bugs and limitations that Web authors are forced to work around.

This section defines a collection of attributes that can be used to determine, from script, the kind of user agent in use, in order to work around these issues.

Client detection should always be limited to detecting known current versions; future versions and unknown versions should always be assumed to be fully compliant.

appName

Must return either the string "Netscape" or the full name of the browser, e.g. "Mellblom Browsernator".

appVersion

Must return either the string "4.0" or a string representing the version of the browser in detail, e.g. "1.0 (VMS; en-US) Mellblomenator/9000".

platform

Must return either the empty string or a string representing the platform on which the browser is executing, e.g. "MacIntel", "Win32", "FreeBSD i386", "WebTV OS".

userAgent

Must return the string used for the value of the "User-Agent" header in HTTP requests, or the empty string if no such header is ever sent.

5.7.2 Custom protocol and content handlers

The registerProtocolHandler() method allows Web sites to register themselves as possible handlers for particular protocols. For example, an online fax service could register itself as a handler of the fax: protocol ([RFC2806]), so that if the user clicks on such a link, he is given the opportunity to use that Web site. Analogously, the registerContentHandler() method allows Web sites to register themselves as possible handlers for content in a particular MIME type. For example, the same online fax service could register itself as a handler for image/g3fax files ([RFC1494]), so that if the user has no native application capable of handling G3 Facsimile byte streams, his Web browser can instead suggest he use that site to view the image.

User agents may, within the constraints described in this section, do whatever they like when the methods are called. A UA could, for instance, prompt the user and offer the user the opportunity to add the site to a shortlist of handlers, or make the handlers his default, or cancel the request. UAs could provide such a UI through modal UI or through a non-modal transient notification interface. UAs could also simply silently collect the information, providing it only when relevant to the user.

There is an example of how these methods could be presented to the user below.

The arguments to the methods have the following meanings and corresponding implementaion requirements:

protocol (registerProtocolHandler() only)

A scheme, such as ftp or fax. The scheme must be compared in an ASCII case-insensitive manner by user agents for the purposes of comparing with the scheme part of URLs that they consider against the list of registered handlers.

The protocol value, if it contains a colon (as in "ftp:"), will never match anything, since schemes don't contain colons.

mimeType (registerContentHandler() only)

A MIME type, such as model/vrml or text/richtext. The MIME type must be compared in an ASCII case-insensitive manner by user agents for the purposes of comparing with MIME types of documents that they consider against the list of registered handlers.

User agents must compare the given values only to the MIME type/subtype parts of content types, not to the complete type including parameters. Thus, if mimeType values passed to this method include characters such as commas or whitespace, or include MIME parameters, then the handler being registered will never be used.

url

The URL of the page that will handle the requests.

When the user agent uses this URL, it must replace the first occurrence of the exact literal string "%s" with an escaped version of the absolute URL of the content in question (as defined below), then resolve the resulting URL, relative to the base URL of the first script at the time the registerContentHandler() or registerProtocolHandler() methods were invoked, and then fetch the resulting URL using the GET method (or equivalent for non-HTTP URLs).

To get the escaped version of the absolute URL of the content in question, the user agent must replace every character in that absolute URL that doesn't match the <query> production defined in RFC 3986 by the percent-encoded form of that character. [RFC3986]

If the user had visited a site at http://example.com/ that made the following call:

navigator.registerContentHandler('application/x-soup', 'soup?url=%s', 'SoupWeb™')

...and then, much later, while visiting http://www.example.net/, clicked on a link such as:

<a href="chickenkïwi.soup">Download our Chicken Kiwi soup!</a>

...then, assuming this chickenkïwi.soup file was served with the MIME type application/x-soup, the UA might navigate to the following URL:

http://example.com/soup?url=http://www.example.net/chickenk%C3%AFwi.soup

This site could then fetch the chickenkïwi.soup file and do whatever it is that it does with soup (synthesize it and ship it to the user, or whatever).

title

A descriptive title of the handler, which the UA might use to remind the user what the site in question is.

User agents should raise SECURITY_ERR exceptions if the methods are called with protocol or mimeType values that the UA deems to be "privileged". For example, a site attempting to register a handler for http URLs or text/html content in a Web browser would likely cause an exception to be raised.

User agents must raise a SYNTAX_ERR exception if the url argument passed to one of these methods does not contain the exact literal string "%s", or if resolving the url argument with the first occurance of the string "%s" removed, relative to the first script's base URL, is not successful.

User agents must not raise any other exceptions (other than binding-specific exceptions, such as for an incorrect number of arguments in an ECMAScript implementation).

This section does not define how the pages registered by these methods are used, beyond the requirements on how to process the url value (see above). To some extent, the processing model for navigating across documents defines some cases where these methods are relevant, but in general UAs may use this information wherever they would otherwise consider handing content to native plugins or helper applications.

UAs must not use registered content handlers to handle content that was returned as part of a non-GET transaction (or rather, as part of any non-idempotent transaction), as the remote site would not be able to fetch the same data.

5.7.2.1 Security and privacy

These mechanisms can introduce a number of concerns, in particular privacy concerns.

Hijacking all Web usage. User agents should not allow protocols that are key to its normal operation, such as http or https, to be rerouted through third-party sites. This would allow a user's activities to be trivially tracked, and would allow user information, even in secure connections, to be collected.

Hijacking defaults. It is strongly recommended that user agents do not automatically change any defaults, as this could lead the user to send data to remote hosts that the user is not expecting. New handlers registering themselves should never automatically cause those sites to be used.

Registration spamming. User agents should consider the possibility that a site will attempt to register a large number of handlers, possibly from multiple domains (e.g. by redirecting through a series of pages each on a different domain, and each registering a handler for video/mpeg — analogous practices abusing other Web browser features have been used by pornography Web sites for many years). User agents should gracefully handle such hostile attempts, protecting the user.

Misleading titles. User agents should not rely wholly on the title argument to the methods when presenting the registered handlers to the user, since sites could easily lie. For example, a site hostile.example.net could claim that it was registering the "Cuddly Bear Happy Content Handler". User agents should therefore use the handler's domain in any UI along with any title.

Hostile handler metadata. User agents should protect against typical attacks against strings embedded in their interface, for example ensuring that markup or escape characters in such strings are not executed, that null bytes are properly handled, that over-long strings do not cause crashes or buffer overruns, and so forth.

Leaking Intranet URLs. The mechanism described in this section can result in secret Intranet URLs being leaked, in the following manner:

  1. The user registers a third-party content handler as the default handler for a content type.
  2. The user then browses his corporate Intranet site and accesses a document that uses that content type.
  3. The user agent contacts the third party and hands the third party the URL to the Intranet content.

No actual confidential file data is leaked in this manner, but the URLs themselves could contain confidential information. For example, the URL could be http://www.corp.example.com/upcoming-aquisitions/the-sample-company.egf, which might tell the third party that Example Corporation is intending to merge with The Sample Company. Implementors might wish to consider allowing administrators to disable this feature for certain subdomains, content types, or protocols.

Leaking secure URLs. User agents should not send HTTPS URLs to third-party sites registered as content handlers, in the same way that user agents do not send Referer headers from secure sites to third-party sites.

Leaking credentials. User agents must never send username or password information in the URLs that are escaped and included sent to the handler sites. User agents may even avoid attempting to pass to Web-based handlers the URLs of resources that are known to require authentication to access, as such sites would be unable to access the resources in question without prompting the user for credentials themselves (a practice that would require the user to know whether to trust the third-party handler, a decision many users are unable to make or even understand).

5.7.2.2 Sample user interface

This section is non-normative.

A simple implementation of this feature for a desktop Web browser might work as follows.

The registerProtocolHandler() method could display a modal dialog box:

||[ Protocol Handler Registration ]|||||||||||||||||||||||||||
|                                                            |
| This Web page:                                             |
|                                                            |
|    Kittens at work                                         |
|    http://kittens.example.org/                             |
|                                                            |
| ...would like permission to handle the protocol "x-meow:"  |
| using the following Web-based application:                 |
|                                                            |
|    Kittens-at-work displayer                               |
|    http://kittens.example.org/?show=%s                     |
|                                                            |
| Do you trust the administrators of the "kittens.example.   |
| org" domain?                                               |
|                                                            |
|              ( Trust kittens.example.org )  (( Cancel ))   |
|____________________________________________________________|

...where "Kittens at work" is the title of the page that invoked the method, "http://kittens.example.org/" is the URL of that page, "x-meow" is the string that was passed to the registerProtocolHandler() method as its first argument (protocol), "http://kittens.example.org/?show=%s" was the second argument (url), and "Kittens-at-work displayer" was the third argument (title).

If the user clicks the Cancel button, then nothing further happens. If the user clicks the "Trust" button, then the handler is remembered.

When the user then attempts to fetch a URL that uses the "x-meow:" scheme, then it might display a dialog as follows:

||[ Unknown Protocol ]||||||||||||||||||||||||||||||||||||||||
|                                                            |
| You have attempted to access:                              |
|                                                            |
|    x-meow:S2l0dGVucyBhcmUgdGhlIGN1dGVzdCE%3D               |
|                                                            |
| How would you like FerretBrowser to handle this resource?  |
|                                                            |
|  (o) Contact the FerretBrowser plugin registry to see if   |
|      there is an official way to handle this resource.     |
|                                                            |
|  ( ) Pass this URL to a local application:                 |
|      [ /no application selected/             ] ( Choose )  |
|                                                            |
|  ( ) Pass this URL to the "Kittens-at-work displayer"      |
|      application at "kittens.example.org".                 |
|                                                            |
|  [ ] Always do this for resources using the "x-meow"       |
|      protocol in future.                                   |
|                                                            |
|                                     ( Ok )  (( Cancel ))   |
|____________________________________________________________|

...where the third option is the one that was primed by the site registering itself earlier.

If the user does select that option, then the browser, in accordance with the requirements described in the previous two sections, will redirect the user to "http://kittens.example.org/?show=x-meow%3AS2l0dGVucyBhcmUgdGhlIGN1dGVzdCE%253D".

The registerContentHandler() method would work equivalently, but for unknown MIME types instead of unknown protocols.