…TML. (w3c#1689)

This does just enough to make the build pass for the navigable changes
in HTML, without actually fixing the underlying model to match.

Co-authored-by: Julian Descottes <[email protected]>

For WebDriver BiDi we want to be able to return any Node object, and
to support all reachable Nodes, not just those in the same browsing
context. Therefore the approach of having per-Window Element and
ShadowRoot caches won't work. Instead implement the following:

* A per session, per browsing context group Node to id mapping that
can store any Node.
* Frontends in WebDriver to store Elements and ShadowRoots in this
map, and perform the additional same-document, connected element,
checks that the protocol requires.

This doesn't introduce any normative changes into WebDriver, it just
refactors the infrastructure to make it reusable in the BiDi context.

Co-authored-by: Maksim Sadym <[email protected]>

Use "error value" rather than the incorrect "error response".

If we've previously seen an element in the current window, but it was
GC'd we should return "stale element reference". To support this, add
a set of seen node ids keyed on window so we can check if the element
reference was ever valid in this document.

…JSON clone algorithm" (w3c#1709)

This is really designed for BiDi, allowing actions to specify the
origin relative to an element in the form:

 {
  type: "element"
  sharedId: <id>
 }

rather than sending in a WebDriver-style element reference. 
To use this, each caller has to pass in steps to determine if something
represents an element origin, and if so, decode it into an actual element.

This allows BiDi to specify different steps to WebDriver classic

…aleness check.

Signed-off-by: Aurélien Pupier <[email protected]>

Correct the markup so the build system recognizes the reference to the
variable named "keyup action" and add a period to end the statement.

The existing link was self-referential.  This was unhelpful for understanding the document.

…#1750)

The term was renamed in the HTML spec in whatwg/html#8712 so the current
reference was broken as mentioned in w3c#1735.

While here, use ReSpec's shorthand syntax to refer to these sub concepts
directly and avoid having to specifically link to them in the index at the
end of the document.

…commands (w3c#1757)

In this commit we update the Safari vendor status document to point to the set of commands supporting the W3C WebDriver protocol. The previous link redirects to [macOS WebDriver Commands for Safari 11.1 and earlier](https://developer.apple.com/documentation/webkit/macos_webdriver_commands_for_safari_11_1_and_earlier?language=objc), which highlights the WebDriver Commands supporting the Selenium JSON Wire Protocol instead.

Signed-off-by: Abrar Rahman Protyasha <[email protected]>

…for wheel input sources (w3c#1760)

Move "pointer" check for wheel action into processing action step.

This was previously leading to undefined behaviour in the spec, because a wheel input source doesn't have a location to offset from.

coordindates -> coordinates

* Correct element click actions list

element click is erroneously defined as `«pointer move action, pointer down action, pointer move action».` but should obviously be `«pointer move action, pointer down action, pointer up action».` making use of the pointer up action defined

* Correct element click pointer up action's id

The pointer id of pointer up action should be "pointer" to match the pointer move and pointer down actions pointer ids

… ShadowRoot (w3c#1778)

This specification uses the List type from WHATWG Infra [1]. It does so
indirectly, working with a derivative which it refers to as a "JSON
List." This type is not defined, but because its usage matches that of
the List, the qualifier "JSON" appears to be superfluous.

Remove the qualifier to clarify the type of the specification values.

[1] https://infra.spec.whatwg.org/#lists

… window. (w3c#1782)

…3c#1784)

With BiDi we want to support multiple sessions, at most one of which
can also enable the HTTP frontend. Therefore we add the concept of
multiple sessions, which can have different flags set according to the
protocols they support (http, bidi, etc.).

This explictly passes the session, parameters and url variables down
into each command. In addition the URL variables are handled as a
infra struct rather than as a custom thing with implied variables.

Instead of having a concept of the "current session" we explicitly
pass the session around where required.

---------

Co-authored-by: Maksim Sadym <[email protected]>

This makes editing much easier, since unpaired ' were causing syntax highlighting
problems.

This reverts commit d05e463.

…3c#1790)

* Add userAgent capability

* add userAgent to matching

* Update index.html

Co-authored-by: Henrik Skupin <[email protected]>

---------

Co-authored-by: Henrik Skupin <[email protected]>

This takes us down to zero respec warnings when bulding the spec.

We still have terms which are only referenced in non-normative
contexts. That's probably also a bug, and could be fixed in a
followup. However this at least provides a clean baseline for future
spec work.

This refactors the way that timeout configuration is used in the spec,
and fixes several bugs, but does not otherwise have intentional
normative changes.

The main change is the creation of a "timeouts configuration" struct
that is owned by the session. A new struct is created when the
timeouts are changed (including during capabilities processing) and
this fixes a number of confusing cases where the "JSON deserialize"
algorithm was linked in place of the more specific algorithm for
reading the timeout data.

In addition a new "timer" class is created with a flag that's set when
the required time has elapsed. This is now used in all places where we
wait up to a timeout, and we assume we're able to wait for the flag to
change, or check the current value of the flag, as required. Fixing
this required fixing many cases where it was assumed that timeouts
couldn't be null.

Co-authored-by: Alex Rudenko <[email protected]>
Co-authored-by: Henrik Skupin <[email protected]>

Rewrite the user prompt handler configuration to allow overrides

The idea is that for BiDi we'll accept objects like:

{
  "alert": "dismiss",
  "beforeUnload": "ignore"
}

to allow different handling per prompt type, whilst falling back to
the appropiate defaults to maintain the current behaviour for
implementations that don't support BiDi.

We also allow the possibility of multiple user prompts

The specifications allow one prompt per event loop, so instead of
assuming a single current user prompt, allow getting the user
prompt for the active browsing context's event loop.

---------

Co-authored-by: Henrik Skupin <[email protected]>

Selenium's atom "Is Element Enabled" special-cases the
disabled state for "option" and "optgroup" elements
when the nearest anchestor "select" is disabled as well.

…c#1811)

In SeleniumHQ/selenium@33c6b78
the atom was fixed to correctly find capitalized text containing
and underscore.

…3c#1816)

Co-authored-by: jgraham <[email protected]>

This would prevent creating a BiDi session for a browser that already has a HTTP session
with the notify flag set for some prompt handler.

…c#1817) (w3c#1820)

Incorrect parameter name "input state" was replaced with "source"

Co-authored-by: daniilch <[email protected]>

protcols -> protocols

Previously an object value for the unhandledPromptBehavior capability
like:

{
  "default": "dismiss"
}

was equivalent to the string value

"dismiss"

which for legacy reasons does not affect "beforeUnload" prompts.

For WebDriver-BiDi session we'd ideally like to remove this special
case and have the default value apply to all prompt types.

Therefore this changes things so that an object value with a default
key provides a default that applies to all prompt types, whereas the
traditional string values only apply to alert/confirm/prompt dialogs.

This preserves classic semantics for string-only values, but makes the
object values behave in a more uniform way.

When creating a session, ensure that we always return the used value
of this capability, whether or not it was passed in.

Previously it was unclear if it was acceptable to return without error
from set window rect if the implementation is unable to set some of
the properties.

This updates the spec so that:

* It's unambiguously OK to run the command even if you don't support
some aspects of the functionality on the current platform /
configuration (you are expected to continue to return an error if you
don't support any aspect of the functionality).

* It's clear that both position and dimension properties are best
effort, and even if you are able to adjust them there's no guarantee
that you get the exact requested values.

* It's clear what to do if you get just an x coordinate but not y, or
just width but not height, or vice-versa. Previously this was undefined.

* Fix some small problems with set window rect changes

* Restore handling both missing and null values for parameters.

* Fix some grammar errors.

* Apply suggestions from code review

---------

Co-authored-by: Alex Rudenko <[email protected]>

---------

Co-authored-by: jgraham <[email protected]>