[w3c/uievents] Should require Input event to be fired within same event loop as keydown? keypress? neither? (#238)

Create a page with the following markup:
```
<!DOCTYPE html>
<html>
<body>
<p>Focus the text field below. Then press a key on the keyboard. The output will be the value of the field seen one event loop turn after the listed event dispatched.</p>
<input id="input">
<pre id="console"></pre>
<script>
// Note that scheduling a timer from an Input event handler is for aesthetics only: to make the
// logged Input event be ordered like the spec'ed DOM dispatch event order. By the time the Input
// event fires the DOM is guaranteed to have been updated. So, no timer is needed.
let input = document.getElementById("input");
for (let eventName of ["keydown", "keypress", "keyup", "input"]) {
    input.addEventListener(eventName, (event) => {
        window.setTimeout(() => {
            log(`${eventName}: ${input.value}`);
        }, 0);
    });
}

function log(message)
{
    document.getElementById("console").appendChild(document.createTextNode(message + "\n"));
}
</script>
</body>
</html>
```

Open ^^^ in your browser and follow the instructions. I'm seeing different things in different browsers™.

In Mac Firefox 67.0.4 I see, emphasis mine:

<pre>
<b>keydown: </b>
keypress: a
input: a
keyup: a
</pre>

On iOS, I see the following (with auto capitalization is off under Settings > General > Keyboard > Hardware Keyboard), emphasis mine:

<pre>
<b>keydown: </b>
<b>keypress: </b>
input: a
keyup: a
</pre>

In Mac Safari and Chrome Canary for Mac version 77.0.3847.0, emphasis mine:

<pre>
<b>keydown: a</b>
<b>keypress: a</b>
input: a
keyup: a
</pre>

For the last two browsers above what is happening is that text insertion (i.e. a DOM update) is occurring within the same event loop as the the keydown.

Spec makes **no** mention that DOM update must occur in same event loop as keydown or keypress (that's what Firefox is doing). Spec **only** guarantees DOM is updated when input event is dispatched.

## Real-world examples

I know of two sites that assume DOM is updated on keydown/keypress:

1. Google Sheets

Repro steps: Create a new sheet. Tap on a cell. Type into it. Formula bar is updated with DOM value of cell on timer scheduled from keypress (read: not input event).

2. Bitbucket Server (formerly known as Stash)

Repro steps: In a pull request comment, type `@`. Bitbucket schedules a timer on keypress and expects text insertion (i.e DOM update) when timer fires so that when it reads `<textarea>'s` value it will see the typed `@` and trigger its suggestion UI.

## What to do?

**What is the expected behavior?** **Should spec require DOM be updated for text insertion/deletion in same event loop iteration that keydown is dispatched?** same event loop iteration that keypress is dispatched? Should we keep the current spec text with no such requirement? Should we spec out explicitly that there is no such requirement?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/238

Received on Monday, 8 July 2019 19:00:14 UTC