I want to trigger a workflow when an input has been clicked. to do this I put the input inside of a group and added a “when group is clicked” WF on the group. Everything works great when the input is set to text (and some other options, like ‘email’), but when I set the input content format to decimal, the WF doesn’t fire.
Any idea why?? and if there is a way around this? I’m using the WF to run a little JS to select existing characters inside the input.
The WF is not on the input, it is on the group that contains the input. If you have an input inside a group, when you click into the input, the group’s ‘when clicked’ WF will fire. which works fine in this case when the ‘content format’ on the input is set to ‘text’. But if I change the ‘content format’ to ‘decimal’ it doesn’t fire. I have confirmed this with the debugger. It’s not that the WF doesn’t do what’s expected, the debugger step-by-step boxes don’t pop up.
I’m not counting characters, I’m input.select(); ing them. The WF fires, as confirmed by the debugger window popping up and stepping through actions, when the ‘content format’ on the input is set to text. If that ‘content format’ is set to decimal or number, it doesn’t fire.
Does this sound like a bug?
I thought if I put a ‘when clicked’ WF on a group that it would fire whenever the group was clicked on regardless of what else is in the group or clicked on if it is also in the group. At least that has been my experience up until now, except in this case.
That is usually the case. I do believe Bubble made some kind of change to this behavior over the past couple of years, but I feel like I recall the change was to make the behavior more consistent.
I would imagine that if you setup a simple test page, with two identical setups side by side with only the single difference being the content type of the input, and can clearly demonstrate via a video the difference in behavior, that may suffice to get Bubble support to investigate it as a bug to which you may hear back of a fix being implemented, or an explanation from engineering on the reason for the difference.
However, if you are really in need of this functionality, something I’ve done in apps is to have a group inside of the container (the same container that contains the input) and this new group will basically overlay the input. Use that group to fire the when clicked workflow action, as well to trigger a workflow action to set focus to the input.
Yikes! Is that really what it takes to report a bug? I may look into it over the weekend.
Great suggestion for the work around. Only problem is that ios seems to require an interaction with an input before it will allow JS to work with it. Capturing the click “through” the tapping on the input satisfies both issues when the group is behind it (and works great when set to text). I’m afraid a mask over the input would work fine on Chrome, but would block that interaction on ios safari.