Submit button not working

The rename worked and I have submit working, but now it is not posting anything, although I see something being posted in Firefox network monitor page. Using PHP 7.4 on the back end and not getting anything in $_POST, so not sure what that is all about. I do know it works if you remove the e.preventDefault(), so tonight I am going to look into it more. I see from the JQuery threads that it does seem to be a DOM issue, but I find it interesting that it was working great in 6.5 and now broken in 6.6. Only change was Foundation upgrade.

Once I figure out more, I will update the group. And thanks for all your hard work on Foundation. Great stuff!

OK, got this figured out and a demo. Check out It my documentation site for my PHP wrapper around Foundation. The entire site is written in PHP, with no HTML files, templates or other blocks of HTML. This page is 71 lines of PHP code actually.

So what you can do is specify which JS libraries to include. It will also show you the post values on a successful post and the libraries you included (debugging of the page really, but just nice to show).

So if you include no libraries, all buttons will post. The one combination that breaks it is Foundation 6.6. Plan vanilla HTML works, as just just JQuery. Foundation 6.5 works as well. Foundation 6.6 is clearly broken, as is does not submit with plain HMTL and plain JQuery do post. This is standard HTML behavior, and we don’t want to change it.

In general, I use the name of the submit button to allow multiple submits on a page. Often I don’t care what the text says, the fact that the button was pressed will post the name of the submit button, and I can just test that to know what button was pressed.

It also appears that the name of the submit button does not matter to JQuery, so maybe this issue was fixed in JQuery, or modern browsers no longer have the original issue? Don’t know.

Anyway, I think the fix is to remove the e.preventDefault() call on line 69 of foundation.abide.js. You are actually submitting the form, so you don’t really need to prevent the default action (which should be submit). I traced into JQuery, and it looks like not processing the default action on a submit will not submit the form. I think this is the proper behavior.

I have done some testing on my site with Foundation 6.6 (currently on 6.5 due to this issue), and I have not see any problems with this solution yet. Let me know what kinds of things to look for, and I can do some more in depth testing. I have just been trying to get 6.6 up and running and this has been a huge issue for my site.

Anyway, absolutely love Foundation and happy to help out in anyway possible.

Also, looks like we should be able to grab the foundation account now, the guy has even posted an update to his one and only repo. I’ll see if I can connect everyone over emails this weekend.

See which should work. Don’t forget to add the proper name attributes.

Also on my side it works in mobile Chrome on Android

It would helpful if you can provide a codepen with a reproducable testcase.

Hmm, had only been testing on Windows Firefox and Chrome, but just confirmed Chrome, Firefox, and native browser on Android behave the same way, as does iPhone Safari (don’t have a current Mac).

So the issue is once you select 6.6, then hit a button, it will post the first time (since the page was not created with 6.6), but once 6.6 has been selected and posted once, none of the buttons will submit the form.

I see your codepen is using a button tag, I’ll try that. Not sure when I will have time to set up a codepen example, tried the other day, but was not sure how to include foundation libraries. I’ll take a closer look at your example. Got a beer tasting tonight (10 homebrews on tap), so probably Sunday.

Well, you use value='Save' name='submit' type='submit' which will not work anymore. Please use value='Save' name='send' type='submit' or similar.

See (name=‘send’) vs (name=‘submit’)

PS: Please enable https on the domain so codepen and others can load the assets over a secure connection =)

As I’ve alrey written: Submit button not working

With the local version (copy the code from the first codepen link in this comment) it works, see the screenshot:

So I got a CodePen example working, basically yours with a button and input.

There are three problems that I see. Looks like 6.6 broke submits named submit. 1.) It worked on 6.5 with out issue. 2.) It works if you just use vanilla html, and / or JQuery alone. And the thing that will continue to cause me issues is 3.) It is not posting the button name / value pair under 6.6. #2 would be a deal breaker in my book. You just can’t be adding JavaScript libraries that change the expected default behavior of html with out a solid reason and be completely upfront about it.

So these three (really two) things are wrong with 6.6. All are fixed in my testing by removing the e.preventDefault() in abide right before the _this3.$element.submit(); code. It looks like this code was added in Nov 2018 but not merged in till 6.6 (f237c0ffeb0d82b63410deebdd8cc9ef4943ebde). Obviously this would need more testing and happy to do so if you think of some edge cases we might want to test.

I am really questioning the need for the preventDefault. I am not sure why it is used here. You want to do the default action and are explicitly calling the JQuery submit method.

Anyway, that is where I am at. I can’t upgrade my project to use 6.6, because even if I rename the submit name, I still can not receive the button pressed to submit the form, and that is important. Not sure why more people have not complained about this. It is a pretty big change from 6.5 and completely non standard html.

And thanks for the super prompt replies to this thread. Everyone on this project is doing yeoman work and it is much appreciated!

This is a bug / issue with jQuery and .submit(). Please carefully reread

We will not change that on our side. As .submit() is a normal method it would break anyways if you use the method. So please chanhe your markup and you should be fine.

Add a hidden input, this is the same in plain jQuery.

jQuery will be removed in Foundation 7.

Nothing wrong on our side =)

So it is nice that you are removing JQuery in 7, which a lot of people don’t use anymore, so this makes sense, but I will probably still use JQuery, as my sites don’t use a lot of custom JavaScript, and JQuery works well for me.

So I can change my markup, no big deal. It is a breaking change for a library I support, but doable.

So even when I make the markup change, I still have an issue with determining which button the user pressed. I created two CodePens to highlight the issue. is a plain vanilla Sign In page, no JQuery, no Foundation, just HTML. In the page handling the post, I query the presence of the button pressed to decide what to do, sign the person in, or go to the forgot email page. On the forgot page, I have the email address the user entered, so I prepopulate the page with it. This is a great UX pattern I wish more people would use, it is so annoying having to enter your email address again when you just entered it on the last page. I use this button post pattern through out my sites. Works great.

I also used the same markup in Try hitting a button. It submits because I am not naming either one submit! But check out the parameters passed to the subsequent page. Notice something is missing? The pressed button is just not there. I can’t use a hidden field as you are suggesting, as I need it conditionally posted, and a hidden field will not do that.

So my question is, what is the preventDefault call actually used for in abide before calling submit? As far as I can see, it only breaks submit. Take it out and both of my issues go away. So what is it doing there and why is it needed? 6.5 also used JQuery and did not suffer this problem, because it does not call preventDefault before calling submit. So what exactly does it add?

For forms with multiple submits you can use button elements which also work.

Regarding the name, you can use a different one (instead of submit as this is also too general) or use submit[] if you need it but I advice against use submit as name.

.submit() was not in the before 6.6.0. So this has nothing to do with preventDefault (which just catches the submit / button action). This is what preventDefault is there for (to stop the event from bubbling to others listeners).


submit: Creates a submit button. This is the default value.

At least there are multiple solutions. And as previously written this is an issue with jQuery, not Foundation itself.

6.6.0, like other minor releases, includes also a few breaking changes. This one just slipped through in the changelog.

So this is totally ok for 6.6.0

Daniel, looks like you are correct in using buttons. They did not seem to work in my initial testing. It also seems that you can name them submit! I changed the CodePens to use buttons instead of input. I can now make a non-breaking change in my library and upgrade to 6.6.

Thanks for hearing me out. I am fine with a workaround, but obviously it would have been better had I not run in to the issue. Let me know if you want some help in documenting this breaking change.

Looking forward to V7, as it won’t have this problem for sure. No JQuery issues!

And thanks again for all your hard work on Foundation. I tell everyone “Friends don’t let friends use Bootstrap”.

That would be very helpful =)
Let us know if you need any assistence with this.

Thanks for the hint. I have added an example with <button name="submit" as I was not aware of that (that it works with button elements but not input, not sure if this is an inconsistency / bug in jQuery or intended).

Just submitted a PR. Turns out you need to remove the type=“button” and add the class submit. Corrected the documentation and my sites are all working on 6.6 now with no source code changes.

Thanks for all the help!

You should also update the 6.6.0 release notes with something like:

Make sure submit buttons use <button> instead of <input type="submit">. Also add the class submit and remove the type="button" attribute.

1 Like

Thanks for the PR and finding a better solution.

Technically a <button type="button"> is a <input type="submit"> when used in a form so this makes sense.