Hi there,
We’ve having issues where our application is not picking up Webflow form submissions on mobile using Safari or Firefox. Works on desktop.
Anyone has this issue and a fix?
Hey @hello77, this kind of mobile-only issue can be tricky to track down, but we’ve seen a similar verified case that points to a likely culprit.
The way Wized’s Forms approach works is that form field values are only populated after the conventional browser submit event fires. On mobile browsers like Safari and Firefox, that submit event sometimes doesn’t trigger the same way it does on desktop — which means Wized never receives the form data, even though everything looks fine visually.
The recommended fix is to switch from the Forms approach to the Inputs approach in Wized:
- Remove the Wized attribute from the form element
- Add the wized attribute directly to each individual input field inside the form
- In Wized, instead of using an On Submit event on the form, set up an On Click event on your submit button
- Configure your request to pull values from the individual inputs (e.g.
return i.[yourInputName]) rather than from the form object
This completely sidesteps the dependency on the form submit event and works consistently across browsers and devices.
Also worth checking is if Webflow’s bot protection (reCAPTCHA) is enabled on the form, disable it. It temporarily disables the submit button on page load, which can prevent the submit event from firing.
If switching to Inputs doesn’t resolve it, we’ll loop in the dev team for a deeper look.
Hi @elvisben !
We are using the on click event for the submit button and have bot and spam protection disabled but still having issues on mobile for Safari and Firefox.
I’ve had a couple of tries on safari mobile on our end and couldn’t reproduce this. Could you share the site link we test it out on our end? Perhaps we don’t have the same exact setup to reproduce
Of course, here it is Get Life Insurance Quotes Online | Fast & Free | LifeSimple
I’ve gone through the stepped form, so the issue is the “View Plans” button at the end not activating on iOS and firefox mobile, right?
Correct, it doesn’t capture the submission. We’ve tried via analyzing the mobile web inspector and got nowhere with our fixes
We set the terms on the last step where you select a button like “10 Years, 15 Years” for example and they each represents a value that the API recognizes for the quotes on another page when you submit.
The variable I meant was the v.term, how do you set the v.term variable in the earlier snippet shared? I think the selection of the years on the last step isn’t happening then on iOS
On click of those button we get the input values to set the v.term from this snippet in Wized:
// Capture plan
if (i.term === “10 Years”) {
v.term = 3;
} else if (i.term === “15 Years”) {
v.term = 4;
} else if (i.term === “20 Years”) {
v.term = 5;
} else if (i.term === “25 Years”) {
v.term = 6;
} else if (i.term === “30 Years”) {
v.term = 7;
} else if (i.term === “35 Years”) {
v.term = 9;
} else if (i.term === “40 Years”) {
v.term = “0”;
} else if (i.term === “45 Years”) {
v.term = “A”;
} else if (i.term === “50 Years”) {
v.term = “B”;
} else if (i.term === “100 Years”) {
v.term = “P”;
} else if (i.term === “10 Pay”) {
v.term = “S”;
} else if (i.term === “20 Pay”) {
v.term = “J”;
} else if (i.term === “Lifetime Pay”) {
v.term = “H”;
} else if (i.term === “My Par Gift”) {
v.term = “Charity”;
}
if (i.coverage && n.path === “/plans”) {
// v.coverage = i.coverage * 50000;
var slider = document.querySelector(‘[w-el=“coverage”]’);
// Record the final value when the slider thumb is released
slider.addEventListener(“change”, () => {
return (v.coverage = slider.value * 50000);
// Here you could also send the `finalValue` to a server, save it in a variable, etc.
});
}
I’ve done some further testing and currently the v.term gets set as I click through the choices however on the form complete condition for v.formComplete evaluates to false because of the condition v.coverage... on line 163 in the screenshot below.
Could you verify the evaluation of the conditions according to the logic?
We were trying to solve for the recaptcha in the form so this code was created. I’ve temporarily reverted to the old code and ran a test but still didn’t submit the form.
If you have a solution for the recaptcha as well that would be helpful if my solution was not sufficient.
I think there has been a misunderstanding - the recaptcha was fine and I saw it working well so I didn’t bother mentioning it.
However the difference I saw was coming to the v.formComplete being true in desktop and somehow being false in iOS environment - that is what I was implying in the previous message. I wasn’t sure of there being logic elsewhere and that is why I was asking if you can verify the evaluations and perhaps find if logic elsewhere clashes.
I have just tested and seen that at the time of sending this the button isn’t enabled for both desktop and iOS - could you revert to the old code and check the evaluations in browser dev tools of the dependecies making up the v.formComplete variable?
We’ve changed it back, there shouldn’t be any additional logic that would cause clashing. Is there a method for you to check on our behalf?
I can only use the debugger from the link provided - I’ve recorded this loom video: Evaluation | Loom which shows how I actually get to see the values at the point where I have filled out all the rest of the form and want to click on the “View Plans” button
What I can’t know before hand is if there is code that sets it differently in desktop and mobile(I say mobile because the test in the loom is done on Android and still has the same issue) - this is what I am referring to as “clashing” logic. Might you happen to know how to use the debugging tools in the browser because this is a code related issue.
Hi Elvis, appreciate the video.
So the logic for the button is basically, there needs to be term selected, so those buttons on the last step and the coverage amount is greater than $50,000 which is the default value. Those are the basic validation on the final step. I tested on both desktop and mobile but only mobile is having issue of not submitting the form when desktop is working. I keep seeing the XHR request for the form to fail on mobile and can’t figure out why.
There is no split code for desktop vs mobile for context.
I’ve seen I wasn’t actually moving the slider, I thought it was auto-calculated. Moving it made it active in my case check this recording: iOS test | Loom
Yup that looks correct but do you know why on mobile the form submission to Webflow isn’t working? That is the main issue we’re facing
The form submission function comes down to the code - because the logic evaluation is the one which makes the form button to be disabled.
I’ll advise that you review if the logic is intended because I’ve also retried in desktop chrome and I can now see the same issue 2026-04-20 23-47-07 | Loom