Re: Actions questions

On 09/05/16 19:05, James Graham wrote:
> On 09/05/16 17:40, Andreas Tolfsen wrote:
>> On Fri, 29 Apr 2016, at 16:56, James Graham wrote:
>>> For an input device like a pointer, the pointer can clearly only do one
>>> thing at a time. For a keyboard that is less true. Should it be possible
>>> to have multiple concurrent action chains corresponding to the "same"
>>> keyboard?
>>
>> Because each input device needs to be uniquely identified with an ID,
>> for example to maintain modifier key state, we shouldn’t allow multiple
>> action chains for the same device.
>>
>> However, in practical terms this doesn’t matter as the desired output
>> are just DOM events. We need to disallow it for race condition reasons
>> in the WebDriver abstraction we’re creating, so that the same keyboard
>> references in two concurrent actions do not perform a keyUp("shift") and
>> keyDown("shift") operation in the same tick.
> 
> I don't think that's true. I imagine that the concurrency isn't "real"
> i.e. if you get three actions to perform in the same tick, they won't
> generate events in a random order, but in a well-defined order e.g.
> top-to-bottom. So if you happened to send
> 
> {actions:
> [
> [{id: 1, type: key, actions: [{type: keyDown, value: a}],
> [{id: 1, type: key, actions: [{type: keyUp, value: a}],
> ]
> }
> 
> you would always get the keyDown event before the keyUp event.
> 
> It may be that we don't care about being able to chord in this way, and
> that one-after-another in separate ticks is good enough, in which case
> disallowing this would be OK.

You are correct that we should have a well-defined ordering. I imagine a
sane execution order is, for each tick, the action for each device in
term one-after-another. That is, not reordering the input based on for
example device ID or type.

With respect to my earlier point, however, if you read the following
action sequence it’s not obvious that the second sequence cancels the
first’s shift down since modifier state would be associated with a
uniquely identifiable device:

{actions: [
  [{id: 1, type: key, actions: [{type: keyDown, value: shift},
                                {type: pause},
                                {type: keyDown, value: a}],
  [{id: 1, type: key, actions: [{type: keyDown, value: b},
                                {type: keyUp, value: shift},
                                {type: pause}]
]}

This might produce "Ba", and not "Ab" as one might expect.

However, I guess _disallowing_ that input might not actually be needed
since such a “sanity check” for duplicate devices could be made in the
local end. For this reason, please disregard my earlier point.

>>>> The client bindings set the focus on the element and then the rest is
>>>> assumed that you are working on the active element. See
>>>> https://github.com/SeleniumHQ/selenium/blob/master/py/selenium/webdriver/common/action_chains.py#L156
>>>>
>>>> as an example
>>>
>>> OK, so there is no way to supply an element with the action, or change
>>> the element mid action chain without dispatching actions that will do
>>> so.
>>
>> What David says here is not strictly true. The Java Actions API allows
>> you to move the mouse to a given web element.
> 
> So what's the desired functionality here?

I personally think it is valuable to be able to move a pointer-type
cursor (finger, mouse, stylus) to an element’s location and by offset
from an element’s location:

    moveToElement(element, [xOffset, yOffset])

>>> It's not yet clear to me exactly what effect the choice of keyboard
>>> layout has if you can send any codepoint as the 'key' to press. Maybe
>>> someone can fill me in?
>>
>> This is a grey area. Selenium assumes a US keyboard layout, in the sense
>> that it only converts [a-z] to [A-Z] when shift is pressed.
>>
>> Perhaps we need to be clearer about this?
> 
> OK, so I read some more here, and the issue seems to be that we need to
> populate various event various attributes related to the physical
> location on the keyboard and the key that was pressed (e.g. 'a' if the
> character is 'A'). So a simple approach would be to start by specifying
> a US keyboard layout for the purposes of that translation and, in some
> future revision of the spec, making it possible to specify the keyboard
> layout somehow (either as a global or as part of the actions API).
> However this still leaves several open questions, like how to
> translation an action with value: ☃ into a key event.

Yes, I like the approach of making the specification extensible at a
later date.

A future API that would let you select a keyboard layout similarly to
how you set a script’s global timeout duration would be nice.

Received on Wednesday, 11 May 2016 16:50:11 UTC