- From: Andreas Tolfsen <ato@mozilla.com>
- Date: Wed, 27 Apr 2016 11:43:09 +0100
- To: public-browser-tools-testing@w3.org
Tue, 26 Apr 2016 17:50:05 -0700 Jason Juang <juangj@google.com>:
> On Wed, Apr 20, 2016 at 1:08 PM, David Burns <dburns@mozilla.com>
> wrote:
> > Is it expected that the keyboard model has key repetition e.g. if I
> > do
> >>
> >> [[{keyDown a}, {pause 10}, {keyUp a}]]
> >>
> >> when the focus is on an input control, how many "a" characters
> >> should I see?
> >
> > Originally I didnt think of this but I guess, from my previous
> > answer above I think we should see a "few" a's
>
> If you split up the action chain and send
>
> [[{keyDown a}]]
>
> then wait, say, 5 real-time seconds, and then send
>
> [[{keyUp a}]]
>
> should you expect that the key repeats during the entire interval
> between the actions? Or does the key only repeat if there is an
> explicit pause command?
James and I discussed this the other day and reached the conclusion it
should not.
Whilst it is possible to fake holding down a key by factoring in the
frame rate and the OS key repeat rate to generate x DOM events over the
course of y seconds, this quickly gets us into the realm of reproducing
realistic time frames.
The way the action chain ticks are explained in the specification now,
each tick is relative to the time taken to perform the longest
individual action in a slice. This is fundamentally incompatible with a
wall-clock interpretation where we would essentially have to guarantee
the duration of each tick.
The mouseMove action is related: It lets you to move the mouse cursor
from one point to another, but does little to ensure a smooth path
finding transition between those points. In other words, there is no
“trail of events” being generated between those two points.
So instead of thinking about actions as a time-spatial representation
of input, it’s better to think of it as a mental model to map parallel
pipelining of event generation.
Received on Wednesday, 27 April 2016 10:43:39 UTC