Good morning,
A couple of months ago I created a page that processed user input using a text input and the onInput event. I started getting bug reports from users on Safari, and when I dug into it, I was able to reproduce (intermittently) a problem where onInput on Safari does not work as I would expect.
What I noticed is that when you type, the input that shows in the text input box is not the same as the input as captured in the event handler or in the input.value property. The event.target.value and $w('#myTextInputElement').value contents are one cycle behind reality.
Input box shows: a
Event:
$w...value:
Input box: as
Event: a
$w...value: a
Input box: asd
Event: as
$w...value: as
Input box: asdf
Event: asd
$w...value: asd
and so on.
I was able to reproduce this only on Safari. Chrome and Firefox behaved as I would expect (as in...if the text in the input box said asdf, the event target and $w...value also contained asdf).
I also wanted to see if this was something that happened only using Wix/Velo, or if I could reproduce this in straight JS. I could not. I hunted on this forum, Google search, Stackoverflow, etc but did not see anything odd about Safari not behaving with regards to the onInput event, either in plain JS or in Wix/Velo.
The reason for this forum post is that I filed a ticket with Wix support a few weeks ago and have not gotten any response. I'm not sure if this is even a bug, or if there's something I should be doing differently. I can't imagine how I could be the only person who has experienced this problem. I think Safari is a commonly used browser and someone would have seen this problem before?? It just seems odd that I would see this behavior, and then not find a single reference to it anywhere on Stackoverflow/Google/Velo Forum/etc.
I had to code around this problem with a REALLY annoying compromise. I cannot use onInput. I can only use onChange which requires the user to click outside the input box in order to run the event handler. I would love to use the keyup event, but Wix/Velo does not give you access to that event. They only give you access to onKeyPress, which is not the right behavior. The event target is what was in the input box when the key was pressed, which is the previous input. The event target for keyup contains the contents of the input box when the key was released...so...the CURRENT contents...
Here's the test page: https://polkaset.wixsite.com/testinganddebugging/input-test
The code behind this test page is straightforward:
$w.onReady(function () {
});
export function textInput_input(event) {
$w('#inputUiElementValue').text =
$w('#textInputWithInputHandler').value;
$w('#inputEventValue').text = event.target.value;
}
As I mentioned above, the problem is intermittent. Sometimes onInput works as I'd expect it. Sometimes it does not. If you get the "correct" behavior, reload the page and try again. Sometimes you'll get the wrong behavior, sometimes you'll get the right behavior. I've reproduced this on several different Macs. My client has also reproduced this on her Mac (she's the first person who found this because she uses Safari...I use Chrome).
Has anyone else seen this problem? Is anyone else able to reproduce this with the test site above? Is this a bug? Should I be doing something else? I really want to remove the ugly onChange workaround. It is a poor user experience. But I can't do that until I get some resolution on whether or not I can/should use onInput.
Thanks in advance
Tracey
Wondering if there has been any progress on this? I have the workaround in place, but it would be very nice if this were fixed. I think it's a pretty bad bug. For me, it corrupted data in my database before I found it.