2016-01-30 08:50:46 -08:00
|
|
|
// Licensed to the Software Freedom Conservancy (SFC) under one
|
|
|
|
|
// or more contributor license agreements. See the NOTICE file
|
|
|
|
|
// distributed with this work for additional information
|
|
|
|
|
// regarding copyright ownership. The SFC licenses this file
|
|
|
|
|
// to you under the Apache License, Version 2.0 (the
|
|
|
|
|
// "License"); you may not use this file except in compliance
|
|
|
|
|
// with the License. You may obtain a copy of the License at
|
|
|
|
|
//
|
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
//
|
|
|
|
|
// Unless required by applicable law or agreed to in writing,
|
|
|
|
|
// software distributed under the License is distributed on an
|
|
|
|
|
// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
|
|
|
|
// KIND, either express or implied. See the License for the
|
|
|
|
|
// specific language governing permissions and limitations
|
|
|
|
|
// under the License.
|
|
|
|
|
|
2020-08-03 17:56:31 +03:00
|
|
|
'use strict'
|
2016-01-30 08:50:46 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @fileoverview Defines types related to user input with the WebDriver API.
|
|
|
|
|
*/
|
2020-08-03 17:56:31 +03:00
|
|
|
const { Command, Name } = require('./command')
|
2021-07-09 16:33:17 +05:30
|
|
|
const { InvalidArgumentError } = require('./error')
|
2016-01-30 08:50:46 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Enumeration of the buttons used in the advanced interactions API.
|
|
|
|
|
* @enum {number}
|
|
|
|
|
*/
|
|
|
|
|
const Button = {
|
|
|
|
|
LEFT: 0,
|
|
|
|
|
MIDDLE: 1,
|
2020-08-03 17:56:31 +03:00
|
|
|
RIGHT: 2,
|
2022-08-21 11:58:45 +05:30
|
|
|
BACK: 3,
|
2022-08-22 19:42:48 +03:00
|
|
|
FORWARD: 4,
|
2020-08-03 17:56:31 +03:00
|
|
|
}
|
2016-01-30 08:50:46 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Representations of pressable keys that aren't text. These are stored in
|
|
|
|
|
* the Unicode PUA (Private Use Area) code points, 0xE000-0xF8FF. Refer to
|
2017-10-26 23:36:30 -05:00
|
|
|
* http://www.google.com.au/search?&q=unicode+pua&btnK=Search
|
2016-01-30 08:50:46 -08:00
|
|
|
*
|
|
|
|
|
* @enum {string}
|
2017-10-08 20:05:35 -07:00
|
|
|
* @see <https://www.w3.org/TR/webdriver/#keyboard-actions>
|
2016-01-30 08:50:46 -08:00
|
|
|
*/
|
|
|
|
|
const Key = {
|
2020-08-03 17:56:31 +03:00
|
|
|
NULL: '\uE000',
|
|
|
|
|
CANCEL: '\uE001', // ^break
|
|
|
|
|
HELP: '\uE002',
|
|
|
|
|
BACK_SPACE: '\uE003',
|
|
|
|
|
TAB: '\uE004',
|
|
|
|
|
CLEAR: '\uE005',
|
|
|
|
|
RETURN: '\uE006',
|
|
|
|
|
ENTER: '\uE007',
|
|
|
|
|
SHIFT: '\uE008',
|
|
|
|
|
CONTROL: '\uE009',
|
|
|
|
|
ALT: '\uE00A',
|
|
|
|
|
PAUSE: '\uE00B',
|
|
|
|
|
ESCAPE: '\uE00C',
|
|
|
|
|
SPACE: '\uE00D',
|
|
|
|
|
PAGE_UP: '\uE00E',
|
|
|
|
|
PAGE_DOWN: '\uE00F',
|
|
|
|
|
END: '\uE010',
|
|
|
|
|
HOME: '\uE011',
|
|
|
|
|
ARROW_LEFT: '\uE012',
|
|
|
|
|
LEFT: '\uE012',
|
|
|
|
|
ARROW_UP: '\uE013',
|
|
|
|
|
UP: '\uE013',
|
|
|
|
|
ARROW_RIGHT: '\uE014',
|
|
|
|
|
RIGHT: '\uE014',
|
|
|
|
|
ARROW_DOWN: '\uE015',
|
|
|
|
|
DOWN: '\uE015',
|
|
|
|
|
INSERT: '\uE016',
|
|
|
|
|
DELETE: '\uE017',
|
|
|
|
|
SEMICOLON: '\uE018',
|
|
|
|
|
EQUALS: '\uE019',
|
|
|
|
|
|
|
|
|
|
NUMPAD0: '\uE01A', // number pad keys
|
|
|
|
|
NUMPAD1: '\uE01B',
|
|
|
|
|
NUMPAD2: '\uE01C',
|
|
|
|
|
NUMPAD3: '\uE01D',
|
|
|
|
|
NUMPAD4: '\uE01E',
|
|
|
|
|
NUMPAD5: '\uE01F',
|
|
|
|
|
NUMPAD6: '\uE020',
|
|
|
|
|
NUMPAD7: '\uE021',
|
|
|
|
|
NUMPAD8: '\uE022',
|
|
|
|
|
NUMPAD9: '\uE023',
|
|
|
|
|
MULTIPLY: '\uE024',
|
|
|
|
|
ADD: '\uE025',
|
|
|
|
|
SEPARATOR: '\uE026',
|
|
|
|
|
SUBTRACT: '\uE027',
|
|
|
|
|
DECIMAL: '\uE028',
|
|
|
|
|
DIVIDE: '\uE029',
|
|
|
|
|
|
|
|
|
|
F1: '\uE031', // function keys
|
|
|
|
|
F2: '\uE032',
|
|
|
|
|
F3: '\uE033',
|
|
|
|
|
F4: '\uE034',
|
|
|
|
|
F5: '\uE035',
|
|
|
|
|
F6: '\uE036',
|
|
|
|
|
F7: '\uE037',
|
|
|
|
|
F8: '\uE038',
|
|
|
|
|
F9: '\uE039',
|
|
|
|
|
F10: '\uE03A',
|
|
|
|
|
F11: '\uE03B',
|
|
|
|
|
F12: '\uE03C',
|
|
|
|
|
|
|
|
|
|
COMMAND: '\uE03D', // Apple command key
|
|
|
|
|
META: '\uE03D', // alias for Windows key
|
2017-10-08 20:05:35 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Japanese modifier key for switching between full- and half-width
|
|
|
|
|
* characters.
|
|
|
|
|
* @see <https://en.wikipedia.org/wiki/Language_input_keys>
|
|
|
|
|
*/
|
|
|
|
|
ZENKAKU_HANKAKU: '\uE040',
|
2020-08-03 17:56:31 +03:00
|
|
|
}
|
2016-01-30 08:50:46 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Simulate pressing many keys at once in a "chord". Takes a sequence of
|
|
|
|
|
* {@linkplain Key keys} or strings, appends each of the values to a string,
|
|
|
|
|
* adds the chord termination key ({@link Key.NULL}) and returns the resulting
|
|
|
|
|
* string.
|
|
|
|
|
*
|
|
|
|
|
* Note: when the low-level webdriver key handlers see Keys.NULL, active
|
|
|
|
|
* modifier keys (CTRL/ALT/SHIFT/etc) release via a keyup event.
|
|
|
|
|
*
|
2017-10-08 20:21:44 -07:00
|
|
|
* @param {...string} keys The key sequence to concatenate.
|
2016-01-30 08:50:46 -08:00
|
|
|
* @return {string} The null-terminated key sequence.
|
|
|
|
|
*/
|
2020-08-03 17:56:31 +03:00
|
|
|
Key.chord = function (...keys) {
|
|
|
|
|
return keys.join('') + Key.NULL
|
|
|
|
|
}
|
2016-01-30 08:50:46 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Used with {@link ./webelement.WebElement#sendKeys WebElement#sendKeys} on
|
|
|
|
|
* file input elements (`<input type="file">`) to detect when the entered key
|
|
|
|
|
* sequence defines the path to a file.
|
|
|
|
|
*
|
|
|
|
|
* By default, {@linkplain ./webelement.WebElement WebElement's} will enter all
|
|
|
|
|
* key sequences exactly as entered. You may set a
|
|
|
|
|
* {@linkplain ./webdriver.WebDriver#setFileDetector file detector} on the
|
|
|
|
|
* parent WebDriver instance to define custom behavior for handling file
|
|
|
|
|
* elements. Of particular note is the
|
|
|
|
|
* {@link selenium-webdriver/remote.FileDetector}, which should be used when
|
|
|
|
|
* running against a remote
|
2019-11-16 21:28:00 +01:00
|
|
|
* [Selenium Server](https://selenium.dev/downloads/).
|
2016-01-30 08:50:46 -08:00
|
|
|
*/
|
|
|
|
|
class FileDetector {
|
|
|
|
|
/**
|
|
|
|
|
* Handles the file specified by the given path, preparing it for use with
|
|
|
|
|
* the current browser. If the path does not refer to a valid file, it will
|
2016-11-28 05:10:25 +03:00
|
|
|
* be returned unchanged, otherwise a path suitable for use with the current
|
2016-01-30 08:50:46 -08:00
|
|
|
* browser will be returned.
|
|
|
|
|
*
|
|
|
|
|
* This default implementation is a no-op. Subtypes may override this function
|
|
|
|
|
* for custom tailored file handling.
|
|
|
|
|
*
|
2016-02-08 21:43:09 -08:00
|
|
|
* @param {!./webdriver.WebDriver} driver The driver for the current browser.
|
2016-01-30 08:50:46 -08:00
|
|
|
* @param {string} path The path to process.
|
2016-06-08 08:26:34 -07:00
|
|
|
* @return {!Promise<string>} A promise for the processed file path.
|
2016-01-30 08:50:46 -08:00
|
|
|
* @package
|
|
|
|
|
*/
|
2022-08-22 19:42:48 +03:00
|
|
|
handleFile(_driver, path) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return Promise.resolve(path)
|
2016-01-30 08:50:46 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/**
|
|
|
|
|
* Generic description of a single action to send to the remote end.
|
|
|
|
|
*
|
|
|
|
|
* @record
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
|
|
|
|
class Action {
|
|
|
|
|
constructor() {
|
|
|
|
|
/** @type {!Action.Type} */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.type
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @type {(number|undefined)} */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.duration
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @type {(string|undefined)} */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.value
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @type {(Button|undefined)} */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.button
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @type {(number|undefined)} */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.x
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @type {(number|undefined)} */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.y
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
}
|
2017-10-08 20:05:35 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @enum {string}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @package
|
|
|
|
|
* @see <https://w3c.github.io/webdriver/webdriver-spec.html#terminology-0>
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
Action.Type = {
|
|
|
|
|
KEY_DOWN: 'keyDown',
|
|
|
|
|
KEY_UP: 'keyUp',
|
|
|
|
|
PAUSE: 'pause',
|
|
|
|
|
POINTER_DOWN: 'pointerDown',
|
|
|
|
|
POINTER_UP: 'pointerUp',
|
|
|
|
|
POINTER_MOVE: 'pointerMove',
|
2020-08-03 17:56:31 +03:00
|
|
|
POINTER_CANCEL: 'pointerCancel',
|
2022-02-03 13:35:44 +00:00
|
|
|
SCROLL: 'scroll',
|
2020-08-03 17:56:31 +03:00
|
|
|
}
|
2017-10-08 20:05:35 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Represents a user input device.
|
|
|
|
|
*
|
|
|
|
|
* @abstract
|
|
|
|
|
*/
|
|
|
|
|
class Device {
|
|
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @param {Device.Type} type the input type.
|
2017-10-08 20:05:35 -07:00
|
|
|
* @param {string} id a unique ID for this device.
|
|
|
|
|
*/
|
|
|
|
|
constructor(type, id) {
|
2020-08-03 17:56:31 +03:00
|
|
|
/** @private @const */ this.type_ = type
|
|
|
|
|
/** @private @const */ this.id_ = id
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** @return {!Object} the JSON encoding for this device. */
|
|
|
|
|
toJSON() {
|
2020-08-03 17:56:31 +03:00
|
|
|
return { type: this.type_, id: this.id_ }
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/**
|
|
|
|
|
* Device types supported by the WebDriver protocol.
|
|
|
|
|
*
|
|
|
|
|
* @enum {string}
|
|
|
|
|
* @see <https://w3c.github.io/webdriver/webdriver-spec.html#input-source-state>
|
|
|
|
|
*/
|
|
|
|
|
Device.Type = {
|
|
|
|
|
KEY: 'key',
|
|
|
|
|
NONE: 'none',
|
2020-08-03 17:56:31 +03:00
|
|
|
POINTER: 'pointer',
|
2022-02-03 13:35:44 +00:00
|
|
|
WHEEL: 'wheel',
|
2020-08-03 17:56:31 +03:00
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @param {(string|Key|number)} key
|
|
|
|
|
* @return {string}
|
|
|
|
|
* @throws {!(InvalidArgumentError|RangeError)}
|
|
|
|
|
*/
|
|
|
|
|
function checkCodePoint(key) {
|
|
|
|
|
if (typeof key === 'number') {
|
2020-08-03 17:56:31 +03:00
|
|
|
return String.fromCodePoint(key)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (typeof key !== 'string') {
|
2020-08-03 17:56:31 +03:00
|
|
|
throw new InvalidArgumentError(`key is not a string: ${key}`)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
2020-08-03 17:56:31 +03:00
|
|
|
key = key.normalize()
|
2021-12-01 23:51:08 +05:30
|
|
|
if (Array.from(key).length !== 1) {
|
2024-02-07 16:07:24 +00:00
|
|
|
throw new InvalidArgumentError(`key input is not a single code point: ${key}`)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
2020-08-03 17:56:31 +03:00
|
|
|
return key
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
2017-10-08 20:05:35 -07:00
|
|
|
/**
|
|
|
|
|
* Keyboard input device.
|
|
|
|
|
*
|
|
|
|
|
* @final
|
|
|
|
|
* @see <https://www.w3.org/TR/webdriver/#dfn-key-input-source>
|
|
|
|
|
*/
|
|
|
|
|
class Keyboard extends Device {
|
|
|
|
|
/** @param {string} id the device ID. */
|
|
|
|
|
constructor(id) {
|
2020-08-03 17:56:31 +03:00
|
|
|
super(Device.Type.KEY, id)
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
2017-12-27 11:56:08 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Generates a key down action.
|
|
|
|
|
*
|
|
|
|
|
* @param {(Key|string|number)} key the key to press. This key may be
|
|
|
|
|
* specified as a {@link Key} value, a specific unicode code point,
|
|
|
|
|
* or a string containing a single unicode code point.
|
|
|
|
|
* @return {!Action} a new key down action.
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
|
|
|
|
keyDown(key) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return { type: Action.Type.KEY_DOWN, value: checkCodePoint(key) }
|
2017-12-27 11:56:08 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Generates a key up action.
|
|
|
|
|
*
|
|
|
|
|
* @param {(Key|string|number)} key the key to press. This key may be
|
|
|
|
|
* specified as a {@link Key} value, a specific unicode code point,
|
|
|
|
|
* or a string containing a single unicode code point.
|
|
|
|
|
* @return {!Action} a new key up action.
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
|
|
|
|
keyUp(key) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return { type: Action.Type.KEY_UP, value: checkCodePoint(key) }
|
2017-12-27 11:56:08 -08:00
|
|
|
}
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/**
|
|
|
|
|
* Defines the reference point from which to compute offsets for
|
|
|
|
|
* {@linkplain ./input.Pointer#move pointer move} actions.
|
|
|
|
|
*
|
|
|
|
|
* @enum {string}
|
|
|
|
|
*/
|
|
|
|
|
const Origin = {
|
|
|
|
|
/** Compute offsets relative to the pointer's current position. */
|
|
|
|
|
POINTER: 'pointer',
|
|
|
|
|
/** Compute offsets relative to the viewport. */
|
2020-08-03 17:56:31 +03:00
|
|
|
VIEWPORT: 'viewport',
|
|
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
2017-10-08 20:05:35 -07:00
|
|
|
/**
|
|
|
|
|
* Pointer input device.
|
|
|
|
|
*
|
|
|
|
|
* @final
|
|
|
|
|
* @see <https://www.w3.org/TR/webdriver/#dfn-pointer-input-source>
|
|
|
|
|
*/
|
|
|
|
|
class Pointer extends Device {
|
|
|
|
|
/**
|
|
|
|
|
* @param {string} id the device ID.
|
|
|
|
|
* @param {Pointer.Type} type the pointer type.
|
|
|
|
|
*/
|
|
|
|
|
constructor(id, type) {
|
2020-08-03 17:56:31 +03:00
|
|
|
super(Device.Type.POINTER, id)
|
|
|
|
|
/** @private @const */ this.pointerType_ = type
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/** @override */
|
|
|
|
|
toJSON() {
|
2024-02-07 16:07:24 +00:00
|
|
|
return Object.assign({ parameters: { pointerType: this.pointerType_ } }, super.toJSON())
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @return {!Action} An action that cancels this pointer's current input.
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
|
|
|
|
cancel() {
|
2020-08-03 17:56:31 +03:00
|
|
|
return { type: Action.Type.POINTER_CANCEL }
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @param {!Button=} button The button to press.
|
2022-06-03 20:04:19 +05:30
|
|
|
* @param width
|
|
|
|
|
* @param height
|
|
|
|
|
* @param pressure
|
|
|
|
|
* @param tangentialPressure
|
|
|
|
|
* @param tiltX
|
|
|
|
|
* @param tiltY
|
|
|
|
|
* @param twist
|
|
|
|
|
* @param altitudeAngle
|
|
|
|
|
* @param azimuthAngle
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @return {!Action} An action to press the specified button with this device.
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
2022-06-02 23:41:17 +05:30
|
|
|
press(
|
|
|
|
|
button = Button.LEFT,
|
|
|
|
|
width = 0,
|
|
|
|
|
height = 0,
|
|
|
|
|
pressure = 0,
|
|
|
|
|
tangentialPressure = 0,
|
|
|
|
|
tiltX = 0,
|
|
|
|
|
tiltY = 0,
|
|
|
|
|
twist = 0,
|
|
|
|
|
altitudeAngle = 0,
|
2024-02-07 16:07:24 +00:00
|
|
|
azimuthAngle = 0,
|
2022-06-02 23:41:17 +05:30
|
|
|
) {
|
2022-02-11 11:34:47 +00:00
|
|
|
return {
|
2022-06-02 23:41:17 +05:30
|
|
|
type: Action.Type.POINTER_DOWN,
|
|
|
|
|
button,
|
|
|
|
|
width,
|
|
|
|
|
height,
|
|
|
|
|
pressure,
|
|
|
|
|
tangentialPressure,
|
|
|
|
|
tiltX,
|
|
|
|
|
tiltY,
|
|
|
|
|
twist,
|
|
|
|
|
altitudeAngle,
|
|
|
|
|
azimuthAngle,
|
2022-02-11 11:34:47 +00:00
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @param {!Button=} button The button to release.
|
|
|
|
|
* @return {!Action} An action to release the specified button with this
|
|
|
|
|
* device.
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
|
|
|
|
release(button = Button.LEFT) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return { type: Action.Type.POINTER_UP, button }
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Creates an action for moving the pointer `x` and `y` pixels from the
|
|
|
|
|
* specified `origin`. The `origin` may be defined as the pointer's
|
|
|
|
|
* {@linkplain Origin.POINTER current position}, the
|
|
|
|
|
* {@linkplain Origin.VIEWPORT viewport}, or the center of a specific
|
|
|
|
|
* {@linkplain ./webdriver.WebElement WebElement}.
|
|
|
|
|
*
|
|
|
|
|
* @param {{
|
|
|
|
|
* x: (number|undefined),
|
|
|
|
|
* y: (number|undefined),
|
|
|
|
|
* duration: (number|undefined),
|
|
|
|
|
* origin: (!Origin|!./webdriver.WebElement|undefined),
|
|
|
|
|
* }=} options the move options.
|
|
|
|
|
* @return {!Action} The new action.
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
2022-06-02 23:41:17 +05:30
|
|
|
move({
|
|
|
|
|
x = 0,
|
|
|
|
|
y = 0,
|
|
|
|
|
duration = 100,
|
|
|
|
|
origin = Origin.VIEWPORT,
|
|
|
|
|
width = 0,
|
|
|
|
|
height = 0,
|
|
|
|
|
pressure = 0,
|
|
|
|
|
tangentialPressure = 0,
|
|
|
|
|
tiltX = 0,
|
|
|
|
|
tiltY = 0,
|
|
|
|
|
twist = 0,
|
|
|
|
|
altitudeAngle = 0,
|
|
|
|
|
azimuthAngle = 0,
|
2022-02-11 11:34:47 +00:00
|
|
|
}) {
|
|
|
|
|
return {
|
2022-06-02 23:41:17 +05:30
|
|
|
type: Action.Type.POINTER_MOVE,
|
|
|
|
|
origin,
|
|
|
|
|
duration,
|
|
|
|
|
x,
|
|
|
|
|
y,
|
|
|
|
|
width,
|
|
|
|
|
height,
|
|
|
|
|
pressure,
|
|
|
|
|
tangentialPressure,
|
|
|
|
|
tiltX,
|
|
|
|
|
tiltY,
|
|
|
|
|
twist,
|
|
|
|
|
altitudeAngle,
|
|
|
|
|
azimuthAngle,
|
2022-02-11 11:34:47 +00:00
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* The supported types of pointers.
|
|
|
|
|
* @enum {string}
|
|
|
|
|
*/
|
|
|
|
|
Pointer.Type = {
|
|
|
|
|
MOUSE: 'mouse',
|
|
|
|
|
PEN: 'pen',
|
2020-08-03 17:56:31 +03:00
|
|
|
TOUCH: 'touch',
|
|
|
|
|
}
|
2017-10-08 20:05:35 -07:00
|
|
|
|
2022-02-03 13:35:44 +00:00
|
|
|
class Wheel extends Device {
|
|
|
|
|
/**
|
2022-06-03 20:04:19 +05:30
|
|
|
* @param {string} id the device ID..
|
2022-02-03 13:35:44 +00:00
|
|
|
*/
|
2022-06-03 20:04:19 +05:30
|
|
|
constructor(id) {
|
2022-02-03 13:35:44 +00:00
|
|
|
super(Device.Type.WHEEL, id)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Scrolls a page via the coordinates given
|
|
|
|
|
* @param {number} x starting x coordinate
|
|
|
|
|
* @param {number} y starting y coordinate
|
|
|
|
|
* @param {number} deltaX Delta X to scroll to target
|
|
|
|
|
* @param {number} deltaY Delta Y to scroll to target
|
2022-06-03 20:04:19 +05:30
|
|
|
* @param {WebElement} origin element origin
|
2022-02-03 13:35:44 +00:00
|
|
|
* @param {number} duration duration ratio be the ratio of time delta and duration
|
|
|
|
|
* @returns {!Action} An action to scroll with this device.
|
|
|
|
|
*/
|
|
|
|
|
scroll(x, y, deltaX, deltaY, origin, duration) {
|
|
|
|
|
return {
|
|
|
|
|
type: Action.Type.SCROLL,
|
2022-06-02 23:41:17 +05:30
|
|
|
duration: duration,
|
|
|
|
|
x: x,
|
|
|
|
|
y: y,
|
|
|
|
|
deltaX: deltaX,
|
|
|
|
|
deltaY: deltaY,
|
|
|
|
|
origin: origin,
|
2022-02-03 13:35:44 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-08 20:05:35 -07:00
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* User facing API for generating complex user gestures. This class should not
|
|
|
|
|
* be instantiated directly. Instead, users should create new instances by
|
|
|
|
|
* calling {@link ./webdriver.WebDriver#actions WebDriver.actions()}.
|
|
|
|
|
*
|
|
|
|
|
* ### Action Ticks
|
|
|
|
|
*
|
|
|
|
|
* Action sequences are divided into a series of "ticks". At each tick, the
|
|
|
|
|
* WebDriver remote end will perform a single action for each device included
|
|
|
|
|
* in the action sequence. At tick 0, the driver will perform the first action
|
|
|
|
|
* defined for each device, at tick 1 the second action for each device, and
|
|
|
|
|
* so on until all actions have been executed. If an individual device does
|
|
|
|
|
* not have an action defined at a particular tick, it will automatically
|
|
|
|
|
* pause.
|
|
|
|
|
*
|
|
|
|
|
* By default, action sequences will be synchronized so only one device has a
|
|
|
|
|
* define action in each tick. Consider the following code sample:
|
|
|
|
|
*
|
|
|
|
|
* const actions = driver.actions();
|
|
|
|
|
*
|
|
|
|
|
* await actions
|
|
|
|
|
* .keyDown(SHIFT)
|
|
|
|
|
* .move({origin: el})
|
|
|
|
|
* .press()
|
|
|
|
|
* .release()
|
|
|
|
|
* .keyUp(SHIFT)
|
|
|
|
|
* .perform();
|
|
|
|
|
*
|
|
|
|
|
* This sample produces the following sequence of ticks:
|
|
|
|
|
*
|
|
|
|
|
* | Device | Tick 1 | Tick 2 | Tick 3 | Tick 4 | Tick 5 |
|
|
|
|
|
* | -------- | -------------- | ------------------ | ------- | --------- | ------------ |
|
|
|
|
|
* | Keyboard | keyDown(SHIFT) | pause() | pause() | pause() | keyUp(SHIFT) |
|
|
|
|
|
* | Mouse | pause() | move({origin: el}) | press() | release() | pause() |
|
|
|
|
|
*
|
|
|
|
|
* If you'd like the remote end to execute actions with multiple devices
|
|
|
|
|
* simultaneously, you may pass `{async: true}` when creating the actions
|
|
|
|
|
* builder. With synchronization disabled (`{async: true}`), the ticks from our
|
|
|
|
|
* previous example become:
|
|
|
|
|
*
|
|
|
|
|
* | Device | Tick 1 | Tick 2 | Tick 3 |
|
|
|
|
|
* | -------- | ------------------ | ------------ | --------- |
|
|
|
|
|
* | Keyboard | keyDown(SHIFT) | keyUp(SHIFT) | |
|
|
|
|
|
* | Mouse | move({origin: el}) | press() | release() |
|
|
|
|
|
*
|
|
|
|
|
* When synchronization is disabled, it is your responsibility to insert
|
|
|
|
|
* {@linkplain #pause() pauses} for each device, as needed:
|
|
|
|
|
*
|
|
|
|
|
* const actions = driver.actions({async: true});
|
|
|
|
|
* const kb = actions.keyboard();
|
|
|
|
|
* const mouse = actions.mouse();
|
|
|
|
|
*
|
|
|
|
|
* actions.keyDown(SHIFT).pause(kb).pause(kb).key(SHIFT);
|
|
|
|
|
* actions.pause(mouse).move({origin: el}).press().release();
|
|
|
|
|
* actions.perform();
|
|
|
|
|
*
|
|
|
|
|
* With pauses insert for individual devices, we're back to:
|
|
|
|
|
*
|
|
|
|
|
* | Device | Tick 1 | Tick 2 | Tick 3 | Tick 4 |
|
|
|
|
|
* | -------- | -------------- | ------------------ | ------- | ------------ |
|
|
|
|
|
* | Keyboard | keyDown(SHIFT) | pause() | pause() | keyUp(SHIFT) |
|
|
|
|
|
* | Mouse | pause() | move({origin: el}) | press() | release() |
|
|
|
|
|
*
|
|
|
|
|
* #### Tick Durations
|
|
|
|
|
*
|
|
|
|
|
* The length of each action tick is however long it takes the remote end to
|
|
|
|
|
* execute the actions for every device in that tick. Most actions are
|
2019-12-07 00:51:57 +05:30
|
|
|
* "instantaneous", however, {@linkplain #pause pause} and
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* {@linkplain #move pointer move} actions allow you to specify a duration for
|
|
|
|
|
* how long that action should take. The remote end will always wait for all
|
|
|
|
|
* actions within a tick to finish before starting the next tick, so a device
|
|
|
|
|
* may implicitly pause while waiting for other devices to finish.
|
|
|
|
|
*
|
|
|
|
|
* | Device | Tick 1 | Tick 2 |
|
|
|
|
|
* | --------- | --------------------- | ------- |
|
|
|
|
|
* | Pointer 1 | move({duration: 200}) | press() |
|
|
|
|
|
* | Pointer 2 | move({duration: 300}) | press() |
|
|
|
|
|
*
|
|
|
|
|
* In table above, the move for Pointer 1 should only take 200 ms, but the
|
|
|
|
|
* remote end will wait for the move for Pointer 2 to finish
|
|
|
|
|
* (an additional 100 ms) before proceeding to Tick 2.
|
2017-10-08 20:05:35 -07:00
|
|
|
*
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* This implicit waiting also applies to pauses. In the table below, even though
|
|
|
|
|
* the keyboard only defines a pause of 100 ms, the remote end will wait an
|
2019-12-07 00:51:57 +05:30
|
|
|
* additional 200 ms for the mouse move to finish before moving to Tick 2.
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
*
|
|
|
|
|
* | Device | Tick 1 | Tick 2 |
|
|
|
|
|
* | -------- | --------------------- | -------------- |
|
|
|
|
|
* | Keyboard | pause(100) | keyDown(SHIFT) |
|
|
|
|
|
* | Mouse | move({duration: 300}) | |
|
|
|
|
|
*
|
|
|
|
|
* [client rect]: https://developer.mozilla.org/en-US/docs/Web/API/Element/getClientRects
|
|
|
|
|
* [bounding client rect]: https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect
|
|
|
|
|
*
|
|
|
|
|
* @final
|
2017-10-08 20:05:35 -07:00
|
|
|
* @see <https://www.w3.org/TR/webdriver/#actions>
|
|
|
|
|
*/
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
class Actions {
|
2017-12-20 22:07:25 -08:00
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @param {!Executor} executor The object to execute the configured
|
|
|
|
|
* actions with.
|
2021-04-08 14:35:11 +05:30
|
|
|
* @param {{async: (boolean|undefined)}} options Options for this action
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* sequence (see class description for details).
|
2017-12-20 22:07:25 -08:00
|
|
|
*/
|
2021-04-08 14:35:11 +05:30
|
|
|
constructor(executor, { async = false } = {}) {
|
2017-10-08 20:05:35 -07:00
|
|
|
/** @private @const */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.executor_ = executor
|
2017-10-08 20:05:35 -07:00
|
|
|
|
2017-12-20 22:07:25 -08:00
|
|
|
/** @private @const */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.sync_ = !async
|
2017-12-20 22:07:25 -08:00
|
|
|
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @private @const */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.keyboard_ = new Keyboard('default keyboard')
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
|
|
|
|
/** @private @const */
|
2020-08-03 17:56:31 +03:00
|
|
|
this.mouse_ = new Pointer('default mouse', Pointer.Type.MOUSE)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
2022-02-03 13:35:44 +00:00
|
|
|
/** @private @const */
|
|
|
|
|
this.wheel_ = new Wheel('default wheel')
|
|
|
|
|
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @private @const {!Map<!Device, !Array<!Action>>} */
|
|
|
|
|
this.sequences_ = new Map([
|
|
|
|
|
[this.keyboard_, []],
|
|
|
|
|
[this.mouse_, []],
|
2022-02-03 13:35:44 +00:00
|
|
|
[this.wheel_, []],
|
2020-08-03 17:56:31 +03:00
|
|
|
])
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @return {!Keyboard} the keyboard device handle. */
|
|
|
|
|
keyboard() {
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.keyboard_
|
2017-12-20 22:07:25 -08:00
|
|
|
}
|
|
|
|
|
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
/** @return {!Pointer} the mouse pointer device handle. */
|
|
|
|
|
mouse() {
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.mouse_
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
2022-02-03 13:35:44 +00:00
|
|
|
/** @return {!Wheel} the wheel device handle. */
|
|
|
|
|
wheel() {
|
|
|
|
|
return this.wheel_
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-08 20:05:35 -07:00
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @param {!Device} device
|
|
|
|
|
* @return {!Array<!Action>}
|
|
|
|
|
* @private
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
sequence_(device) {
|
2020-08-03 17:56:31 +03:00
|
|
|
let sequence = this.sequences_.get(device)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
if (!sequence) {
|
2020-08-03 17:56:31 +03:00
|
|
|
sequence = []
|
|
|
|
|
this.sequences_.set(device, sequence)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
2020-08-03 17:56:31 +03:00
|
|
|
return sequence
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Appends `actions` to the end of the current sequence for the given
|
|
|
|
|
* `device`. If device synchronization is enabled, after inserting the
|
|
|
|
|
* actions, pauses will be inserted for all other devices to ensure all action
|
|
|
|
|
* sequences are the same length.
|
|
|
|
|
*
|
|
|
|
|
* @param {!Device} device the device to update.
|
|
|
|
|
* @param {...!Action} actions the actions to insert.
|
|
|
|
|
* @return {!Actions} a self reference.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
insert(device, ...actions) {
|
2020-08-03 17:56:31 +03:00
|
|
|
this.sequence_(device).push(...actions)
|
|
|
|
|
return this.sync_ ? this.synchronize() : this
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Ensures the action sequence for every device referenced in this action
|
|
|
|
|
* sequence is the same length. For devices whose sequence is too short,
|
|
|
|
|
* this will insert {@linkplain #pause pauses} so that every device has an
|
|
|
|
|
* explicit action defined at each tick.
|
2017-10-08 20:05:35 -07:00
|
|
|
*
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @param {...!Device} devices The specific devices to synchronize.
|
|
|
|
|
* If unspecified, the action sequences for every device will be
|
|
|
|
|
* synchronized.
|
|
|
|
|
* @return {!Actions} a self reference.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
synchronize(...devices) {
|
2020-08-03 17:56:31 +03:00
|
|
|
let sequences
|
|
|
|
|
let max = 0
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
if (devices.length === 0) {
|
|
|
|
|
for (const s of this.sequences_.values()) {
|
2020-08-03 17:56:31 +03:00
|
|
|
max = Math.max(max, s.length)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
2020-08-03 17:56:31 +03:00
|
|
|
sequences = this.sequences_.values()
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
} else {
|
2020-08-03 17:56:31 +03:00
|
|
|
sequences = []
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
for (const device of devices) {
|
2020-08-03 17:56:31 +03:00
|
|
|
const seq = this.sequence_(device)
|
|
|
|
|
max = Math.max(max, seq.length)
|
|
|
|
|
sequences.push(seq)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
}
|
2017-12-27 11:56:08 -08:00
|
|
|
|
2020-08-03 17:56:31 +03:00
|
|
|
const pause = { type: Action.Type.PAUSE, duration: 0 }
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
for (const seq of sequences) {
|
|
|
|
|
while (seq.length < max) {
|
2020-08-03 17:56:31 +03:00
|
|
|
seq.push(pause)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
}
|
2017-12-27 11:56:08 -08:00
|
|
|
|
2020-08-03 17:56:31 +03:00
|
|
|
return this
|
2017-12-27 11:56:08 -08:00
|
|
|
}
|
|
|
|
|
|
2017-12-20 22:07:25 -08:00
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Inserts a pause action for the specified devices, ensuring each device is
|
|
|
|
|
* idle for a tick. The length of the pause (in milliseconds) may be specified
|
|
|
|
|
* as the first parameter to this method (defaults to 0). Otherwise, you may
|
|
|
|
|
* just specify the individual devices that should pause.
|
|
|
|
|
*
|
|
|
|
|
* If no devices are specified, a pause action will be created (using the same
|
|
|
|
|
* duration) for every device.
|
|
|
|
|
*
|
2019-12-07 00:51:57 +05:30
|
|
|
* When device synchronization is enabled (the default for new {@link Actions}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* objects), there is no need to specify devices as pausing one automatically
|
|
|
|
|
* pauses the others for the same duration. In other words, the following are
|
|
|
|
|
* all equivalent:
|
|
|
|
|
*
|
|
|
|
|
* let a1 = driver.actions();
|
|
|
|
|
* a1.pause(100).perform();
|
|
|
|
|
*
|
|
|
|
|
* let a2 = driver.actions();
|
|
|
|
|
* a2.pause(100, a2.keyboard()).perform();
|
|
|
|
|
* // Synchronization ensures a2.mouse() is automatically paused too.
|
|
|
|
|
*
|
|
|
|
|
* let a3 = driver.actions();
|
|
|
|
|
* a3.pause(100, a3.keyboard(), a3.mouse()).perform();
|
|
|
|
|
*
|
|
|
|
|
* When device synchronization is _disabled_, you can cause individual devices
|
|
|
|
|
* to pause during a tick. For example, to hold the SHIFT key down while
|
|
|
|
|
* moving the mouse:
|
|
|
|
|
*
|
|
|
|
|
* let actions = driver.actions({async: true});
|
|
|
|
|
*
|
|
|
|
|
* actions.keyDown(Key.SHIFT);
|
|
|
|
|
* actions.pause(actions.mouse()) // Pause for shift down
|
|
|
|
|
* .press(Button.LEFT)
|
|
|
|
|
* .move({x: 10, y: 10})
|
|
|
|
|
* .release(Button.LEFT);
|
|
|
|
|
* actions
|
|
|
|
|
* .pause(
|
|
|
|
|
* actions.keyboard(), // Pause for press left
|
|
|
|
|
* actions.keyboard(), // Pause for move
|
|
|
|
|
* actions.keyboard()) // Pause for release left
|
|
|
|
|
* .keyUp(Key.SHIFT);
|
|
|
|
|
* await actions.perform();
|
|
|
|
|
*
|
|
|
|
|
* @param {(number|!Device)=} duration The length of the pause to insert, in
|
|
|
|
|
* milliseconds. Alternatively, the duration may be omitted (yielding a
|
|
|
|
|
* default 0 ms pause), and the first device to pause may be specified.
|
|
|
|
|
* @param {...!Device} devices The devices to insert the pause for. If no
|
|
|
|
|
* devices are specified, the pause will be inserted for _all_ devices.
|
|
|
|
|
* @return {!Actions} a self reference.
|
2017-12-20 22:07:25 -08:00
|
|
|
*/
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
pause(duration, ...devices) {
|
|
|
|
|
if (duration instanceof Device) {
|
2020-08-03 17:56:31 +03:00
|
|
|
devices.push(duration)
|
|
|
|
|
duration = 0
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
} else if (!duration) {
|
2020-08-03 17:56:31 +03:00
|
|
|
duration = 0
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
2020-08-03 17:56:31 +03:00
|
|
|
const action = { type: Action.Type.PAUSE, duration }
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
|
|
|
|
// NB: need a properly typed variable for type checking.
|
|
|
|
|
/** @type {!Iterable<!Device>} */
|
2020-08-03 17:56:31 +03:00
|
|
|
const iterable = devices.length === 0 ? this.sequences_.keys() : devices
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
for (const device of iterable) {
|
2020-08-03 17:56:31 +03:00
|
|
|
this.sequence_(device).push(action)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.sync_ ? this.synchronize() : this
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Inserts an action to press a single key.
|
|
|
|
|
*
|
2017-10-08 20:05:35 -07:00
|
|
|
* @param {(Key|string|number)} key the key to press. This key may be
|
|
|
|
|
* specified as a {@link Key} value, a specific unicode code point,
|
|
|
|
|
* or a string containing a single unicode code point.
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @return {!Actions} a self reference.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
|
|
|
|
keyDown(key) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.insert(this.keyboard_, this.keyboard_.keyDown(key))
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Inserts an action to release a single key.
|
|
|
|
|
*
|
2017-10-08 20:05:35 -07:00
|
|
|
* @param {(Key|string|number)} key the key to release. This key may be
|
|
|
|
|
* specified as a {@link Key} value, a specific unicode code point,
|
|
|
|
|
* or a string containing a single unicode code point.
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @return {!Actions} a self reference.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
|
|
|
|
keyUp(key) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.insert(this.keyboard_, this.keyboard_.keyUp(key))
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Inserts a sequence of actions to type the provided key sequence.
|
2017-10-08 20:05:35 -07:00
|
|
|
* For each key, this will record a pair of {@linkplain #keyDown keyDown}
|
|
|
|
|
* and {@linkplain #keyUp keyUp} actions. An implication of this pairing
|
|
|
|
|
* is that modifier keys (e.g. {@link ./input.Key.SHIFT Key.SHIFT}) will
|
|
|
|
|
* always be immediately released. In other words, `sendKeys(Key.SHIFT, 'a')`
|
|
|
|
|
* is the same as typing `sendKeys('a')`, _not_ `sendKeys('A')`.
|
|
|
|
|
*
|
|
|
|
|
* @param {...(Key|string|number)} keys the keys to type.
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @return {!Actions} a self reference.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
|
|
|
|
sendKeys(...keys) {
|
2022-08-17 00:17:49 +05:30
|
|
|
const { WebElement } = require('./webdriver')
|
|
|
|
|
|
2020-08-03 17:56:31 +03:00
|
|
|
const actions = []
|
2022-08-22 19:42:48 +03:00
|
|
|
if (keys.length > 1 && keys[0] instanceof WebElement) {
|
|
|
|
|
this.click(keys[0])
|
2022-08-17 00:17:49 +05:30
|
|
|
keys.shift()
|
|
|
|
|
}
|
2017-10-08 20:05:35 -07:00
|
|
|
for (const key of keys) {
|
|
|
|
|
if (typeof key === 'string') {
|
|
|
|
|
for (const symbol of key) {
|
2024-02-07 16:07:24 +00:00
|
|
|
actions.push(this.keyboard_.keyDown(symbol), this.keyboard_.keyUp(symbol))
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
} else {
|
2020-08-03 17:56:31 +03:00
|
|
|
actions.push(this.keyboard_.keyDown(key), this.keyboard_.keyUp(key))
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
}
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.insert(this.keyboard_, ...actions)
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
2017-12-20 22:07:25 -08:00
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Inserts an action to press a mouse button at the mouse's current location.
|
2017-10-08 20:05:35 -07:00
|
|
|
*
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @param {!Button=} button The button to press; defaults to `LEFT`.
|
|
|
|
|
* @return {!Actions} a self reference.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
2017-12-27 11:56:08 -08:00
|
|
|
press(button = Button.LEFT) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.insert(this.mouse_, this.mouse_.press(button))
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* Inserts an action to release a mouse button at the mouse's current
|
|
|
|
|
* location.
|
2017-10-08 20:05:35 -07:00
|
|
|
*
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
* @param {!Button=} button The button to release; defaults to `LEFT`.
|
|
|
|
|
* @return {!Actions} a self reference.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
2017-12-27 11:56:08 -08:00
|
|
|
release(button = Button.LEFT) {
|
2020-08-03 17:56:31 +03:00
|
|
|
return this.insert(this.mouse_, this.mouse_.release(button))
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2022-02-03 13:35:44 +00:00
|
|
|
* scrolls a page via the coordinates given
|
|
|
|
|
* @param {number} x starting x coordinate
|
|
|
|
|
* @param {number} y starting y coordinate
|
|
|
|
|
* @param {number} deltax delta x to scroll to target
|
|
|
|
|
* @param {number} deltay delta y to scroll to target
|
|
|
|
|
* @param {number} duration duration ratio be the ratio of time delta and duration
|
2022-06-03 20:04:19 +05:30
|
|
|
* @returns {!Actions} An action to scroll with this device.
|
2017-10-08 20:05:35 -07:00
|
|
|
*/
|
2022-02-03 13:47:03 +00:00
|
|
|
scroll(x, y, targetDeltaX, targetDeltaY, origin, duration) {
|
2024-02-07 16:07:24 +00:00
|
|
|
return this.insert(this.wheel_, this.wheel_.scroll(x, y, targetDeltaX, targetDeltaY, origin, duration))
|
2022-02-03 13:47:03 +00:00
|
|
|
}
|
2017-10-08 20:05:35 -07:00
|
|
|
|
2022-02-03 13:47:03 +00:00
|
|
|
/**
|
|
|
|
|
* Inserts an action for moving the mouse `x` and `y` pixels relative to the
|
|
|
|
|
* specified `origin`. The `origin` may be defined as the mouse's
|
2022-06-27 09:57:26 +01:00
|
|
|
* {@linkplain ./input.Origin.POINTER current position}, the top-left corner of the
|
2022-02-03 13:47:03 +00:00
|
|
|
* {@linkplain ./input.Origin.VIEWPORT viewport}, or the center of a specific
|
2022-06-27 09:57:26 +01:00
|
|
|
* {@linkplain ./webdriver.WebElement WebElement}. Default is top left corner of the view-port if origin is not specified
|
2022-02-03 13:47:03 +00:00
|
|
|
*
|
|
|
|
|
* You may adjust how long the remote end should take, in milliseconds, to
|
|
|
|
|
* perform the move using the `duration` parameter (defaults to 100 ms).
|
|
|
|
|
* The number of incremental move events generated over this duration is an
|
|
|
|
|
* implementation detail for the remote end.
|
|
|
|
|
*
|
|
|
|
|
* @param {{
|
|
|
|
|
* x: (number|undefined),
|
|
|
|
|
* y: (number|undefined),
|
|
|
|
|
* duration: (number|undefined),
|
|
|
|
|
* origin: (!Origin|!./webdriver.WebElement|undefined),
|
|
|
|
|
* }=} options The move options. Defaults to moving the mouse to the top-left
|
|
|
|
|
* corner of the viewport over 100ms.
|
|
|
|
|
* @return {!Actions} a self reference.
|
|
|
|
|
*/
|
|
|
|
|
move({ x = 0, y = 0, duration = 100, origin = Origin.VIEWPORT } = {}) {
|
2024-02-07 16:07:24 +00:00
|
|
|
return this.insert(this.mouse_, this.mouse_.move({ x, y, duration, origin }))
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
2022-02-03 13:47:03 +00:00
|
|
|
/**
|
|
|
|
|
* Short-hand for performing a simple left-click (down/up) with the mouse.
|
|
|
|
|
*
|
|
|
|
|
* @param {./webdriver.WebElement=} element If specified, the mouse will
|
|
|
|
|
* first be moved to the center of the element before performing the
|
|
|
|
|
* click.
|
|
|
|
|
* @return {!Actions} a self reference.
|
|
|
|
|
*/
|
|
|
|
|
click(element) {
|
|
|
|
|
if (element) {
|
|
|
|
|
this.move({ origin: element })
|
|
|
|
|
}
|
|
|
|
|
return this.press().release()
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
2022-02-03 13:47:03 +00:00
|
|
|
/**
|
|
|
|
|
* Short-hand for performing a simple right-click (down/up) with the mouse.
|
|
|
|
|
*
|
|
|
|
|
* @param {./webdriver.WebElement=} element If specified, the mouse will
|
|
|
|
|
* first be moved to the center of the element before performing the
|
|
|
|
|
* click.
|
|
|
|
|
* @return {!Actions} a self reference.
|
|
|
|
|
*/
|
|
|
|
|
contextClick(element) {
|
|
|
|
|
if (element) {
|
|
|
|
|
this.move({ origin: element })
|
|
|
|
|
}
|
|
|
|
|
return this.press(Button.RIGHT).release(Button.RIGHT)
|
|
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
2022-02-03 13:47:03 +00:00
|
|
|
/**
|
|
|
|
|
* Short-hand for performing a double left-click with the mouse.
|
|
|
|
|
*
|
|
|
|
|
* @param {./webdriver.WebElement=} element If specified, the mouse will
|
|
|
|
|
* first be moved to the center of the element before performing the
|
|
|
|
|
* click.
|
|
|
|
|
* @return {!Actions} a self reference.
|
|
|
|
|
*/
|
|
|
|
|
doubleClick(element) {
|
|
|
|
|
return this.click(element).press().release()
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
|
2022-02-03 13:47:03 +00:00
|
|
|
/**
|
|
|
|
|
* Configures a drag-and-drop action consisting of the following steps:
|
|
|
|
|
*
|
|
|
|
|
* 1. Move to the center of the `from` element (element to be dragged).
|
|
|
|
|
* 2. Press the left mouse button.
|
|
|
|
|
* 3. If the `to` target is a {@linkplain ./webdriver.WebElement WebElement},
|
|
|
|
|
* move the mouse to its center. Otherwise, move the mouse by the
|
|
|
|
|
* specified offset.
|
|
|
|
|
* 4. Release the left mouse button.
|
|
|
|
|
*
|
|
|
|
|
* @param {!./webdriver.WebElement} from The element to press the left mouse
|
|
|
|
|
* button on to start the drag.
|
|
|
|
|
* @param {(!./webdriver.WebElement|{x: number, y: number})} to Either another
|
|
|
|
|
* element to drag to (will drag to the center of the element), or an
|
|
|
|
|
* object specifying the offset to drag by, in pixels.
|
|
|
|
|
* @return {!Actions} a self reference.
|
|
|
|
|
*/
|
|
|
|
|
dragAndDrop(from, to) {
|
|
|
|
|
// Do not require up top to avoid a cycle that breaks static analysis.
|
|
|
|
|
const { WebElement } = require('./webdriver')
|
2024-02-07 16:07:24 +00:00
|
|
|
if (!(to instanceof WebElement) && (!to || typeof to.x !== 'number' || typeof to.y !== 'number')) {
|
|
|
|
|
throw new InvalidArgumentError('Invalid drag target; must specify a WebElement or {x, y} offset')
|
2022-02-03 13:47:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
this.move({ origin: from }).press()
|
|
|
|
|
if (to instanceof WebElement) {
|
|
|
|
|
this.move({ origin: to })
|
|
|
|
|
} else {
|
|
|
|
|
this.move({ x: to.x, y: to.y, origin: Origin.POINTER })
|
|
|
|
|
}
|
|
|
|
|
return this.release()
|
2022-02-03 13:35:44 +00:00
|
|
|
}
|
|
|
|
|
|
2022-02-03 13:47:03 +00:00
|
|
|
/**
|
|
|
|
|
* Releases all keys, pointers, and clears internal state.
|
|
|
|
|
*
|
|
|
|
|
* @return {!Promise<void>} a promise that will resolve when finished
|
|
|
|
|
* clearing all action state.
|
|
|
|
|
*/
|
|
|
|
|
clear() {
|
|
|
|
|
for (const s of this.sequences_.values()) {
|
|
|
|
|
s.length = 0
|
|
|
|
|
}
|
|
|
|
|
return this.executor_.execute(new Command(Name.CLEAR_ACTIONS))
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Performs the configured action sequence.
|
|
|
|
|
*
|
|
|
|
|
* @return {!Promise<void>} a promise that will resolve when all actions have
|
|
|
|
|
* been completed.
|
|
|
|
|
*/
|
|
|
|
|
async perform() {
|
2022-02-03 13:47:03 +00:00
|
|
|
const _actions = []
|
|
|
|
|
this.sequences_.forEach((actions, device) => {
|
|
|
|
|
if (!isIdle(actions)) {
|
|
|
|
|
actions = actions.concat() // Defensive copy.
|
|
|
|
|
_actions.push(Object.assign({ actions }, device.toJSON()))
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
if (_actions.length === 0) {
|
|
|
|
|
return Promise.resolve()
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
2024-02-07 16:07:24 +00:00
|
|
|
await this.executor_.execute(new Command(Name.ACTIONS).setParameter('actions', _actions))
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
2023-12-26 19:15:43 +05:30
|
|
|
|
|
|
|
|
getSequences() {
|
|
|
|
|
const _actions = []
|
|
|
|
|
this.sequences_.forEach((actions, device) => {
|
|
|
|
|
if (!isIdle(actions)) {
|
|
|
|
|
actions = actions.concat()
|
|
|
|
|
_actions.push(Object.assign({ actions }, device.toJSON()))
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
return _actions
|
|
|
|
|
}
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @param {!Array<!Action>} actions
|
|
|
|
|
* @return {boolean}
|
|
|
|
|
*/
|
|
|
|
|
function isIdle(actions) {
|
2024-02-07 16:07:24 +00:00
|
|
|
return actions.length === 0 || actions.every((a) => a.type === Action.Type.PAUSE && !a.duration)
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Script used to compute the offset from the center of a DOM element's first
|
|
|
|
|
* client rect from the top-left corner of the element's bounding client rect.
|
|
|
|
|
* The element's center point is computed using the algorithm defined here:
|
|
|
|
|
* <https://w3c.github.io/webdriver/webdriver-spec.html#dfn-center-point>.
|
|
|
|
|
*
|
|
|
|
|
* __This is only exported for use in internal unit tests. DO NOT USE.__
|
|
|
|
|
*
|
|
|
|
|
* @package
|
|
|
|
|
*/
|
|
|
|
|
const INTERNAL_COMPUTE_OFFSET_SCRIPT = `
|
|
|
|
|
function computeOffset(el) {
|
|
|
|
|
var rect = el.getClientRects()[0];
|
|
|
|
|
var left = Math.max(0, Math.min(rect.x, rect.x + rect.width));
|
|
|
|
|
var right =
|
|
|
|
|
Math.min(window.innerWidth, Math.max(rect.x, rect.x + rect.width));
|
|
|
|
|
var top = Math.max(0, Math.min(rect.y, rect.y + rect.height));
|
|
|
|
|
var bot =
|
|
|
|
|
Math.min(window.innerHeight, Math.max(rect.y, rect.y + rect.height));
|
|
|
|
|
var x = Math.floor(0.5 * (left + right));
|
|
|
|
|
var y = Math.floor(0.5 * (top + bot));
|
|
|
|
|
|
|
|
|
|
var bbox = el.getBoundingClientRect();
|
|
|
|
|
return [x - bbox.left, y - bbox.top];
|
2017-10-08 20:05:35 -07:00
|
|
|
}
|
2020-08-03 17:56:31 +03:00
|
|
|
return computeOffset(arguments[0]);`
|
2017-10-08 20:05:35 -07:00
|
|
|
|
2016-01-30 08:50:46 -08:00
|
|
|
// PUBLIC API
|
|
|
|
|
|
2016-03-12 11:49:57 -08:00
|
|
|
module.exports = {
|
2020-08-03 17:56:31 +03:00
|
|
|
Action, // For documentation only.
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
Actions,
|
2017-10-08 20:05:35 -07:00
|
|
|
Button,
|
|
|
|
|
Device,
|
|
|
|
|
Key,
|
|
|
|
|
Keyboard,
|
|
|
|
|
FileDetector,
|
|
|
|
|
Origin,
|
|
|
|
|
Pointer,
|
[js] Another pass at the new actions API for #4564
The previous iteration heavily favored sequences where multiple devices acted
in each tick. This also made it too difficult for "simple" sequences like
"press SHIFT, move the mouse (0, 30), press LEFT, release LEFT, etc." This new
version goes back to favoring simple, synchronous sequences, but still allows
configuring async sequences.
The new input.Actions class API is largely compatible with
actions.LegacyActionSequence, however, the mouse methods have been renamed to
force a breakage since there is a change in parameters.
The new API still supports translating mouse+keyboard sequences to the legacy
protocol, but users have to explicitly request this when the sequence is first
created (translation is opt-in because it's not 100%; known issues are all
covered in the input.Actions class doc)
2018-01-07 18:33:43 -08:00
|
|
|
INTERNAL_COMPUTE_OFFSET_SCRIPT,
|
2020-08-03 17:56:31 +03:00
|
|
|
}
|
