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.
Ah, yes...I'd forgotten about that...Yes, I can put that in, but still please let me know if the bug does get fixed so I can remove the setTimeout patch. I think this is a pretty bad bug. I discovered it when the data in our inventory database was suddenly really weirdly wrong after my client tried to update the inventory using this form. She ended up setting codes and prices for things that were so bizarre that I had to manually scour and fix the entire database. There are other places on the site that use onInput, but not for updating data. I'd like not to have to put this temporary fix in everywhere.
I would also hate for others who have not read this thread to fall prey to this bug. I think that most people developing Wix sites don't have the ability to continually test their site across browsers/versions/OSs.
For anyone interested, there are 2 REALLY GREAT YouTube videos I watch to remind me about browsers and threading (really, the lack of threading)/event loops/micro tasks/macro tasks/request animation frame/jank/etc. These will explain why calling setTimeout will "fix" this issue.
https://www.youtube.com/watch?v=cCOL7MC4Pl0
https://www.youtube.com/watch?v=8aGhZQkoFbQ Thank you for getting to the bottom of this, and please do update this thread when the bug is fixed.
I see the hotfix, it's adding setTimeout with zero delays. Looks like it fixes the problem. Demo: https://alexanderz5.wixsite.com/my-site-1/on-input
/** * @param {keyof PageElementsMap} selector * @param {$w.EventHandler} eventHandler */ const onInput = (selector, eventHandler) => { // @ts-ignore $w(selector).onInput((event) => { setTimeout(eventHandler, 0, event); }); } $w.onReady(function () { onInput('#input1', (event) => { $w('#text1').text = event.target.value; $w('#text2').text = $w('#input1').value; }); });Thank you for looking into this. I already coded around the bug by using onChange, but it is an annoying temporary solution. My client uses this page to update inventory. The typical routine is that she has pages of 5 digit codes and prices that she wrote down (on paper) from walking around the facility counting stock. She needs to QUICKLY type in 5 digits, then tab to the next input, set the price and a couple other properties, then hit <enter> to save. The onChange workaround slows her down. There are two problems with it.
First, she can't just enter a 5 digit code and load the inventory row. She has to click/tab outside the input box. This slows her down a lot.
Second, I have to disable the save button and can not re-enable it until I run the validation code that makes sure all the form fields are valid with respect to each other. I used to run this onInput. Now I can't. This means she has to click/tab somewhere outside the text input to fire the onChange handler and then enable the save button. This slows her down CONSIDERABLY. It basically doubles or triples the time it takes her to update one row. Multiply this by several hundred items, and it's really not ideal.
I could spend a lot of time writing multiple workarounds, but I have a lot of other things I need to be doing. Is it worth my time to spend several days writing workarounds? Or just do something that's "good enough" while I wait for the fd from Wix.
Please let me know if this is likely to be fixed soon. If it's something that will takes many months, then I will need to spend some time making the interim solution less painful for my client.
Hey @polkaset ! It looks like a bug. I try to find a contact person to fix it. Thank you for the bug report!