Inputs lose state on quick interactions (or on slow networks)

Qwik Version

0.0.42

Operating System (or Browser)

macOS Monterey (Chrome v.104) and Ubuntu 20.04 LTS (Chromium v.104)

Node Version (if applicable)

No response

Which component is affected?

Qwik Runtime

Expected Behaviour

When interacting with inputs the text typed into them should persist but if the user is fast enough and the network is slow the text can actually be completely (or partially) removed.

Actual Behaviour

You can see in this stackblitz reproduction that if you type quickly enough in the first input and switch into the second and keep typing, the text typed into the second input gets removed.

For example see the following gif:

There I am typing three ones (111) in both inputs, but as you can see 2 1s in the second input just disappear (but you do need to be quite fast to trigger the bug).

That is the best reproduction I could do on stackblitz, there the issue is difficult to reproduce since their web containers don’t allow you to throttle the network (and serve the js files instantaneously via service workers), but if you run the reproduction locally the issue is very easy to reproduce (and it shows more clearly how this can be an issue with the user experience):

(naturally in the second gif I am not deleting the text myself, it is getting remove as soon as the core.mjs file is downloaded)

Additional Information

I’m sorry if this is a minor bug or it is expected by the asynchronous way Qwik is implemented

(PS: not sure why the core there is 1.5mb it does seem way way too large, it is probably because I was just running the app locally in dev mode, but even with a smaller js file, if the network is slow enough and/or the user’s interaction is fast enough the issue would appear)

Another thing to mention is that this only happens initially when the js file gets fetched, after that no state gets lost anymore.

[manucorporat]

You guys are amazing! Yep on change behavior is a bit odd, react fakes it behaving like oninput. But we will not do this, seems a bit against the standards

[nnelgxorz]

Happy to help, @dario-piotrowicz!