6.5.9 History traversal

When a user agent is required to traverse the history to a specified entry, optionally with replacement enabled, the user agent must act as follows:

  1. If there is no longer a Document object for the entry in question, the user agent must navigate the browsing context to the location for that entry to perform an entry update of that entry, and abort these steps. The "navigate" algorithm reinvokes this "traverse" algorithm to complete the traversal, at which point there is a Document object and so this step gets skipped. The navigation must be done using the same source browsing context as was used the first time this entry was created. (This can never happen with replacement enabled.)

  2. If the current entry's title was not set by the pushState() or replaceState() methods, then set its title to the value returned by the document.title IDL attribute.

  3. If appropriate, update the current entry in the browsing context's Document object's History object to reflect any state that the user agent wishes to persist. The entry is then said to be an entry with persisted user state.

    For example, some user agents might want to persist the scroll position, or the values of form controls.

  4. If the specified entry has a different Document object than the current entry then the user agent must run the following substeps:

    1. If the browsing context is a top-level browsing context, but not an auxiliary browsing context, and the origin of the Document of the specified entry is not the same as the origin of the Document of the current entry, then the following sub-sub-steps must be run:
      1. The current browsing context name must be stored with all the entries in the history that are associated with Document objects with the same origin as the active document and that are contiguous with the current entry.
      2. The browsing context's browsing context name must be unset.
    2. The user agent must make the specified entry's Document object the active document of the browsing context.
    3. If the specified entry has a browsing context name stored with it, then the following sub-sub-steps must be run:
      1. The browsing context's browsing context name must be set to the name stored with the specified entry.
      2. Any browsing context name stored with the entries in the history that are associated with Document objects with the same origin as the new active document, and that are contiguous with the specified entry, must be cleared.
    4. If the specified entry's Document has any input elements whose resulting autocompletion state is off, invoke the reset algorithm of each of those elements.

    5. If the current document readiness of the specified entry's Document is "complete", queue a task to fire a pageshow event at the Window object of that Document, but with its target set to the Document object (and the currentTarget set to the Window object), using the PageTransitionEvent interface, with the persisted attribute set to true. This event must not bubble, must not be cancelable, and has no default action.

  5. Set the document's current address to the URL of the specified entry.

  6. If the specified entry has a URL that differs from the current entry's only by its fragment identifier, and the two share the same Document object, then let hash changed be true, and let old URL be the URL of the current entry and new URL be the URL of the specified entry. Otherwise, let hash changed be false.

  7. If the traversal was initiated with replacement enabled, remove the entry immediately before the specified entry in the session history.

  8. If the specified entry is not an entry with persisted user state, but its URL has a fragment identifier, scroll to the fragment identifier.

  9. If the entry is an entry with persisted user state, the user agent may update aspects of the document view, for instance the scroll position or values of form fields, that it had previously recorded.

  10. If the specified entry is a state object or the first entry for a Document, the user agent must run the following substeps:

    1. If the entry is a state object entry, let state be a structured clone of that state object. Otherwise, let state be null.

    2. Run the appropriate steps according to the conditions described:

      If the current document readiness is set to the string "complete"

      Queue a task to fire a popstate event at the Window object of the Document, using the PopStateEvent interface, with the state attribute set to the value of state. This event must bubble but not be cancelable and has no default action.

      Otherwise

      Let the Document's pending state object be state. (If there was already a pending state object, the previous one is discarded.)

      The event will then be fired just after the load event.

  11. If hash changed is true, then queue a task to fire a hashchange event at the browsing context's Window object, using the HashChangeEvent interface, with the oldURL attribute set to old URL and the newURL attribute set to new URL. This event must bubble but not be cancelable and has no default action.

  12. The current entry is now the specified entry.

The pending state object must be initially null.

The task source for the tasks mentioned above is the DOM manipulation task source.

6.5.9.1 Event definitions

The popstate event is fired when navigating to a session history entry that represents a state object.

interface PopStateEvent : Event {
  readonly attribute any state;
  void initPopStateEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any stateArg);
};
event . state

Returns a copy of the information that was provided to pushState() or replaceState().

The initPopStateEvent() method must initialize the event in a manner analogous to the similarly-named method in the DOM Events interfaces. [DOMEVENTS]

The state attribute represents the context information for the event, or null, if the state represented is the initial state of the Document.


The hashchange event is fired when navigating to a session history entry whose URL differs from that of the previous one only in the fragment identifier.

interface HashChangeEvent : Event {
  readonly attribute any oldURL;
  readonly attribute any newURL;
  void initHashChangeEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in DOMString oldURLArg, in DOMString newURLArg);
};
event . oldURL

Returns the URL of the session history entry that was previously current.

event . newURL

Returns the URL of the session history entry that is now current.

The initHashChangeEvent() method must initialize the event in a manner analogous to the similarly-named method in the DOM Events interfaces. [DOMEVENTS]

The oldURL attribute represents context information for the event, specifically the URL of the session history entry that was traversed from.

The newURL attribute represents context information for the event, specifically the URL of the session history entry that was traversed to.


The pageshow event is fired when traversing to a session history entry.

The pagehide event is fired when traversing from a session history entry.

interface PageTransitionEvent : Event {
  readonly attribute any persisted;
  void initPageTransitionEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in any persistedArg);
};
event . persisted

Returns false if the page is newly being loaded (and the load event will fire). Otherwise, returns true.

The initPageTransitionEvent() method must initialize the event in a manner analogous to the similarly-named method in the DOM Events interfaces. [DOMEVENTS]

The persisted attribute represents the context information for the event.

6.5.10 Unloading documents

A Document has a salvageable state, which is initially true.

When a user agent is to prompt to unload a document, it must run the following steps.

  1. Let event be a new BeforeUnloadEvent event object with the name beforeunload, which does not bubble but is cancelable.

  2. Dispatch: Dispatch event at the Document's Window object.

  3. Release the storage mutex.

  4. If any event listeners were triggered by the earlier dispatch step, then set the Document's salvageable state to false.

  5. If the returnValue attribute of the event object is not the empty string, or if the event was canceled, then the user agent should ask the user to confirm that they wish to unload the document.

    The prompt shown by the user agent may include the string of the returnValue attribute, or some leading subset thereof. (A user agent may want to truncate the string to 1024 characters for display, for instance.)

    The user agent must pause while waiting for the user's response.

    If the user did not confirm the page navigation, then the user agent refused to allow the document to be unloaded.

  6. If this algorithm was invoked by another instance of the "prompt to unload a document" algorithm (i.e. through the steps below that invoke this algorithm for all descendant browsing contexts), then abort these steps here.

  7. Let descendants be the list of the descendant browsing contexts of the Document.

  8. If descendants is not an empty list, then for each browsing context b in descendants run the following substeps:

    1. Prompt to unload the active document of the browsing context b. If the user refused to allow the document to be unloaded, then the user implicitly also refused to allow this document to be unloaded; abort these steps.

    2. If salvageable state of the active document of the browsing context b is false, then set the salvageable state of this document to false also.

When a user agent is to unload a document, it must run the following steps. These steps are passed an argument, recycle, which is either true or false, indicating whether the Document object is going to be re-used. (This is set by the document.open() method.)

  1. Fire a pagehide event at the Window object of the Document, but with its target set to the Document object (and the currentTarget set to the Window object), using the PageTransitionEvent interface, with the persisted attribute set to true. This event must not bubble, must not be cancelable, and has no default action.

  2. Unload event: Fire a simple event named unload at the Document's Window object.

  3. Release the storage mutex.

  4. If any event listeners were triggered by the earlier unload event step, then set the Document object's salvageable state to false.

  5. Run any unloading document cleanup steps for Document that are defined by this specification or any other relevant specifications.

  6. If this algorithm was invoked by another instance of the "unload a document" algorithm (i.e. through the steps below that invoke this algorithm for all descendant browsing contexts), then abort these steps here.

  7. Let descendants be the list of the descendant browsing contexts of the Document.

  8. If descendants is not an empty list, then for each browsing context b in descendants run the following substeps:

    1. Unload the active document of the browsing context b with the recycle parameter set to false.

    2. If salvageable state of the active document of the browsing context b is false, then set the salvageable state of this document to false also.

  9. If salvageable and recycle are both false, then the Document's browsing context must discard the Document.

This specification defines the following unloading document cleanup steps. Other specifications can define more.

  1. If there are any outstanding transactions that have callbacks that involve scripts whose global object is the Document's Window object, roll them back (without invoking any of the callbacks) and set the Document's salvageable state to false. [WEBSQL]

  2. Close the WebSocket connection of any WebSocket objects that were created by the WebSocket() constructor visible on the Document's Window object. If this affected any WebSocket objects, the set Document's salvageable state to false.

  3. If the Document's salvageable state is false, empty the Document's Window's list of active timeouts and its list of active intervals.

6.5.10.1 Event definition
interface BeforeUnloadEvent : Event {
           attribute DOMString returnValue;
};
event . returnValue [ = value ]

Returns the current return value of the event (the message to show the user).

Can be set, to update the message.

There are no BeforeUnloadEvent-specific initialization methods.

The returnValue attribute represents the message to show the user. When the event is created, the attribute must be set to the empty string. On getting, it must return the last value it was set to. On setting, the attribute must be set to the new value.

6.5.11 Aborting a document load

If the user cancels any instance of the fetching algorithm in the context of a Document in a browsing context, then, if that Document is an active document, the user agent must queue a task to fire a simple event named abort at that Document's Window object.

6.6 Offline Web applications

6.6.1 Introduction

This section is non-normative.

In order to enable users to continue interacting with Web applications and documents even when their network connection is unavailable — for instance, because they are traveling outside of their ISP's coverage area — authors can provide a manifest which lists the files that are needed for the Web application to work offline and which causes the user's browser to keep a copy of the files for use offline.

To illustrate this, consider a simple clock applet consisting of an HTML page "clock.html", a CSS style sheet "clock.css", and a JavaScript script "clock.js".

Before adding the manifest, these three files might look like this:

<!-- clock.html -->
<!DOCTYPE HTML>
<html>
 <head>
  <title>Clock</title>
  <script src="clock.js"></script>
  <link rel="stylesheet" href="clock.css">
 </head>
 <body>
  <p>The time is: <output id="clock"></output></p>
 </body>
</html>
/* clock.css */
output { font: 2em sans-serif; }
/* clock.js */
setTimeout(function () {
    document.getElementById('clock').value = new Date();
}, 1000);

If the user tries to open the "clock.html" page while offline, though, the user agent (unless it happens to have it still in the local cache) will fail with an error.

The author can instead provide a manifest of the three files:

CACHE MANIFEST
clock.html
clock.css
clock.js

With a small change to the HTML file, the manifest (served as text/cache-manifest) is linked to the application:

<!-- clock.html -->
<!DOCTYPE HTML>
<html manifest="clock.manifest">
 <head>
  <title>Clock</title>
  <script src="clock.js"></script>
  <link rel="stylesheet" href="clock.css">
 </head>
 <body>
  <p>The time is: <output id="clock"></output></p>
 </body>
</html>

Now, if the user goes to the page, the browser will cache the files and make them available even when the user is offline.

Authors are encouraged to include the main page in the manifest also, but in practice the page that referenced the manifest is automatically cached even if it isn't explicitly mentioned.

HTTP cache headers and restrictions on caching pages served over TLS (encrypted, using https:) are overridden by manifests. Thus, pages will not expire from an application cache before the user agent has updated it, and even applications served over TLS can be made to work offline.

6.6.1.1 Event summary

This section is non-normative.

When the user visits a page that declares a manifest, the browser will try to update the cache. It does this by fetching a copy of the manifest and, if the manifest has changed since the user agent last saw it, redownloading all the resources it mentions and caching them anew.

As this is going on, a number of events get fired on the ApplicationCache object to keep the script updated as to the state of the cache update, so that the user can be notified appropriately. The events are as follows:

Event name Interface Dispatched when... Next events
checking Event The user agent is checking for an update, or attempting to download the manifest for the first time. This is always the first event in the sequence. noupdate, downloading, obsolete, error
noupdate Event The manifest hadn't changed. Last event in sequence.
downloading Event The user agent has found an update and is fetching it, or is downloading the resources listed by the manifest for the first time. progress, error, cached, updateready
progress ProgressEvent The user agent is downloading resources listed by the manifest. progress, error, cached, updateready
cached Event The resources listed in the manifest have been downloaded, and the application is now cached. Last event in sequence.
updateready Event The resources listed in the manifest have been newly redownloaded, and the script can use swapCache() to switch to the new cache. Last event in sequence.
obsolete Event The manifest was found to have become a 404 or 410 page, so the application cache is being deleted. Last event in sequence.
error Event The manifest was a 404 or 410 page, so the attempt to cache the application has been aborted. Last event in sequence.
The manifest hadn't changed, but the page referencing the manifest failed to download properly.
A fatal error occurred while fetching the resources listed in the manifest.
The manifest changed while the update was being run. The user agent will try fetching the files again momentarily.

6.6.2 Application caches

An application cache is a set of cached resources consisting of:

Each application cache has a completeness flag, which is either complete or incomplete.


An application cache group is a group of application caches, identified by the absolute URL of a resource manifest which is used to populate the caches in the group.

An application cache is newer than another if it was created after the other (in other words, application caches in an application cache group have a chronological order).

Only the newest application cache in an application cache group can have its completeness flag set to incomplete; the others are always all complete.

Each application cache group has an update status, which is one of the following: idle, checking, downloading.

A relevant application cache is an application cache that is the newest in its group to be complete.

Each application cache group has a list of pending master entries. Each entry in this list consists of a resource and a corresponding Document object. It is used during the application cache download process to ensure that new master entries are cached even if the application cache download process was already running for their application cache group when they were loaded.

An application cache group can be marked as obsolete, meaning that it must be ignored when looking at what application cache groups exist.


A cache host is a Document or a SharedWorkerGlobalScope object. A cache host can be associated with an application cache.

A Document initially is not associated with an application cache, but can become associated with one early during the page load process, when steps in the parser and in the navigation sections cause cache selection to occur.

A SharedWorkerGlobalScope can be associated with an application cache when it is created.

Each cache host has an associated ApplicationCache object.


Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following:


A URL matches a fallback namespace if there exists a relevant application cache whose manifest's URL has the same origin as the URL in question, and that has a fallback namespace that is a prefix match for the URL being examined. If multiple fallback namespaces match the same URL, the longest one is the one that matches. A URL looking for a fallback namespace can match more than one application cache at a time, but only matches one namespace in each cache.

If a manifest http://example.com/app1/manifest declares that http://example.com/resources/images is a fallback namespace, and the user navigates to HTTP://EXAMPLE.COM:80/resources/images/cat.png, then the user agent will decide that the application cache identified by http://example.com/app1/manifest contains a namespace with a match for that URL.

6.6.3 The cache manifest syntax

6.6.3.1 A sample manifest

This section is non-normative.

This example manifest requires two images and a style sheet to be cached and whitelists a CGI script.

CACHE MANIFEST
# the above line is required

# this is a comment
# there can be as many of these anywhere in the file
# they are all ignored
  # comments can have spaces before them
  # but must be alone on the line

# blank lines are ignored too

# these are files that need to be cached they can either be listed
# first, or a "CACHE:" header could be put before them, as is done
# lower down.
images/sound-icon.png
images/background.png
# note that each file has to be put on its own line

# here is a file for the online whitelist -- it isn't cached, and
# references to this file will bypass the cache, always hitting the
# network (or trying to, if the user is offline).
NETWORK:
comm.cgi

# here is another set of files to cache, this time just the CSS file.
CACHE:
style/default.css

It could equally well be written as follows:

CACHE MANIFEST
NETWORK:
comm.cgi
CACHE:
style/default.css
images/sound-icon.png
images/background.png

The following manifest defines a catch-all error page that is displayed for any page on the site while the user is offline. It also specifies that the online whitelist wildcard flag is open, meaning that accesses to resources on other sites will not be blocked. (Resources on the same site are already not blocked because of the catch-all fallback namespace.)

So long as all pages on the site reference this manifest, they will get cached locally as they are fetched, so that subsequent hits to the same page will load the page immediately from the cache. Until the manifest is changed, those pages will not be fetched from the server again. When the manifest changes, then all the files will be redownloaded.

Subresources, such as style sheets, images, etc, would only be cached using the regular HTTP caching semantics, however.

CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*
6.6.3.2 Writing cache manifests

Manifests must be served using the text/cache-manifest MIME type. All resources served using the text/cache-manifest MIME type must follow the syntax of application cache manifests, as described in this section.

An application cache manifest is a text file, whose text is encoded using UTF-8. Data in application cache manifests is line-based. Newlines must be represented by U+000A LINE FEED (LF) characters, U+000D CARRIAGE RETURN (CR) characters, or U+000D CARRIAGE RETURN (CR) U+000A LINE FEED (LF) pairs.

This is a willful violation of two aspects of RFC 2046, which requires all text/* types to support an open-ended set of character encodings and only allows CRLF line breaks. These requirements, however, are outdated; UTF-8 is now widely used, such that supporting other encodings is no longer necessary, and use of CR, LF, and CRLF line breaks is commonly supported and indeed sometimes CRLF is not supported by text editors. [RFC2046]

The first line of an application cache manifest must consist of the string "CACHE", a single U+0020 SPACE character, the string "MANIFEST", and either a U+0020 SPACE character, a U+0009 CHARACTER TABULATION (tab) character, a U+000A LINE FEED (LF) character, or a U+000D CARRIAGE RETURN (CR) character. The first line may optionally be preceded by a U+FEFF BYTE ORDER MARK (BOM) character. If any other text is found on the first line, it is ignored.

Subsequent lines, if any, must all be one of the following:

A blank line

Blank lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters only.

A comment

Comment lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, followed by a single U+0023 NUMBER SIGN character (#), followed by zero or more characters other than U+000A LINE FEED (LF) and U+000D CARRIAGE RETURN (CR) characters.

Comments must be on a line on their own. If they were to be included on a line with a URL, the "#" would be mistaken for part of a fragment identifier.

A section header

Section headers change the current section. There are three possible section headers:

CACHE:
Switches to the explicit section.
FALLBACK:
Switches to the fallback section.
NETWORK:
Switches to the online whitelist section.

Section header lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, followed by one of the names above (including the U+003A COLON character (:)) followed by zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.

Ironically, by default, the current section is the explicit section.

Data for the current section

The format that data lines must take depends on the current section.

When the current section is the explicit section, data lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, a valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.

When the current section is the fallback section, data lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, a valid URL identifying a resource other than the manifest itself, one or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, another valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.

When the current section is the online whitelist section, data lines must consist of zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters, either a single U+002A ASTERISK character (*) or a valid URL identifying a resource other than the manifest itself, and then zero or more U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters.

Manifests may contain sections more than once. Sections may be empty.

If the manifest's <scheme> is https: or another scheme intended for encrypted data transfer, then all URLs in explicit sections must have the same origin as the manifest itself.

URLs that are to be fallback pages associated with fallback namespaces, and those namespaces themselves, must be given in fallback sections, with the namespace being the first URL of the data line, and the corresponding fallback page being the second URL. All the other pages to be cached must be listed in explicit sections.

Fallback namespaces and fallback entries must have the same origin as the manifest itself.

A fallback namespace must not be listed more than once.

Namespaces that the user agent is to put into the online whitelist must all be specified in online whitelist sections. (This is needed for any URL that the page is intending to use to communicate back to the server.) To specify that all URLs are automatically whitelisted in this way, a U+002A ASTERISK character character (*) may be specified as one of the URLs.

Authors should not include namespaces in the online whitelist for which another namespace in the online whitelist is a prefix match.

Relative URLs must be given relative to the manifest's own URL. All URLs in the manifest must have the same <scheme> as the manifest itself (either explicitly or implicitly, through the use of relative URLs).

URLs in manifests must not have fragment identifiers (i.e. the U+0023 NUMBER SIGN character isn't allowed in URLs in manifests).

Fallback namespaces and namespaces in the online whitelist are matched by prefix match.

6.6.3.3 Parsing cache manifests

When a user agent is to parse a manifest, it means that the user agent must run the following steps:

  1. The user agent must decode the byte stream corresponding with the manifest to be parsed, treating it as UTF-8. Bytes or sequences of bytes that are not valid UTF-8 sequences must be interpreted as a U+FFFD REPLACEMENT CHARACTER.

  2. Let base URL be the absolute URL representing the manifest.

  3. Let explicit URLs be an initially empty list of absolute URLs for explicit entries.

  4. Let fallback URLs be an initially empty mapping of fallback namespaces to absolute URLs for fallback entries.

  5. Let online whitelist namespaces be an initially empty list of absolute URLs for an online whitelist.

  6. Let online whitelist wildcard flag be blocking.

  7. Let input be the decoded text of the manifest's byte stream.

  8. Let position be a pointer into input, initially pointing at the first character.

  9. If position is pointing at a U+FEFF BYTE ORDER MARK (BOM) character, then advance position to the next character.

  10. If the characters starting from position are "CACHE", followed by a U+0020 SPACE character, followed by "MANIFEST", then advance position to the next character after those. Otherwise, this isn't a cache manifest; abort this algorithm with a failure while checking for the magic signature.

  11. If the character at position is neither a U+0020 SPACE character, a U+0009 CHARACTER TABULATION (tab) character, U+000A LINE FEED (LF) character, nor a U+000D CARRIAGE RETURN (CR) character, then this isn't a cache manifest; abort this algorithm with a failure while checking for the magic signature.

  12. This is a cache manifest. The algorithm cannot fail beyond this point (though bogus lines can get ignored).

  13. Collect a sequence of characters that are not U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters, and ignore those characters. (Extra text on the first line, after the signature, is ignored.)

  14. Let mode be "explicit".

  15. Start of line: If position is past the end of input, then jump to the last step. Otherwise, collect a sequence of characters that are U+000A LINE FEED (LF), U+000D CARRIAGE RETURN (CR), U+0020 SPACE, or U+0009 CHARACTER TABULATION (tab) characters.

  16. Now, collect a sequence of characters that are not U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters, and let the result be line.

  17. Drop any trailing U+0020 SPACE and U+0009 CHARACTER TABULATION (tab) characters at the end of line.

  18. If line is the empty string, then jump back to the step labeled "start of line".

  19. If the first character in line is a U+0023 NUMBER SIGN character (#), then jump back to the step labeled "start of line".

  20. If line equals "CACHE:" (the word "CACHE" followed by a U+003A COLON character (:)), then set mode to "explicit" and jump back to the step labeled "start of line".

  21. If line equals "FALLBACK:" (the word "FALLBACK" followed by a U+003A COLON character (:)), then set mode to "fallback" and jump back to the step labeled "start of line".

  22. If line equals "NETWORK:" (the word "NETWORK" followed by a U+003A COLON character (:)), then set mode to "online whitelist" and jump back to the step labeled "start of line".

  23. If line ends with a U+003A COLON character (:), then set mode to "unknown" and jump back to the step labeled "start of line".

  24. This is either a data line or it is syntactically incorrect.

  25. Let position be a pointer into line, initially pointing at the start of the string.

  26. Let tokens be a list of strings, initially empty.

  27. While position doesn't point past the end of line:

    1. Let current token be an empty string.

    2. While position doesn't point past the end of line and the character at position is neither a U+0020 SPACE nor a U+0009 CHARACTER TABULATION (tab) character, add the character at position to current token and advance position to the next character in input.

    3. Add current token to the tokens list.

    4. While position doesn't point past the end of line and the character at position is either a U+0020 SPACE or a U+0009 CHARACTER TABULATION (tab) character, advance position to the next character in input.

  28. Process tokens as follows:

    If mode is "explicit"

    Resolve the first item in tokens, relative to base URL; ignore the rest.

    If this fails, then jump back to the step labeled "start of line".

    If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line". If the manifest's <scheme> is https: or another scheme intended for encrypted data transfer, and the resulting absolute URL does not have the same origin as the manifest's URL, then jump back to the step labeled "start of line".

    Drop the <fragment> component of the resulting absolute URL, if it has one.

    Add the resulting absolute URL to the explicit URLs.

    If mode is "fallback"

    Let part one be the first token in tokens, and let part two be the second token in tokens.

    Resolve part one and part two, relative to base URL.

    If either fails, then jump back to the step labeled "start of line".

    If the absolute URL corresponding to either part one or part two does not have the same origin as the manifest's URL, then jump back to the step labeled "start of line".

    Drop any the <fragment> components of the resulting absolute URLs.

    If the absolute URL corresponding to part one is already in the fallback URLs mapping as a fallback namespace, then jump back to the step labeled "start of line".

    Otherwise, add the absolute URL corresponding to part one to the fallback URLs mapping as a fallback namespace, mapped to the absolute URL corresponding to part two as the fallback entry.

    If mode is "online whitelist"

    If the first item in tokens is a U+002A ASTERISK character (*), then set online whitelist wildcard flag to open and jump back to the step labeled "start of line".

    Otherwise, resolve the first item in tokens, relative to base URL; ignore the rest.

    If this fails, then jump back to the step labeled "start of line".

    If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line".

    Drop the <fragment> component of the resulting absolute URL, if it has one.

    Add the resulting absolute URL to the online whitelist namespaces.

    If mode is "unknown"

    Do nothing. The line is ignored.

  29. Jump back to the step labeled "start of line". (That step jumps to the next, and last, step when the end of the file is reached.)

  30. Return the explicit URLs list, the fallback URLs mapping, the online whitelist namespaces, and the online whitelist wildcard flag.

If a resource is listed in the explicit section or as a fallback entry in the fallback section, the resource will always be taken from the cache, regardless of any other matching entries in the fallback namespaces or online whitelist namespaces.

When a fallback namespace and an online whitelist namespace overlap, the online whitelist namespace has priority.

The online whitelist wildcard flag is applied last, only for URLs that match neither the online whitelist namespace nor the fallback namespace and that are not listed in the explicit section.

6.6.4 Downloading or updating an application cache

When the user agent is required (by other parts of this specification) to start the application cache download process for an absolute URL purported to identify a manifest, or for an application cache group, potentially given a particular cache host, and potentially given a master resource, the user agent must run the steps below. These steps are always run asynchronously, in parallel with the event loop tasks.

Some of these steps have requirements that only apply if the user agent shows caching progress. Support for this is optional. Caching progress UI could consist of a progress bar or message panel in the user agent's interface, or an overlay, or something else. Certain events fired during the application cache download process allow the script to override the display of such an interface. The goal of this is to allow Web applications to provide more seamless update mechanisms, hiding from the user the mechanics of the application cache mechanism. User agents may display user interfaces independent of this, but are encouraged to not show prominent update progress notifications for applications that cancel the relevant events.

These events are delayed until after the load event has fired.

The application cache download process steps are as follows:

  1. Optionally, wait until the permission to start the application cache download process has been obtained from the user and until the user agent is confident that the network is available. This could include doing nothing until the user explicitly opts-in to caching the site, or could involve prompting the user for permission. The algorithm might never get past this point. (This step is particularly intended to be used by user agents running on severely space-constrained devices or in highly privacy-sensitive environments).

  2. Atomically, so as to avoid race conditions, perform the following substeps:

    1. Pick the appropriate substeps:

      If these steps were invoked with an absolute URL purported to identify a manifest

      Let manifest URL be that absolute URL.

      If there is no application cache group identified by manifest URL, then create a new application cache group identified by manifest URL. Initially, it has no application caches. One will be created later in this algorithm.

      If these steps were invoked with an application cache group

      Let manifest URL be the absolute URL of the manifest used to identify the application cache group to be updated.

    2. Let cache group be the application cache group identified by manifest URL.

    3. If these steps were invoked with a master resource, then add the resource, along with the resource's Document, to cache group's list of pending master entries.

    4. If these steps were invoked with a cache host, and the status of cache group is checking or downloading, then queue a post-load task to fire a simple event named checking that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking to see if it can download the application.

    5. If these steps were invoked with a cache host, and the status of cache group is downloading, then also queue a post-load task to fire a simple event named downloading that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user the application is being downloaded.

    6. If the status of the cache group is either checking or downloading, then abort this instance of the application cache download process, as an update is already in progress.

    7. Set the status of cache group to checking.

    8. For each cache host associated with an application cache in cache group, queue a post-load task to fire a simple event that is cancelable named checking at the ApplicationCache singleton of the cache host. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking for the availability of updates.

    The remainder of the steps run asynchronously.

    If cache group already has an application cache in it, then this is an upgrade attempt. Otherwise, this is a cache attempt.

  3. If this is a cache attempt, then this algorithm was invoked with a cache host; queue a post-load task to fire a simple event named checking that is cancelable at the ApplicationCache singleton of that cache host. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent is checking for the availability of updates.

  4. Fetching the manifest: Fetch the resource from manifest URL, and let manifest be that resource.

    If the resource is labeled with the MIME type text/cache-manifest, parse manifest according to the rules for parsing manifests, obtaining a list of explicit entries, fallback entries and the fallback namespaces that map to them, entries for the online whitelist, and a value for the online whitelist wildcard flag.

  5. If fetching the manifest fails due to a 404 or 410 response or equivalent, then run these substeps:

    1. Mark cache group as obsolete. This cache group no longer exists for any purpose other than the processing of Document objects already associated with an application cache in the cache group.

    2. Let task list be an empty list of tasks.

    3. For each cache host associated with an application cache in cache group, create a task to fire a simple event named obsolete that is cancelable at the ApplicationCache singleton of the cache host, and add it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application is no longer available for offline use.

    4. For each entry in cache group's list of pending master entries, create a task to fire a simple event that is cancelable named error (not obsolete!) at the ApplicationCache singleton of the cache host the Document for this entry, if there still is one, and add it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

    5. If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.

    6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

    7. Let the status of cache group be idle.

    8. For each task in task list, queue that task as a post-load task.

    9. Abort the application cache download process.

  6. Otherwise, if fetching the manifest fails in some other way (e.g. the server returns another 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download, or the parser for manifests fails when checking the magic signature), or if the server returned a redirect, or if the resource is labeled with a MIME type other than text/cache-manifest, then run the cache failure steps.

  7. If this is an upgrade attempt and the newly downloaded manifest is byte-for-byte identical to the manifest found in the newest application cache in cache group, or the server reported it as "304 Not Modified" or equivalent, then run these substeps:

    1. Let cache be the newest application cache in cache group.

    2. Let task list be an empty list of tasks.

    3. For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.

      If the download failed (e.g. the connection times out, or the user cancels the download), then create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the cache host the Document for this entry, if there still is one, and add it to task list. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

      Otherwise, associate the Document for this entry with cache; store the resource for this entry in cache, if it isn't already there, and categorize its entry as a master entry. If the resource's URL has a <fragment> component, it must be removed from the entry in cache (application caches never include fragment identifiers).

      HTTP caching rules, such as Cache-Control: no-store, are ignored for the purposes of the application cache download process.

    4. For each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named noupdate at the ApplicationCache singleton of the cache host, and add it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application is up to date.

    5. Empty cache group's list of pending master entries.

    6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

    7. Let the status of cache group be idle.

    8. For each task in task list, queue that task as a post-load task.

    9. Abort the application cache download process.

  8. Let new cache be a newly created application cache in cache group. Set its completeness flag to incomplete.

  9. For each entry in cache group's list of pending master entries, associate the Document for this entry with new cache.

  10. Set the status of cache group to downloading.

  11. For each cache host associated with an application cache in cache group, queue a post-load task to fire a simple event that is cancelable named downloading at the ApplicationCache singleton of the cache host. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a new version is being downloaded.

  12. Let file list be an empty list of URLs with flags.

  13. Add all the URLs in the list of explicit entries obtained by parsing manifest to file list, each flagged with "explicit entry".

  14. Add all the URLs in the list of fallback entries obtained by parsing manifest to file list, each flagged with "fallback entry".

  15. If this is an upgrade attempt, then add all the URLs of master entries in the newest application cache in cache group whose completeness flag is complete to file list, each flagged with "master entry".

  16. If any URL is in file list more than once, then merge the entries into one entry for that URL, that entry having all the flags that the original entries had.

  17. For each URL in file list, run the following steps. These steps may be run in parallel for two or more of the URLs at a time.

    1. If the resource URL being processed was flagged as neither an "explicit entry" nor or a "fallback entry", then the user agent may skip this URL.

      This is intended to allow user agents to expire resources not listed in the manifest from the cache. Generally, implementors are urged to use an approach that expires lesser-used resources first.

    2. For each cache host associated with an application cache in cache group, queue a post-load task to fire an event with the name progress, which does not bubble, which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to true, the total attribute must be set to the number of files in file list, and the loaded attribute must be set to the number of number of files in file list that have been either downloaded or skipped so far. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a file is being downloaded in preparation for updating the application. [PROGRESS]

    3. Fetch the resource, from the origin of the URL manifest URL. If this is an upgrade attempt, then use the newest application cache in cache group as an HTTP cache, and honor HTTP caching semantics (such as expiration, ETags, and so forth) with respect to that cache. User agents may also have other caches in place that are also honored.

      If the resource in question is already being downloaded for other reasons then the existing download process can sometimes be used for the purposes of this step, as defined by the fetching algorithm.

      An example of a resource that might already be being downloaded is a large image on a Web page that is being seen for the first time. The image would get downloaded to satisfy the img element on the page, as well as being listed in the cache manifest. According to the rules for fetching that image only need be downloaded once, and it can be used both for the cache and for the rendered Web page.

    4. If the previous step fails (e.g. the server returns a 4xx or 5xx response or equivalent, or there is a DNS error, or the connection times out, or the user cancels the download), or if the server returned a redirect, then run the first appropriate step from the following list:

      If the URL being processed was flagged as an "explicit entry" or a "fallback entry"

      Run the cache failure steps.

      Redirects are fatal because they are either indicative of a network problem (e.g. a captive portal); or would allow resources to be added to the cache under URLs that differ from any URL that the networking model will allow access to, leaving orphan entries; or would allow resources to be stored under URLs different than their true URLs. All of these situations are bad.

      If the error was a 404 or 410 HTTP response or equivalent

      Skip this resource. It is dropped from the cache.

      Otherwise

      Copy the resource and its metadata from the newest application cache in cache group whose completeness flag is complete, and act as if that was the fetched resource, ignoring the resource obtained from the network.

      User agents may warn the user of these errors as an aid to development.

      These rules make errors for resources listed in the manifest fatal, while making it possible for other resources to be removed from caches when they are removed from the server, without errors, and making non-manifest resources survive server-side errors.

    5. Otherwise, the fetching succeeded. Store the resource in the new cache.

    6. If the URL being processed was flagged as an "explicit entry" in file list, then categorize the entry as an explicit entry.

    7. If the URL being processed was flagged as a "fallback entry" in file list, then categorize the entry as a fallback entry.

    8. If the URL being processed was flagged as an "master entry" in file list, then categorize the entry as a master entry.

    9. As an optimization, if the resource is an HTML or XML file whose root element is an html element with a manifest attribute whose value doesn't match the manifest URL of the application cache being processed, then the user agent should mark the entry as being foreign.

  18. For each cache host associated with an application cache in cache group, queue a post-load task to fire an event with the name progress, which does not bubble, which is cancelable, and which uses the ProgressEvent interface, at the ApplicationCache singleton of the cache host. The lengthComputable attribute must be set to true, the total and the loaded attributes must be set to the number of number of files in file list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that all the files have been downloaded. [PROGRESS]

  19. Store the list of fallback namespaces, and the URLs of the fallback entries that they map to, in new cache.

  20. Store the URLs that form the new online whitelist in new cache.

  21. Store the value of the new online whitelist wildcard flag in new cache.

  22. For each entry in cache group's list of pending master entries, wait for the resource for this entry to have either completely downloaded or failed.

    If the download failed (e.g. the connection times out, or the user cancels the download), then run these substeps:

    1. Unassociate the Document for this entry from new cache.

    2. Queue a post-load task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one. The default action of this event must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

    3. If this is a cache attempt and this entry is the last entry in cache group's list of pending master entries, then run these further substeps:

      1. Discard cache group and its only application cache, new cache.

      2. If appropriate, remove any user interface indicating that an update for this cache is in progress.

      3. Abort the application cache download process.

    4. Otherwise, remove this entry from cache group's list of pending master entries.

    Otherwise, store the resource for this entry in new cache, if it isn't already there, and categorize its entry as a master entry.

  23. Fetch the resource from manifest URL again, and let second manifest be that resource.

  24. If the previous step failed for any reason, or if the fetching attempt involved a redirect, or if second manifest and manifest are not byte-for-byte identical, then schedule a rerun of the entire algorithm with the same parameters after a short delay, and run the cache failure steps.

  25. Otherwise, store manifest in new cache, if it's not there already, and categorize its entry as the manifest.

  26. Set the completeness flag of new cache to complete.

  27. Let task list be an empty list of tasks.

  28. If this is a cache attempt, then for each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named cached at the ApplicationCache singleton of the cache host, and add it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the application has been cached and that they can now use it offline.

    Otherwise, it is an upgrade attempt. For each cache host associated with an application cache in cache group, create a task to fire a simple event that is cancelable named updateready at the ApplicationCache singleton of the cache host, and add it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a new version is available and that they can activate it by reloading the page.

  29. If appropriate, remove any user interface indicating that an update for this cache is in progress.

  30. Set the update status of cache group to idle.

  31. For each task in task list, queue that task as a post-oad task.

The cache failure steps are as follows:

  1. Let task list be an empty list of tasks.

  2. For each entry in cache group's list of pending master entries, run the following further substeps. These steps may be run in parallel for two or more entries at a time.

    1. Wait for the resource for this entry to have either completely downloaded or failed.

    2. Unassociate the Document for this entry from its application cache, if it has one.

    3. Create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the Document for this entry, if there still is one, and add it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

  3. For each cache host still associated with an application cache in cache group, create a task to fire a simple event that is cancelable named error at the ApplicationCache singleton of the cache host, and add it to task list. The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that the user agent failed to save the application for offline use.

  4. Empty cache group's list of pending master entries.

  5. If cache group has an application cache whose completeness flag is incomplete, then discard that application cache.

  6. If appropriate, remove any user interface indicating that an update for this cache is in progress.

  7. Let the status of cache group be idle.

  8. If this was a cache attempt, discard cache group altogether.

  9. For each task in task list, queue that task as a post-load task.

  10. Abort the application cache download process.

Attempts to fetch resources as part of the application cache download process may be done with cache-defeating semantics, to avoid problems with stale or inconsistent intermediary caches.


User agents may invoke the application cache download process, in the background, for any application cache, at any time (with no cache host). This allows user agents to keep caches primed and to update caches even before the user visits a site.


Each Document has a list of pending application cache download process tasks that is used to delay events fired by the algorithm above until the document's load event has fired. When the Document is created, the list must be empty.

When the steps above say to queue a post-load task task, where task is a task that dispatches an event on a target ApplicationCache object target, the user agent must run the appropriate steps from the following list:

If target's Document has completely loaded

Queue the task task.

Otherwise

Add task to target's Document's list of pending application cache download process tasks.

The task source for these tasks is the networking task source.

6.6.5 The application cache selection algorithm

When the application cache selection algorithm algorithm is invoked with a Document document and optionally a manifest URL manifest URL, the user agent must run the first applicable set of steps from the following list:

If there is a manifest URL, and document was loaded from an application cache, and the URL of the manifest of that cache's application cache group is not the same as manifest URL

Mark the entry for the resource from which document was taken in the application cache from which it was loaded as foreign.

Restart the current navigation from the top of the navigation algorithm, undoing any changes that were made as part of the initial load (changes can be avoided by ensuring that the step to update the session history with the new page is only ever completed after this application cache selection algorithm is run, though this is not required).

The navigation will not result in the same resource being loaded, because "foreign" entries are never picked during navigation.

User agents may notify the user of the inconsistency between the cache manifest and the document's own metadata, to aid in application development.

If document was loaded from an application cache

Associate document with the application cache from which it was loaded. Invoke, in the background, the application cache download process for that application cache's application cache group, with document as the cache host.

If document was loaded using HTTP GET or equivalent, and, there is a manifest URL, and manifest URL has the same origin as document

Invoke, in the background, the application cache download process for manifest URL, with document as the cache host and with the resource from which document was parsed as the master resource.

Otherwise

The Document is not associated with any application cache.

If there was a manifest URL, the user agent may report to the user that it was ignored, to aid in application development.

6.6.6 Changes to the networking model

When a cache host is associated with an application cache whose completeness flag is complete, any and all loads for resources related to that cache host other than those for child browsing contexts must go through the following steps instead of immediately invoking the mechanisms appropriate to that resource's scheme:

  1. If the resource is not to be fetched using the HTTP GET mechanism or equivalent, or if its URL has a different <scheme> component than the application cache's manifest, then fetch the resource normally and abort these steps.

  2. If the resource's URL is a master entry, the manifest, an explicit entry, or a fallback entry in the application cache, then get the resource from the cache (instead of fetching it), and abort these steps.

  3. If there is an entry in the application cache's online whitelist that has the same origin as the resource's URL and that is a prefix match for the resource's URL, then fetch the resource normally and abort these steps.

  4. If the resource's URL has the same origin as the manifest's URL, and there is a fallback namespace f in the application cache that is a prefix match for the resource's URL, then:

    Fetch the resource normally. If this results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors (but not if the user canceled the download), then instead get, from the cache, the resource of the fallback entry corresponding to the fallback namespace f. Abort these steps.

  5. If the application cache's online whitelist wildcard flag is open, then fetch the resource normally and abort these steps.

  6. Fail the resource load as if there had been a generic network error.

The above algorithm ensures that so long as the online whitelist wildcard flag is blocking, resources that are not present in the manifest will always fail to load (at least, after the application cache has been primed the first time), making the testing of offline applications simpler.

6.6.7 Expiring application caches

As a general rule, user agents should not expire application caches, except on request from the user, or after having been left unused for an extended period of time.

Application caches and cookies have similar implications with respect to privacy (e.g. if the site can identify the user when providing the cache, it can store data in the cache that can be used for cookie resurrection). Implementors are therefore encouraged to expose application caches in a manner related to HTTP cookies, allowing caches to be expunged together with cookies and other origin-specific data.

For example, a user agent could have a "delete site-specific data" feature that clears all cookies, application caches, local storage, databases, etc, from an origin all at once.

6.6.8 Application cache API

interface ApplicationCache {

  // update status
  const unsigned short UNCACHED = 0;
  const unsigned short IDLE = 1;
  const unsigned short CHECKING = 2;
  const unsigned short DOWNLOADING = 3;
  const unsigned short UPDATEREADY = 4;
  const unsigned short OBSOLETE = 5;
  readonly attribute unsigned short status;

  // updates
  void update();
  void swapCache();

  // events
           attribute Function onchecking;
           attribute Function onerror;
           attribute Function onnoupdate;
           attribute Function ondownloading;
           attribute Function onprogress;
           attribute Function onupdateready;
           attribute Function oncached;
           attribute Function onobsolete;
};
ApplicationCache implements EventTarget;
cache = window . applicationCache

(In a window.) Returns the ApplicationCache object that applies to the active document of that Window.

cache = self . applicationCache

(In a shared worker.) Returns the ApplicationCache object that applies to the current shared worker.

cache . status

Returns the current status of the application cache, as given by the constants defined below.

cache . update()

Invokes the application cache download process.

Throws an INVALID_STATE_ERR exception if there is no application cache to update.

cache . swapCache()

Switches to the most recent application cache, if there is a newer one. If there isn't, throws an INVALID_STATE_ERR exception.

This does not cause previously-loaded resources to be reloaded; for example, images do not suddenly get reloaded and style sheets and scripts do not get reparsed or reevaluated. The only change is that subsequent requests for cached resources will obtain the newer copies.

There is a one-to-one mapping from cache hosts to ApplicationCache objects. The applicationCache attribute on Window objects must return the ApplicationCache object associated with the Window object's active document. The applicationCache attribute on SharedWorkerGlobalScope objects must return the ApplicationCache object associated with the worker.

A Window or SharedWorkerGlobalScope object has an associated ApplicationCache object even if that cache host has no actual application cache.


The status attribute, on getting, must return the current state of the application cache that the ApplicationCache object's cache host is associated with, if any. This must be the appropriate value from the following list:

UNCACHED (numeric value 0)

The ApplicationCache object's cache host is not associated with an application cache at this time.

IDLE (numeric value 1)

The ApplicationCache object's cache host is associated with an application cache whose application cache group's update status is idle, and that application cache is the newest cache in its application cache group, and the application cache group is not marked as obsolete.

CHECKING (numeric value 2)

The ApplicationCache object's cache host is associated with an application cache whose application cache group's update status is checking.

DOWNLOADING (numeric value 3)

The ApplicationCache object's cache host is associated with an application cache whose application cache group's update status is downloading.

UPDATEREADY (numeric value 4)

The ApplicationCache object's cache host is associated with an application cache whose application cache group's update status is idle, and whose application cache group is not marked as obsolete, but that application cache is not the newest cache in its group.

OBSOLETE (numeric value 5)

The ApplicationCache object's cache host is associated with an application cache whose application cache group is marked as obsolete.


If the update() method is invoked, the user agent must invoke the application cache download process, in the background, for the application cache with which the ApplicationCache object's cache host is associated, but without giving that cache host to the algorithm. If there is no such application cache, or if it is marked as obsolete, then the method must raise an INVALID_STATE_ERR exception instead.

If the swapCache() method is invoked, the user agent must run the following steps:

  1. Check that ApplicationCache object's cache host is associated with an application cache. If it is not, then raise an INVALID_STATE_ERR exception and abort these steps.

  2. Let cache be the application cache with which the ApplicationCache object's cache host is associated. (By definition, this is the same as the one that was found in the previous step.)

  3. If cache's application cache group is marked as obsolete, then unassociate the ApplicationCache object's cache host from cache and abort these steps. (Resources will now load from the network instead of the cache.)

  4. Check that there is an application cache in the same application cache group as cache whose completeness flag is complete and that is newer than cache. If there is not, then raise an INVALID_STATE_ERR exception and abort these steps.

  5. Let new cache be the newest application cache in the same application cache group as cache whose completeness flag is complete.

  6. Unassociate the ApplicationCache object's cache host from cache and instead associate it with new cache.

The following are the event handlers (and their corresponding event handler event types) that must be supported, as IDL attributes, by all objects implementing the ApplicationCache interface:

Event handler Event handler event type
onchecking checking
onerror error
onnoupdate noupdate
ondownloading downloading
onprogress progress
onupdateready updateready
oncached cached
onobsolete obsolete

6.6.9 Browser state

window . navigator . onLine

Returns false if the user agent is definitely offline (disconnected from the network). Returns true if the user agent might be online.

The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page (or knows that such an attempt would fail), and must return true otherwise.

When the value that would be returned by the navigator.onLine attribute of the Window changes from true to false, the user agent must queue a task to fire a simple event named offline at the Window object.

On the other hand, when the value that would be returned by the navigator.onLine attribute of the Window changes from false to true, the user agent must queue a task to fire a simple event named online at the Window object.

The task source for these tasks is the networking task source.

This attribute is inherently unreliable. A computer can be connected to a network without having Internet access.

7 Web application APIs

7.1 Scripting

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

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

7.1.3 Processing model

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

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

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

A 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 WindowProxy object.

A relationship with the script's document

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

When a script fetches a resource, the current address of the script's document will be used to set the Referer (sic) header.

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

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

  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 entry 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 entry script back to whatever it was when this algorithm started.

This algorithm is not invoked by one script calling another.

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

  1. If scripting is disabled for browsing context passed to this algorithm, then abort these steps, as if the script did nothing but return void.

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

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

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

  5. 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 URL 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 URL 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.)

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

7.1.4 Event loops

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

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.

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

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.

Each task that is queued onto a task queue of an event loop defined by this specification 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 document.

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.

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

7.1.4.2 Processing model

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. If the storage mutex is now owned by the event loop, release it so that it is once again free.

  3. Remove that task from its task queue.

  4. If any asynchronously-running algorithms are awaiting a stable state, then run their synchronous section and then resume running their asynchronous algorithm.

    A synchronous section never mutates the DOM, runs any script, or has any other side-effects.

    Steps in synchronous sections are marked with ⌛.

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

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


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

  1. Let task source be the task source of the currently running task.

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

  3. Wait until the condition goal is met.

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

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

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

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

  3. Take ownership of the storage mutex.

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

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.

The history traversal task source

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

7.1.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. (The result will be void also if scripting is disabled.)

    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. (The result will be void also if scripting is disabled.)

    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.

7.1.6 Events

7.1.6.1 Event handlers

Many objects can have event handlers specified. These act as bubbling event listeners for the object on which they are specified.

An event handler can either have the value null or be set to a Function object. Initially, event handlers must be set to null.

Event handlers are exposed in one or two ways.

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

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


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

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

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

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


Event handler content attributes, when specified, must contain valid JavaScript code matching the 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, and scripting is enabled for that 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, create a function object (as defined in ECMAScript edition 5 section 13.2 Creating Function Objects), with:

    Parameter list FormalParameterList
    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.
    Function body FunctionBody
    The event handler content attribute's new value.
    Lexical Environment Scope
    1. Let Scope be the result of NewObjectEnvironment(the element's Document, the global environment).
    2. If the element has a form owner, let Scope be the result of NewObjectEnvironment(the element's form owner, Scope).
    3. Let Scope be the result of NewObjectEnvironment(the element's object, Scope).

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

    Boolean flag Strict
    False.

    Let this new function be the only entry in the script's list of code entry-points.

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

  4. Set up the script's global object, the script's browsing context, the script's document, the script's URL 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 to the aforementioned function.

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

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 is not changed.


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.

Event handlers therefore always fire before event listeners attached using addEventListener().

The listener argument is emphatically not the event handler itself.

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

When an event handler's Function object 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(in any... arguments);
};

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

In JavaScript, any Function object implements this interface.

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

7.1.6.2 Event handlers on elements, Document objects, and Window objects

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

Event handler Event handler event type
onabort abort
oncanplay canplay
oncanplaythrough canplaythrough
onchange change
onclick click
oncontextmenu contextmenu
ondblclick dblclick
ondrag drag
ondragend dragend
ondragenter dragenter
ondragleave dragleave
ondragover dragover
ondragstart dragstart
ondrop drop
ondurationchange durationchange
onemptied emptied
onended ended
onformchange formchange
onforminput forminput
oninput input
oninvalid invalid
onkeydown keydown
onkeypress keypress
onkeyup keyup
onloadeddata loadeddata
onloadedmetadata loadedmetadata
onloadstart loadstart
onmousedown mousedown
onmousemove mousemove
onmouseout mouseout
onmouseover mouseover
onmouseup mouseup
onmousewheel mousewheel
onpause pause
onplay play
onplaying playing
onprogress progress
onratechange ratechange
onreadystatechange readystatechange
onscroll scroll
onseeked seeked
onseeking seeking
onselect select
onshow show
onstalled stalled
onsubmit submit
onsuspend suspend
ontimeupdate timeupdate
onvolumechange volumechange
onwaiting waiting

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

Event handler Event handler event type
onblur blur
onerror error
onfocus focus
onload load

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

Event handler Event handler event type
onafterprint afterprint
onbeforeprint beforeprint
onbeforeunload beforeunload
onblur blur
onerror error
onfocus focus
onhashchange hashchange
onload load
onmessage message
onoffline offline
ononline online
onpagehide pagehide
onpageshow pageshow
onpopstate popstate
onredo redo
onresize resize
onstorage storage
onundo undo
onunload unload

The onerror handler is also used for reporting script errors.

7.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 click event means that a click event, 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 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.

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

7.1.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 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.
  2. 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.
7.1.6.5 Runtime script errors

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

Whenever an uncaught 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 of the script's global object. If the error is still not handled after this, then the error may be reported to the user.


When the user agent is required to report an error error using the event handler 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 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.

Otherwise

The error is not handled.

7.2 Timers

The setTimeout() and setInterval() methods allow authors to schedule timer-based callbacks.

[Supplemental, NoInterfaceObject]
interface WindowTimers {
  long setTimeout(in any handler, in optional any timeout, in any... args);
  void clearTimeout(in long handle);
  long setInterval(in any handler, in optional any timeout, in any... args);
  void clearInterval(in long handle);
};
Window implements WindowTimers;
handle = window . setTimeout( handler [, timeout [, arguments ] ] )

Schedules a timeout to run handler after timeout milliseconds. Any arguments are passed straight through to the handler.

handle = window . setTimeout( code [, timeout ] )

Schedules a timeout to compile and run code after timeout milliseconds.

window . clearTimeout( handle )

Cancels the timeout set with setTimeout() identified by handle.

handle = window . setInterval( handler [, timeout [, arguments ] ] )

Schedules a timeout to run handler every timeout milliseconds. Any arguments are passed straight through to the handler.

handle = window . setInterval( code [, timeout ] )

Schedules a timeout to compile and run code every timeout milliseconds.

window . clearInterval( handle )

Cancels the timeout set with setInterval() identified by handle.

This API does not guarantee that timers will fire exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected.

The WindowTimers interface adds to the Window interface and the WorkerUtils interface (part of Web Workers).

Each object that implements the WindowTimers interface has a list of active timeouts and a list of active intervals. Each entry in these lists is identified by a number, which must be unique within its list for the lifetime of the object that implements the WindowTimers interface.


The setTimeout() method must run the following steps:

  1. Let handle be a user-agent-defined integer that is greater than zero that will identify the timeout to be set by this call.

  2. Add an entry to the list of active timeouts for handle.

  3. Get the timed task handle in the list of active timeouts, and let task be the result.

  4. Get the timeout, and let timeout be the result.

  5. If the currently running task is a task that was created by the setTimeout() method, and timeout is less than 4, then increase timeout to 4.

  6. Return handle, and then continue running this algorithm asynchronously.

  7. If the method context is a Window object, wait until the Document associated with the method context has been fully active for a further timeout milliseconds (not necessarily consecutively).

    Otherwise, if the method context is a WorkerUtils object, wait until timeout milliseconds have passed with the worker not suspended (not necessarily consecutively).

    Otherwise, act as described in the specification that defines that the WindowTimers interface is implemented by some other object.

  8. Wait until any invocations of this algorithm started before this one whose timeout is equal to or less than this one's have completed.

  9. Queue the task task.

The clearTimeout() method must clear the entry identified as handle from the list of active timeouts of the WindowTimers object on which the method was invoked, where handle is the argument passed to the method.


The setInterval() method must run the following steps:

  1. Let handle be a user-agent-defined integer that is greater than zero that will identify the interval to be set by this call.

  2. Add an entry to the list of active intervals for handle.

  3. Get the timed task handle in the list of active intervals, and let task be the result.

  4. Get the timeout, and let timeout be the result.

  5. If timeout is less than 10, then increase timeout to 10.

  6. Return handle, and then continue running this algorithm asynchronously.

  7. Wait: If the method context is a Window object, wait until the Document associated with the method context has been fully active for a further interval milliseconds (not necessarily consecutively).

    Otherwise, if the method context is a WorkerUtils object, wait until interval milliseconds have passed with the worker not suspended (not necessarily consecutively).

    Otherwise, act as described in the specification that defines that the WindowTimers interface is implemented by some other object.

  8. Queue the task task.

  9. Return to the step labeled wait.

The clearInterval() method must clear the entry identified as handle from the list of active intervals of the WindowTimers object on which the method was invoked, where handle is the argument passed to the method.


The method context, when referenced by the algorithms in this section, is the object on which the method for which the algorithm is running is implemented (a Window or WorkerUtils object).

When the above methods are invoked and try to get the timed task handle in list list, they must run the following steps:

  1. If the first argument to the invoked method is an object that has an internal [[Call]] method, then return a task that checks if the entry for handle in list has been cleared, and if it has not, calls the aforementioned [[Call]] method with as its arguments the third and subsequent arguments to the invoked method (if any), and abort these steps.

    Otherwise, continue with the remaining steps.

  2. Apply the ToString() abstract operation to the first argument to the method, and let script source be the result. [ECMA262]

  3. Let script language be JavaScript.

  4. If the method context is a Window object, let global object be the method context, let browsing context be the browsing context with which global object is associated, let character encoding be the character encoding of the Document associated with global object (this is a reference, not a copy), and let base URL be the base URL of the Document associated with global object (this is a reference, not a copy).

    Otherwise, if the method context is a WorkerUtils object, let global object, browsing context, document, character encoding, and base URL be the script's global object, script's browsing context, script's document, script's URL character encoding, and script's base URL (respectively) of the script that the run a worker algorithm created when it created the method context.

    Otherwise, act as described in the specification that defines that the WindowTimers interface is implemented by some other object.

  5. Return a task that checks if the entry for handle in list has been cleared, and if it has not, creates a script using script source as the script source, scripting language as the scripting language, global object as the global object, browsing context as the browsing context, document as the document, character encoding as the URL character encoding, and base URL as the base URL.

When the above methods are to get the timeout, they must run the following steps:

  1. Let timeout be the second argument to the method, or zero if the argument was omitted.

  2. Apply the ToString() abstract operation to timeout, and let timeout be the result. [ECMA262]

  3. Apply the ToNumber() abstract operation to timeout, and let timeout be the result. [ECMA262]

  4. If timeout is an Infinity value, a Not-a-Number (NaN) value, or negative, let timeout be zero.

  5. Round timeout down to the nearest integer, and let timeout be the result.

  6. Return timeout.


The task source for these tasks is the timer task source.

7.3 User prompts

7.3.1 Simple dialogs

window . alert(message)

Displays a modal alert with the given message, and waits for the user to dismiss it.

A call to the navigator.yieldForStorageUpdates() method is implied when this method is invoked.

result = window . confirm(message)

Displays a modal OK/Cancel prompt with the given message, waits for the user to dismiss it, and returns true if the user clicks OK and false if the user clicks Cancel.

A call to the navigator.yieldForStorageUpdates() method is implied when this method is invoked.

result = window . prompt(message [, default] )

Displays a modal text field prompt with the given message, waits for the user to dismiss it, and returns the value that the user entered. If the user cancels the prompt, then returns null instead. If the second argument is present, then the given value is used as a default.

A call to the navigator.yieldForStorageUpdates() method is implied when this method is invoked.

The alert(message) method, when invoked, must release the storage mutex and 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 release the storage mutex and 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 release the storage mutex, 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.

7.3.2 Printing

window . print()

Prompts the user to print the page.

A call to the navigator.yieldForStorageUpdates() method is implied when this method is invoked.

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 named 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 must release the storage mutex.

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

  5. The user agent must fire a simple event named 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.

7.3.3 Dialogs implemented using separate documents

result = window . showModalDialog(url [, argument] )

Prompts the user with the given page, waits for that page to close, and returns the return value.

A call to the navigator.yieldForStorageUpdates() method is implied when this method is invoked.

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

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

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

  2. Release the storage mutex.

  3. If the user agent is configured such that this invocation of showModalDialog() is somehow disabled, then return the empty string and 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.

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

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

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

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

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

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

  10. Spin the event loop until the new browsing context is closed. (The user agent must allow the user to indicate that the browsing context is to be closed.)

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

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

The Window objects of Documents hosted by browsing contexts created by the above algorithm must all have the WindowModal interface added to their Window interface:

[Supplemental, NoInterfaceObject] interface WindowModal {
  readonly attribute any dialogArguments;
           attribute DOMString returnValue;
};
window . dialogArguments

Returns the argument argument that was passed to the showModalDialog() method.

window . returnValue [ = value ]

Returns the current return value for the window.

Can be set, to change the value that will be returned by the showModalDialog() method.

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

7.4 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
};
Navigator implements NavigatorID;
Navigator implements NavigatorOnLine;
Navigator implements NavigatorAbilities;

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

[Supplemental, NoInterfaceObject]
interface NavigatorOnLine {
  readonly attribute boolean onLine;
};

[Supplemental, NoInterfaceObject]
interface NavigatorAbilities {
  // content handler registration
  void registerProtocolHandler(in DOMString scheme, in DOMString url, in DOMString title);
  void registerContentHandler(in DOMString mimeType, in DOMString url, in DOMString title);
  void yieldForStorageUpdates();
};

These interfaces are defined separately so that other specifications can re-use parts of the Navigator interface.

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

window . navigator . appName

Returns the name of the browser.

window . navigator . appVersion

Returns the version of the browser.

window . navigator . platform

Returns the name of the platform.

window . navigator . userAgent

Returns the complete User-Agent header.

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.

7.4.2 Custom scheme and content handlers

The registerProtocolHandler() method allows Web sites to register themselves as possible handlers for particular schemes. For example, an online telephone messaging service could register itself as a handler of the sms: scheme ([RFC5724]), 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 telephone messaging service could register itself as a handler for text/directory files ([RFC2425]), so that if the user has no native application capable of handling vCards ([RFC2426]), his Web browser can instead suggest he use that site to view contact information stored on vCards that he opens.