Pid capability #1
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 <julian.descottes@gmail.com>
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 <69349599+sadym-chromium@users.noreply.github.com>
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
Signed-off-by: Aurélien Pupier <apupier@redhat.com>
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 <a_protyasha@apple.com>
…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
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
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 <69349599+sadym-chromium@users.noreply.github.com>
This makes editing much easier, since unpaired ' were causing syntax highlighting problems.
…3c#1790) * Add userAgent capability * add userAgent to matching * Update index.html Co-authored-by: Henrik Skupin <mail@hskupin.info> --------- Co-authored-by: Henrik Skupin <mail@hskupin.info>
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 <OrKoN@users.noreply.github.com> Co-authored-by: Henrik Skupin <mail@hskupin.info>
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 <mail@hskupin.info>
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 <james@hoppipolla.co.uk>
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.
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 <OrKoN@users.noreply.github.com>
--------- Co-authored-by: jgraham <james@hoppipolla.co.uk>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.