Hi, I am using an Weweb component input field. I have a workflow “on key enter”. The workflow is launched, but it also adds a line inside the input field (extra line/it goes to a new line, for what before we needed to add shift+enter).
On my workflow I have a “reset variable value”, which is not working (it cleans the value inside the variable, but not inside the Input field).
Is this a bug or how to solve this?
I’m having the exact same issue: For some reason, resetting the input variable does reset the value of the variable - but the text is still displayed in the input field! Also binding the init value to the input variable didn’t solve it. How to fix this odd behavior?
1 Like
@julian and @tcc did your solutions work before?
I have multiple pages on my deployed app which were using workflows to format inputs. They’re all still working on the deployed version, but not anymore on the editor preview. I believe this might be a new bug, because it used to work 100%.
Last deploy I made was around April 7th, after the “ReferenceError: process is not defined” bug last week. Maybe they’ve changed something in the mean time?
Hi guys, it’s a bug, our team is working to fix it. As a workaround, you can use conditional rendering in the on enter key workflow to force the input to re-render and clear the value.
1 Like
I’ve been having this issue for quite some time, thought I was in the wrong. Please fix this asap 
Hey @DanielL, I’d like to suggest Weweb to implement an “ongoing issues” page or something like that. I’m trying to figure out how to implement your workaround and I believe a centralised location for this would be awesome. It could even be on the community platform, like a sub-category inside Announcements.
I believe you guys must be overwhelmed with work (I’ve filled a support ticket about this issue and it’s been Under Development for a week now) and I believe having this or an issue tracker would be a relief for us.
2 Likes
EDIT: I found out a better workaround than this one. Check here or use the Conditional Rendering workaround presented by @DanielL.
Hey @tcc, I’ve found a workaround for these input bugs. Instead of using the “reset variable value” action, you can use a Custom JavaScript action, use document.getElementById() to select the input and then change it’s value via JS.
For this, first of all, you’ll have to define an id to your input. It’s under HTML attributes (near Element’s name). This must be unique! Let’s say yours is gonna be inputChatPrompt.
Next, head back to your workflow, and on the Custom JavaScript action, on the JavaScript code part, fill in:
document.getElementById('inputChatPrompt').value = ""
This will reset the input value. If you want to set the value to something else, just:
document.getElementById('inputChatPrompt').value = "something else"
In my app, since I have multiple input fields relying on workflows for formatting, I’ll probably wait a few more days for the support ticket before applying this fix to every input that’s broken.
1 Like
Apologies guys again, the fix should be live next Monday or Tuesday.
1 Like
Hey @DanielL, any news on this fix?
There’s a couple of different ways to do this, obviously the way fnicoli is already mentioned. As long as your input isn’t in a repeatable list you can also do change variable value and find the input variable
Or you can do custom javascript
But these won’t work if the input is in a repeatable list!
@Yaj In a repeatable list, I guess you could add a class to every input and apply JavaScript triggers to everything that comes out of document.getElementsByClassName() but then you’ll be doing everything “outside” the WeWeb UI which might complicate maintenance later.
Anyway, I’ll have to wait for the fix, I’m not willing to apply any workaround to 30+ fields.
But I have a bad feeling this will take another week or two…
I think I did something in our project with repeatable lists and inputs but honestly can’t remember where I’ve done it and what I done. But I always try avoid any DOM references if I can cause they usually come with their own complications, might be better now that weweb got rid of all the wrappers though.
I wouldn’t rely on any fix any time soon. If we find that something like this happens, we never wait for weweb to provide a fix cause that’s just not gonna happen in a time frame you want. Workarounds are unfortunately the only option you have.
Also this inputs in repeatable lists have had this issue forever even on bubble. I’d say this is unlikely to ever get fixed.
I’ve found a better workaround than the one I presented here. This one avoids the tedious task of setting unique IDs on the inputs since it uses the thisInstance variable which can be accessed automatically inside the workflow.
This workaround still relies on a Custom JavaScript action at the end of the workflow. It will only update the current input which the workflow is tied to (so if you’re updating any other inputs, it will probably not work without modification).
The code is as follows:
// Guards against loops related to dispatching events inside an event handler
if(event.domEvent instanceof InputEvent) {
// Figure out the uid of the variable associated with the input
const thisInputVariableKey = context.thisInstance.getAttribute('data-ww-uid') + '-value';
// Apply the variable value to the input value
context.thisInstance.value = variables[thisInputVariableKey]
// Dispatch the event so Vue.js will re-render the input properly
context.thisInstance.dispatchEvent(new Event('input', { bubbles: true }));
}
It gets the UID of the input field, retrieves the value from the variable and sets it into the input. Then, it triggers an Input event that Vue.js will be able to catch and will use to re-render the input. It’s working both for setting and resetting values from input.
@DanielL It’s been 20+ days now, we need an ETA on this silly bug.
3 Likes
@DanielL any update? I have 30+ input fields that don’t reset…
1 Like
Here’s what I have on an input field to prevent a newline from being added
const textarea = wwLib.getFrontDocument().getElementById('expanding-textarea');
textarea.addEventListener('keydown', function(event) {
if (event.key === 'Enter') {
// Prevent the default action (newline character being added)
event.preventDefault();
}
});
Here is how I reset the field
wwLib.getFrontDocument().getElementById('expanding-textarea').value = '';
1 Like
The fix should be live next Monday/Tuesday guys. I’ve confirmed with the team.
1 Like
Hello everyone, this should be fixed now. Sorry for the trouble again, and please let me know if any of you still have this issue.
Hi,
Is there a new bug on the input field?
I have a value inside but it doesn’t push the input value inside the variable:
Ours ended up breaking again and we had to go with dom manipulation