Form submit not working in Safari: find why

Safari fails quietly. The form sends nothing, or it sends a request that the server rejects, and the page shows no message. Autofill can fill the visible text while the script's copy of the field stays empty. A required field can sit in a closed panel, so the browser blocks the submit and its message may land on a field the visitor cannot see. On iPhone, a tap on a styled div may never reach the click handler. A form that posts to another domain can lose the cookie it needs, because Safari blocks cookies from other domains.

• Open Safari's Web Inspector, press Send, and check the Network tab for a request to the form's address.
• Type every field by hand with autofill off, then press Send. If the form sends, autofill is part of the cause.
• Read the Console on page load for a script error. A script that fails stops the submit handler from attaching.
• Look for required fields that are hidden or inside a collapsed panel, and compare the same form in Chrome.
• On iPhone, make sure the submit control is a real button, so the tap reaches the click handler.

The visitor opens the form in Safari, lets autofill fill in name and email, and types a question. They press Send. Then one of three things happens. The button does nothing. It spins and stops with no message. Or the page reloads with the fields empty. The visitor presses Send again, then leaves. Your analytics show a page view and no submission, and your inbox stays empty.

The first cause is autofill. Safari can write text into a field without firing the input events the script uses to store it, so the field looks full while the script's copy is empty. The second is a required field that is hidden, for example inside a closed panel. The browser then blocks the submit and tries to show its message on that field, which the visitor cannot see. Nothing visible happens, and nothing is sent.

The third cause is the tap. On iPhone, Safari may not send a click to an element that is not a link, a button or a form control, such as a styled div used as a button, unless the element sets a cursor style or an onclick handler. The fourth is the cookie. Safari blocks cookies from other domains by default, so a form that posts to a different domain can arrive without the session or security cookie the server checks.

Open the Web Inspector before you test. On a Mac, turn on the Develop menu in Safari's Advanced settings. On an iPhone, turn on Web Inspector under Settings, Safari, Advanced, connect the phone to the Mac, and open it from the Develop menu. Press Send, then read the Network tab. If no request to the form address appears, the fault is in the page. Check the Console on page load too.

A request that returns 401 or 403 means the server refused it, usually because a cookie did not arrive. A request that returns success but leaves the page unchanged usually means the page is ignoring the reply. Then open the same form in Chrome with the same data. If Chrome logs that an invalid form control is not focusable, the console line names the hidden field.

A simulated visitor fills the form the way a stranger would, presses Send, and reports the step where it stopped, with a screenshot and a fix prompt. Before you read a clean run as a Safari result, confirm which browser the visitors used. A pass in another browser does not clear Safari, and the Network tab check above still applies. If the form leads to checkout, the test stops at the payment step and never pays with a real card.

Why visitors leave before they sign up

The same Safari fault can return after the next release, when a new script or a changed field breaks it again. Rerun the same visitors after each fix to see who got further. If the form sits behind a login, test it with a test account, and check each preview deploy before release.