WebDriver

Various parts of this specification are written in terms of step-by-step algorithms. The details of these algorithms do not have any normative significance; implementations are free to adopt any implementation strategy that produces equivalent output to the specification. In particular, algorithms in this document are optimized for readability rather than performance.

Where algorithms that return values are fallible, they are written in terms of returning either success or error. A success value has an associated data field which encapsulates the value returned, whereas an error value has an associated error code.

When calling a fallible algorithm, the construct “Let result be the result of trying to call algorithm” is equivalent to

1. Let temp be the result of calling algorithm.

2. If temp is an error return temp, otherwise let result be temp's data field.

The result of getting a property with name from object is defined as being the same as the result of calling Object.[[GetOwnProperty]](name) on object.

The result of getting a property with default with arguments name and default from object is defined as being the same as the result of calling Object.[[GetOwnProperty]](name) on object if that results in a value other than undefined and default otherwise.

Setting a property with arguments name and value on object is defined as being the same as calling Object.[[Put]](name, value) on object.

The result of JSON serialization with object of type JSON Object is defined as the result of calling stringify(object).

The result of JSON deserialization with text is defined as the result of calling parse(text).

The WebDriver protocol is organized into commands. Each HTTP request with a method and template defined in this specification represents a single command, and therefore each command produces a single HTTP response.

In response to a command, a remote end will run a series of actions known as remote end steps. These provide the sequences of actions that a remote end takes when it receives a particular command.

The remote end is an HTTP server reading requests from the client and writing responses, typically over a TCP socket. For the purposes of this specification we model the data transmission between a particular local end and remote end with a connection to which the remote end may write bytes and read bytes. However the exact details of how this connection works and how it is established are out of scope.

After a connection is established, the remote end must run the following steps:

1. While the connection is not closed:

   1. Read bytes from the connection until a complete HTTP request can be constructed from the data. Let request be a request constructed from the received data, according to the requirements of [RFC7230]. If it is not possible to construct a complete HTTP request, the remote end must either close the connection, return an HTTP response with status code 500, or return an error with error code unknown error.

   2. Let request match be the result of the algorithm to match a request with request's method and URL as arguments.

   3. If request match is of type error, send an error with request match's error code and continue.

      Otherwise, let command and URL variables be request match's data.

   4. Let session be null.

   5. If URL variables contains "session id":

      Note

      This condition is intended to exclude the New Session and Status commands and any extension commands which do not operate on a particular session.

      1. Let session id be URL variables["session id"].

      2. For each active session in the list of active sessions:

         1. If active session's session ID is equal to session id, then let session be active session, and break.

      3. If the session is null send an error with error code invalid session id, then continue.

   6. Enqueue a task on remote end's request queue to run the following steps:

      1. If session is no longer in the list of active sessions, then send an error with error code invalid session id and return.

      2. Let parameters be null.

      3. If request's method is POST:

         1. Let parse result be the result of parsing as JSON with request's body as the argument. If this process throws an exception, return an error with error code invalid argument and jump back to step 1 in this overall algorithm.

         2. If parse result is not an Object, send an error with error code invalid argument and jump back to step 1 in this overall algorithm.

            Otherwise, let parameters be parse result.

      4. Let navigate result be the result of wait for navigation to complete with session.

      5. If navigate result is an error, send an error with error code equal to navigate result's error code and return.

      6. Let response result be the return value obtained by running the remote end steps for command with session, URL variables, and parameters.

      7. If response result is an error, send an error with error code equal to response result's error code and return.

      8. Assert: response result is a success.

      9. Let response data be response result's data.

      10. Send a response with status 200 and response data.

When required to send an error, with error code and an optional error data dictionary, a remote end must run the following steps:

1. Let status and name be the error response data for error code.

2. Let message be an implementation-defined string containing a human-readable description of the reason for the error.

3. Let stacktrace be an implementation-defined string containing a stack trace report of the active stack frames at the time when the error occurred.

   Let body be a new JSON Object initialized with the following properties:

   "error"

   name

   "message"

   message

   "stacktrace"

   stacktrace

4. If the error data dictionary contains any entries, set the "data" field on body to a new JSON Object populated with the dictionary.

5. Send a response with status and body as arguments.

When required to send a response, with arguments status and data, a remote end must run the following steps:

1. Let response be a new response.

2. Set response's HTTP status to status, and status message to the string corresponding to the description of status in the status code registry.

3. Set the response's header with name and value with the following values:

   Content-Type

   "application/json; charset=utf-8"

   Cache-Control

   "no-cache"

4. Let response's body be the UTF-8 encoded JSON serialization of a JSON Object with a key "value" set to data.

5. Let response bytes be the byte sequence resulting from serializing response according to the rules in [RFC7230].

6. Write response bytes to the connection.

Request routing is the process of going from an HTTP request to the series of steps needed to implement the command represented by that request.

A remote end has an associated URL prefix, which is used as a prefix on all WebDriver-defined URLs on that remote end. This must either be undefined or a path-absolute URL.

In order to match a request given a method and URL, the following steps must be taken:

1. Let endpoints be a list containing each row in the table of endpoints.

2. Remove each entry from endpoints for which the concatenation of the URL prefix and the entry's URI template does not have a valid expansion equal to URL's path.

3. If there are no entries in endpoints, return error with error code unknown command.

4. Remove each entry in endpoints for which the method column is not equal to method.

5. If there are no entries in endpoints, return error with error code unknown method.

6. There is now exactly one entry in endpoints; let entry be this entry.

7. Let URI template be the concatenation of URL prefix with entry's URI template.

8. Let command be entry's command.

9. Let URL variables be a map with one entry for each variable defined in URI template, with the entry name equal to the template variable name, and the entry value being the variable value required to expand the URI template to match URL's path.

10. Return success with data command and URL variables.

The following table of endpoints lists the method and URI template for each endpoint node command. Extension commands are implicitly appended to this table.

Errors are represented in the WebDriver protocol by an HTTP response with an HTTP status in the 4xx or 5xx range, and a JSON body containing details of the error. The body is a JSON Object and has a field named "value" whose value is an object bearing three, and sometimes four, fields:

• "error", containing a string indicating the error code.
• "message", containing an implementation-defined string with a human readable description of the kind of error that occurred.
• "stacktrace", containing an implementation-defined string with a stack trace report of the active stack frames at the time when the error occurred.
• Optionally "data", which is a JSON Object with additional error data helpful in diagnosing the error.

The following table lists each error code, its associated HTTP status, JSON error code, and a non-normative description of the error. The error response data for a particular error code is the values of the HTTP Status and JSON Error Code columns for the row corresponding to that error code.

An error data dictionary is a mapping of string keys to JSON serializable values that can optionally be included with error objects.

Using the terminology defined in this section, others may define additional commands that seamlessly integrate with the standard protocol. This allows vendors to expose functionality that is specific to their user agent, and it also allows other web standards to define commands for automating new platform features.

Commands defined in this way are called extension commands and behave no differently than other commands; each has a dedicated HTTP endpoint and a set of remote end steps.

Each extension command has an associated extension command URI Template that is a URI Template string, and which should bear some resemblance to what the command performs. This value, along with the HTTP method and extension command, is added to the table of endpoints and thus follows the same rules for request routing as that of other built-in commands.

In order to avoid potential resource conflicts with other implementations, vendor-specific extension command URI Templates must begin with one or more path segments which uniquely identifies the vendor and UA. It is suggested that vendors use their vendor prefixes without additional characters as outlined in [CSS21], notably in section 4.1.2.2 on vendor keywords, as the name for this path element, and include a vendor-chosen UA identifier.

Other specifications may define additional WebDriver capabilities. Each defined capability must have a capability name which is a string not containing a ":" (colon) character, an additional capability deserialization algorithm which is a set of steps taking a single argument value which has a JSON type, returning either success wrapping the deserialized capability value or error.

An additional WebDriver capability may also define a matched capability serialization algorithm, which is a set of steps used to determine if a capability is matched by the current implementation and provide any computed value to return to the user. This set of steps takes a single argument value, which is the output of the corresponding additional capability deserialization algorithm, and returns either null to indicate the capability is not matched, or a non-null JSON-serializable value if the capability is matched.

Other specifications may also define WebDriver new session algorithms, which are called just after a new session is created, and before the new session response is sent to the remote end. These algorithms are called with session representing the WebDriver session that will be established, and capabilities, the capabilities object that will be returned to the remote end. It is permitted for such an algorithm to modify any entry in the capabilities object with a name that's an additional WebDriver capability defined by the same specification.

Remote ends may also introduce extension capabilities that are extra capabilities used to provide configuration or fulfill other vendor-specific needs. Extension capabilities' key must contain a ":" (colon) character, denoting an implementation specific namespace. The value can be arbitrary JSON types.

As with extension commands, it is suggested that the key used to denote the extension capability namespace is based on the vendor keywords listed in [CSS21] and precedes the first ":" character in the string.

The proxy configuration capability is a JSON Object nested within the primary capabilities. Implementations may define additional proxy configuration options, but they must not alter the semantics of those listed below.

A host and optional port for a scheme is defined as being a valid host, optionally followed by a colon and a valid port. The host may include credentials. If the port is omitted and scheme has a default port, this is the implied port. Otherwise, the port is left undefined.

A proxyType of "direct" indicates that the browser should not use a proxy at all.

A proxyType of "system" indicates that the browser should use the various proxies configured for the underlying Operating System.

A proxyType of "autodetect" indicates that the proxy to use should be detected in an implementation-specific way.

The remote end steps to deserialize as a proxy argument parameter are:

1. If parameter is not a JSON Object return an error with error code invalid argument.

2. Let proxy be a new, empty proxy configuration object.

3. For each enumerable own property in parameter run the following substeps:

   1. Let key be the name of the property.

   2. Let value be the result of getting a property named name from parameter.

   3. If there is no matching key for key in the proxy configuration table return an error with error code invalid argument.

   4. If value is not one of the valid values for that key, return an error with error code invalid argument.

   5. Set a property key to value on proxy.

4. If proxy does not have an own property for "proxyType" return an error with error code invalid argument.

5. If the result of getting a property named "proxyType" from proxy equals "pac", and proxy does not have an own property for "proxyAutoconfigUrl" return an error with error code invalid argument.

6. If proxy has an own property for "socksProxy" and does not have an own property for "socksVersion" return an error with error code invalid argument.

7. Return success with data proxy.

A proxy configuration object is a JSON Object where each of its own properties matching keys in the proxy configuration meets the validity criteria for that key.

To process capabilities given parameters, and session configuration flags flags, the endpoint node must take the following steps:

1. Let capabilities request be the result of getting the property "capabilities" from parameters.

   1. If capabilities request is not a JSON Object, return error with error code invalid argument.

2. Let required capabilities be the result of getting the property "alwaysMatch" from capabilities request.

   1. If required capabilities is undefined, set the value to an empty JSON Object.

   2. Let required capabilities be the result of trying to validate capabilities with arguments required capabilities and flag.

3. Let all first match capabilities be the result of getting the property "firstMatch" from capabilities request.

   1. If all first match capabilities is undefined, set the value to a List with a single entry of an empty JSON Object.

   2. If all first match capabilities is not a List with one or more entries, return error with error code invalid argument.

4. Let validated first match capabilities be an empty List.

5. For each first match capabilities corresponding to an indexed property in all first match capabilities:

   1. Let validated capabilities be the result of trying to validate capabilities with arguments first match capabilities and flags.

   2. Append validated capabilities to validated first match capabilities.

6. Let merged capabilities be an empty List.

7. For each first match capabilities corresponding to an indexed property in validated first match capabilities:

   1. Let merged be the result of trying to merge capabilities with required capabilities and first match capabilities as arguments.

   2. Append merged to merged capabilities.

8. For each capabilities corresponding to an indexed property in merged capabilities:

   1. Let matched capabilities be the result of trying to match capabilities with capabilities as an argument.

   2. If matched capabilities is not null, return success with data matched capabilities.

9. Return success with data null.

When required to validate capabilities with argument capabilities:

1. If capabilities is not a JSON Object return an error with error code invalid argument.

2. Let result be an empty JSON Object.

3. For each enumerable own property in capabilities, run the following substeps:

   1. Let name be the name of the property.

   2. Let value be the result of getting a property named name from capabilities.

   3. Run the substeps of the first matching condition:

      value is null

      Let deserialized be set to null.

      name equals "acceptInsecureCerts"

      If value is not a boolean return an error with error code invalid argument. Otherwise, let deserialized be set to value.

      name equals "browserName"

      name equals "browserVersion"

      name equals "platformName"

      If value is not a string return an error with error code invalid argument. Otherwise, let deserialized be set to value.

      name equals "pageLoadStrategy"

      Let deserialized be the result of trying to deserialize as a page load strategy with argument value.

      name equals "proxy"

      Let deserialized be the result of trying to deserialize as a proxy with argument value.

      name equals "strictFileInteractability"

      If value is not a boolean return an error with error code invalid argument. Otherwise, let deserialized be set to value

      name equals "timeouts"

      Let deserialized be the result of trying to deserialize as timeouts configuration with value.

      name equals "unhandledPromptBehavior"

      Let deserialized be the result of trying to deserialize as an unhandled prompt behavior with argument value.

      name is the name of an additional WebDriver capability

      Let deserialized be the result of trying to run the additional capability deserialization algorithm for the extension capability corresponding to name, with argument value.

      name is the key of an extension capability

      If name is known to the implementation, let deserialized be the result of trying to deserialize value in an implementation-specific way. Otherwise, let deserialized be set to value.

      The remote end is an endpoint node

      Return an error with error code invalid argument.

   4. If deserialized is not null, set a property on result with name name and value deserialized.

4. Return success with data result.

When merging capabilities with JSON Object arguments primary and secondary, an endpoint node must take the following steps:

1. Let result be a new JSON Object.

2. For each enumerable own property in primary, run the following substeps:

   1. Let name be the name of the property.

   2. Let value be the result of getting a property named name from primary.

   3. Set a property on result with name name and value value.

3. If secondary is undefined, return result.

4. For each enumerable own property in secondary, run the following substeps:

   1. Let name be the name of the property.

   2. Let value be the result of getting a property named name from secondary.

   3. Let primary value be the result of getting the property name from primary.

   4. If primary value is not undefined, return an error with error code invalid argument.

   5. Set a property on result with name name and value value.

5. Return result.

When matching capabilities given JSON Object capabilities, and a session configuration flags flags, an endpoint node must take the following steps:

1. Let matched capabilities be a JSON Object with the following entries:

   "browserName"

   ASCII Lowercase name of the user agent as a string.

   "browserVersion"

   The user agent version, as a string.

   "platformName"

   ASCII Lowercase name of the current platform as a string.

   "acceptInsecureCerts"

   Boolean initially set to false, indicating the session will not implicitly trust untrusted or self-signed TLS certificates on navigation.

   "strictFileInteractability"

   Boolean initially set to false, indicating that interactability checks will be applied to <input type=file>.

   "setWindowRect"

   Boolean indicating whether the remote end supports all of the resizing and positioning commands.

   "userAgent"

   String containing the default User-Agent value.

2. If flags contains "http", add the following entries to matched capabilities:

   "strictFileInteractability"

   Boolean initially set to false, indicating that interactabilty checks will be applied to <input type=file>.

3. Optionally add extension capabilities as entries to matched capabilities. The values of these may be elided, and there is no requirement that all extension capabilities be added.

   Note

4. For each name and value corresponding to capabilities's own properties:

   1. Let match value equal value.

   2. Run the substeps of the first matching name:

      "browserName"

      If value is not a string equal to the "browserName" entry in matched capabilities, return success with data null.

      Note

      There is a chance the remote end will need to start a browser process to correctly determine the browserName. Lightweight checks are preferred before this is done.

      "browserVersion"

      Compare value to the "browserVersion" entry in matched capabilities using an implementation-defined comparison algorithm. The comparison is to accept a value that places constraints on the version using the "<", "<=", ">", and ">=" operators.

      If the two values do not match, return success with data null.

      Note

      Version comparison is left as an implementation detail since each user agent will likely have conflicting methods of encoding the user agent version, and standardizing these schemes is beyond the scope of this standard.

      Note

      There is a chance the remote end will need to start a browser process to correctly determine the browserVersion. Lightweight checks are preferred before this is done.

      "platformName"

      If value is not a string equal to the "platformName" entry in matched capabilities, return success with data null.

      Note

      The following platform names are in common usage with well-understood semantics and, when matching capabilities for platform name, greatest interoperability can be achieved by honoring them as valid synonyms for well-known Operating Systems:

      Key	System
      "linux"	Any server or desktop system based upon the Linux kernel.
      "mac"	Any version of Apple's macOS.
      "windows"	Any version of Microsoft Windows, including desktop and mobile versions.

      This list is not exhaustive.

      When returning capabilities from New Session, it is valid to return a more specific platformName, allowing users to correctly identify the Operating System the WebDriver implementation is running on.

      "acceptInsecureCerts"

      If accept insecure TLS flag is set and not equal to value, return success with data null.

      Note

      If the endpoint node does not support insecure TLS certificates and this is the reason no match is ultimately made, it is useful to provide this information to the local end.

      "proxy"

      If the has proxy configuration flag is set, or if the proxy configuration defined in value is not one that passes the endpoint node's implementation-specific validity checks, return success with data null.

      Note

      A local end would only send this capability if it expected it to be honored and the configured proxy used. The intent is that if this is not possible a new session will not be established.

      "unhandledPromptBehavior"

      If check user prompt handler matches with value is false, return success with data null.

      Otherwise

      • If name is the name of an additional WebDriver capability which defines a matched capability serialization algorithm, let match value be the result of running the matched capability serialization algorithm for capability name with arguments value, and flags.

      • Otherwise, if name is the key of an extension capability, let match value be the result of trying implementation-specific steps to match on name with value. If the match is not successful, return success with data null.

   3. If match value is not null, set a property on matched capabilities with name name and value match value.

5. Return success with data matched capabilities.

In addition to per-session state, a remote end that is an endpoint node also has additional state that is global across all sessions.

An endpoint node has an associated accept insecure TLS flag that indicates whether untrusted or self-signed TLS certificates are treated as trusted. The default value of the flag is false if the endpoint doesn't support accepting insecure TLS connections, or unset otherwise.

An endpoint node has an associated has proxy configuration flag that indicates whether the proxy is already configured. The default value of the flag is true if the endpoint doesn't support proxy configuration, or false otherwise.

To create a session, given a JSON Object capabilites, and session configuration flags flags:

1. Let session id be the result of generating a UUID.

2. Let session be a new session with session ID session id, and HTTP flag flags contains "http".

3. Let proxy be the result of getting property "proxy" from capabilities and run the substeps of the first matching statement:

   proxy is a proxy configuration object

   Take implementation-defined steps to set the user agent proxy using the extracted proxy configuration. If the defined proxy cannot be configured return error with error code session not created. Otherwise set the has proxy configuration flag to true.

   Otherwise

   Set a property of capabilities with name "proxy" and a value that is a new JSON Object.

4. If capabilites has a property named "acceptInsecureCerts", set the endpoint node's accept insecure TLS flag to the result of getting a property named "acceptInsecureCerts" from capabilities.

5. Let user prompt handler capability be the result of getting property "unhandledPromptBehavior" from capabilities.

6. If user prompt handler capability is not undefined, update the user prompt handler with user prompt handler capability.

7. Let serialized user prompt handler be serialize the user prompt handler.

8. Set a property on capabilities with the name "unhandledPromptBehavior", and the value serialized user prompt handler.

9. If flags contains "http":

   1. Let strategy be the result of getting property "pageLoadStrategy" from capabilities.

      If strategy is a string, set the session's page loading strategy to strategy. Otherwise, set the page loading strategy to normal and set a property of capabilities with name "pageLoadStrategy" and value "normal".

   2. Let strictFileInteractability be the result of getting property "strictFileInteractability" from capabilities. If strictFileInteractability is a boolean, set session's strict file interactability to strictFileInteractability.

   3. Let timeouts be the result of getting a property "timeouts" from capabilities. If timeouts is not undefined, set session's session timeouts to timeouts.

   4. Set a property on capabilities with name "timeouts" and value serialize the timeouts configuration with session's session timeouts.

10. Process any extension capabilities in capabilities in an implementation-defined manner.

11. Run any WebDriver new session algorithm defined in external specifications, with arguments session, capabilities, and flags.

12. Append session to active sessions.

13. If flags contains "http", append session to active HTTP sessions.

14. Set the webdriver-active flag to true.

To close the session, given session a remote end must take the following steps:

1. If session's HTTP flag is set, remove session from active HTTP sessions.

2. Remove session from active sessions.

3. Perform the following substeps based on the remote end's type:

   Remote end is an endpoint node

   1. If the list of active sessions is empty:

      1. Set the webdriver-active flag to false

      2. Set the user prompt handler to null.

      3. Unset the accept insecure TLS flag.

      4. Reset the has proxy configuration flag to its default value.

      5. Optionally, close all top-level browsing contexts, without prompting to unload.

   Remote end is an intermediary node

   1. Close the associated session. If this causes an error to occur, complete the remainder of this algorithm before returning the error.

4. Perform any implementation-specific cleanup steps.

5. If an error has occurred in any of the steps above, return the error, otherwise return success with data null.

Closing a session might cause the associated browser process to be killed. It is assumed that any implementation-specific cleanup steps are performed after the response has been sent back to the client so that the connection is not prematurely closed.

The New Session command creates a new WebDriver session with the endpoint node. If the creation fails, a session not created error is returned.

If the remote end is an intermediary node, it may use the result of the capabilities processing algorithm to route the new session request to the appropriate endpoint node. An intermediary node is free to define extension capabilities to assist in this process, however, these specific capabilities must not be forwarded to the endpoint node.

If the intermediary node requires additional information unrelated to user agent features, it is recommended that this information be passed as top-level parameters, and not as part of the requested capabilities. An intermediary node must forward custom, top-level parameters (i.e. non-capabilities) to subsequent remote end nodes.

The remote end steps, given session, URL variables and parameters are:

1. If the implementation is an endpoint node, and the list of active HTTP sessions is not empty, or otherwise if the implementation is unable to start an additional session, return error with error code session not created.

2. If the remote end is an intermediary node, take implementation-defined steps that either result in returning an error with error code session not created, or in returning a success with data that is isomorphic to that returned by remote ends according to the rest of this algorithm. If an error is not returned, the intermediary node must retain a reference to the session created on the upstream node as the associated session such that commands may be forwarded to this associated session on subsequent commands.

   Note

   How this is done is entirely up to the implementation, but typically the sessionId, and URL and URL prefix of the upstream remote end will need to be tracked.

3. Let flags be a set containing "http".

4. Let capabilities be the result of trying to process capabilities with parameters and flags.

5. If capabilities's is null, return error with error code session not created.

6. Let session be the result of create a session, with capabilities, and flags.

7. Let body be a JSON Object initialized with:

   "sessionId"

   session's session ID.

   "capabilities"

   capabilities

8. Set session' current top-level browsing context to one of the endpoint node's top-level browsing contexts, preferring the top-level browsing context that has system focus, or otherwise preferring any top-level browsing context whose visibility state is visible.

   Note

   WebDriver implementations typically start a completely new browser instance, but there is no requirement in this specification (or for WebDriver only to be used to automate only web browsers). Implementations might choose to use an existing browser instance, eg. by selecting the window that currently has focus.

9. Set the request queue to a new queue.

10. Return success with data body.

The remote end steps, given session, URL variables and parameters are:

1. If session is an active HTTP session, try to close the session with session.

2. Return success with data null.

Implementations may optionally include additional meta information as part of the body, but the top-level properties ready and message are reserved and must not be overwritten.

The remote end steps, given session, URL variables and parameters are:

1. Let body be a new JSON Object with the following properties:

   "ready"

   The remote end's readiness state.

   "message"

   An implementation-defined string explaining the remote end's readiness state.

2. Return success with data body.

The remote end steps, given session, URL variables and parameters are:

1. Let timeouts be serialize the timeouts configuration with session's timeouts configuration

2. Return success with data timeouts.

The remote end steps, given session, URL variables and parameters are:

1. Let timeouts be the result of trying to deserialize as timeouts configuration with parameters.

2. Set session's timeouts configuration to timeouts.

3. Return success with data null.

If the remote end's accept insecure TLS flag is true, no certificate errors that would normally cause the user agent to abort and show a security warning are to hinder navigation to the requested address.

The remote end steps, given session, URL variables and parameters are:

1. Let URL be the result of getting a property named "url" from parameters.

2. If session's current top-level browsing context is no longer open, return error with error code no such window.

3. If URL is not an absolute URL or is not an absolute URL with fragment or not a local scheme, return error with error code invalid argument.

4. Try to handle any user prompts with session.

5. Let timeout be session's session timeouts page load timeout.

6. Let current URL be session's current top-level browsing context's active document's URL.

7. If current URL and URL do not have the same absolute URL and timeout is not null:

   1. Set timer to a new timer.

   2. Start the timer with timer and timeout.

8. Run these steps, but abort when timer's timeout fired flag is set:

   1. Navigate session's current top-level browsing context to URL.

   2. If URL is special except for file and current URL and URL do not have the same absolute URL :

      1. Try to wait for navigation to complete with session and timer.

      2. Try to run the post-navigation checks.

   3. Set the current browsing context with session and current top-level browsing context.

   4. While session's current top-level browsing context contains a refresh state pragma directive of time 1 second or less, run the following steps:

      1. Set current URL to session's current top-level browsing context's active document's URL.

      2. Wait until the refresh timeout has elapsed and new navigate of session's current top-level browsing context has begun.

      3. Set URL to the destination URL of session's current top-level browsing context's active document's ongoing navigation.

      4. If URL is special except for file and current URL and URL do not have the same absolute URL :

         1. Try to wait for navigation to complete with session and timer.

         2. Try to run the post-navigation checks.

9. If aborted return an error with error code timeout.

10. Return success with data null.

The remote end steps, given session, URL variables and parameters are:

1. If session's current top-level browsing context is no longer open, return error with error code no such window.

2. Try to handle any user prompts with session.

3. Let URL be the serialization of session's current top-level browsing context's active document's URL.

4. Return success with data URL.

The remote end steps, given session, URL variables and parameters are:

1. If session's current top-level browsing context is no longer open, return error with error code no such window.

2. Try to handle any user prompts with session.

3. Let timeout be session' session timeouts page load timeout.

4. Let timer be a new timer.

5. If timeout is not null:

   1. Start the timer with timer and timeout.

6. Traverse the history by a delta –1 for session's current browsing context.

7. If the previous step completed results in a pageHide event firing, wait until pageShow event fires or timer' timeout fired flag to be set, whichever occurs first.

8. If timer' timeout fired flag is set:

   1. Handle any user prompts.

   2. Return error with error code timeout.

9. Return success with data null.

The remote end steps, given session, URL variables and parameters are:

1. If session's current top-level browsing context is no longer open, return error with error code no such window.

2. Try to handle any user prompts with session.

3. Let timeout be session' session timeouts page load timeout.

4. Let timer be a new timer.

5. If timeout is not null:

   1. Start the timer with timer and timeout.

6. Traverse the history by a delta 1 for session's current browsing context.

7. If the previous step completed results in a pageHide event firing, wait until pageShow event fires or timer' timeout fired flag to be set, whichever occurs first.

8. If timer' timeout fired flag is set:

   1. Handle any user prompts.

   2. Return error with error code timeout.

9. Return success with data null.

The remote end steps, given session, URL variables and parameters are:

1. If session's current top-level browsing context is no longer open, return error with error code no such window.

2. Try to handle any user prompts with session.

3. Initiate an overridden reload of session's current top-level browsing context's active document.

4. If URL is special except for file:

   1. Try to wait for navigation to complete with session.

   2. Try to run the post-navigation checks.

5. Set the current browsing context with session and session'scurrent top-level browsing context.

6. Return success with data null.

The remote end steps, given session, URL variables and parameters are:

1. If session's current top-level browsing context is no longer open, return error with error code no such window.

2. Try to handle any user prompts with session.

3. Let title be the session's current top-level browsing context's active document's title.

4. Return success with data title.

The remote end steps, given session, URL variables and parameters are:

1. If session's current top-level browsing context is no longer open, return error with error code no such window.

2. Return success with data being the window handle associated with session's current top-level browsing context.

The remote end steps, given session, URL variables and parameters are:

1. If session's current top-level browsing context is no longer open, return error with error code no such window.

2. Try to handle any user prompts with session.

3. Close session's current top-level browsing context.

4. If there are no more open top-level browsing contexts, then try to close the session.

5. Return the result of running the remote end steps for the Get Window Handles command, with session, URL variables and parameters.

The remote end steps, given session, URL variables and parameters are:

1. Let handle be the result of getting the property "handle" from parameters.

2. If handle is undefined, return error with error code invalid argument.

3. If there is an active user prompt, that prevents the focusing of another top-level browsing context, return error with error code unexpected alert open.

4. If handle is equal to the associated window handle for some top-level browsing context, let context be the that browsing context, and set the current top-level browsing context with session and context.

   Otherwise, return error with error code no such window.

5. Update any implementation-specific state that would result from the user selecting session's current browsing context for interaction, without altering OS-level focus.

6. Return success with data null.

The order in which the window handles are returned is arbitrary.

The remote end steps, given session, URL variables and parameters are:

1. Let handles be a List.

2. For each top-level browsing context in the remote end, push the associated window handle onto handles.

3. Return success with data handles.

Create a new top-level browsing context.

The remote end steps, given session, URL variables and parameters are:

1. If the implementation does not support creating new top-level browsing contexts, return error with error code unsupported operation.

2. If session's current top-level browsing context is no longer open, return error with error code no such window.

3. Try to handle any user prompts with session.

4. Let type hint be the result of getting the property "type" from parameters.

5. Create a new top-level browsing context by running the window open steps with URL set to "about:blank", target set to the empty string, and features set to "noopener" and the user agent configured to create a new browsing context. This must be done without invoking the focusing steps for the created browsing context. If type hint has the value "tab", and the implementation supports multiple browsing context in the same OS window, the new browsing context should share an OS window with session's current browsing context. If type hint is "window", and the implementation supports multiple browsing contexts in separate OS windows, the created browsing context should be in a new OS window. In all other cases the details of how the browsing context is presented to the user are implementation defined.

6. Let handle be the associated window handle of the newly created window.

7. Let type be "tab" if the newly created window shares an OS-level window with session's current browsing context, or "window" otherwise.

8. Let result be a new JSON Object initialized with:

   "handle"

   The value of handle.

   "type"

   The value of type.

9. Return success with data result.

1. Let id be the result of getting the property "id" from parameters.

2. If id is not null, a Number object, or an Object that represents a web element, return error with error code invalid argument.

3. Run the substeps of the first matching condition:

   id is null

   1. If session's current top-level browsing context is no longer open, return error with error code no such window.

   2. Try to handle any user prompts with session.

   3. Set the current browsing context with session and session's current top-level browsing context.

   id is a Number object

   1. If id is less than 0 or greater than 2¹⁶ – 1, return error with error code invalid argument.

   2. If session's current browsing context is no longer open, return error with error code no such window.

   3. Try to handle any user prompts with session.

   4. Let window be the associated window of session's current browsing context's active document.

   5. If id is not a supported property index of window, return error with error code no such frame.

   6. Let child window be the WindowProxy object obtained by calling window.[[GetOwnProperty]] (id).

   7. Set the current browsing context with session and child window's browsing context.

   id represents a web element

   1. If session's current browsing context is no longer open, return error with error code no such window.

   2. Try to handle any user prompts with session.

   3. Let element be the result of trying to get a known element with session and id.

   4. If element is not a frame or iframe element, return error with error code no such frame.

   5. Set the current browsing context with session and element's content navigable's active browsing context.

4. Update any implementation-specific state that would result from the user selecting session's current browsing context for interaction, without altering OS-level focus.

5. Return success with data null.

The remote end steps, given session, URL variables and parameters are:

1. If session's current browsing context is already the top-level browsing context:

   1. If session's current browsing context is no longer open, return error with error code no such window.

   2. Return success with data null.

2. If session's current parent browsing context is no longer open, return error with error code no such window.

3. Try to handle any user prompts with session.

4. If session's current parent browsing context is not null, set the current browsing context with session and current parent browsing context.

5. Update any implementation-specific state that would result from the user selecting session's current browsing context for interaction, without altering OS-level focus.

6. Return success with data null.

WebDriver provides commands for interacting with the operating system window containing session's current top-level browsing context. Because different operating systems' window managers provide different abilities, not all of the commands in this section can be supported by all remote ends. Support for these commands is determined by the window dimensioning/positioning capability. Where a command is not supported, an unsupported operation error is returned.

The top-level browsing context has an associated window state which describes what visibility state its OS widget window is in. It can be in one of the following states:

If for whatever reason the top-level browsing context's OS window cannot enter either of the window states, or if this concept is not applicable on the current system, the default state must be normal.

The WindowRect object for a WindowProxy, window is an Object initialized with the following properties:

"x"

window's screenX attribute.

"y"

window's screenY attribute.

"width"

windows's outerWidth attribute.

"height"

window's outerHeight attribute.

To maximize the window, given an operating system level window with an associated top-level browsing context, run the implementation-specific steps to transition the operating system level window into the maximized window state. If the window manager supports window resizing but does not have a concept of window maximization, the window dimensions must be increased to the maximum available size permitted by the window manager for the current screen. Return when the window has completed the transition, or within an implementation-defined timeout.

To iconify the window, given an operating system level window with an associated top-level browsing context, run implementation-specific steps to transition the operating system level window into the minimized window state. Do not return from this operation until the visibility state of the top-level browsing context's active document has reached the hidden state, or until the operation times out.

To restore the window, given an operating system level window with an associated top-level browsing context, run implementation-specific steps to restore or unhide the window to the visible screen. Do not return from this operation until the visibility state of the top-level browsing context's active document has reached the visible state, or until the operation times out.