17

I apologise in advance for not being able to provide any actual code, as the problem appears in a page which is currently private :-/ Please bear with me.

I have an HTML form. I attached a (proprietary) calendar widget to one of the text input fields. When the user tabs into the field the calendar appears. On the calendar there are a couple of buttons (to move to the previous/next month). When the user clicks on one of these buttons the calendar updates itself accordingly, but also - the form submits! There's NOTHING in the calendar code that touches anything other than the calendar itself and the text input field it is attached to, let alone submits a form! I would appreciate any clue regarding any of the following questions:

1) What could possibly have submitted the form in such a setting?

2) What things generally submit a form, other than clicking on the submit button or hitting the enter key? (In particular, do ordinary buttons submit forms? Under which circumstances?)

3) As a workaround in case I don't manage to figure this out, is there a way to simply totally disable submitting the form (and then reenable it in an event handler attached to the submit key)?

Note(s): The calendar behaves normally other than that - responds normally to key events and to click events on the dates themselves (which are not buttons). I tried this on both Firefox and Chrome and got the same behaviour. I tried to follow the click event handler step-by-step with FireBug, and everything seemed perfectly normal - but the moment it finished the form was submitted (and the page reloaded). The widget uses jQuery 1.7.2. Any help in understanding and/or solving this will be most appreciated!

Tom
  • 4,910
  • 5
  • 33
  • 48
  • 1
    in the onclick event of the calendar buttons, you need to call `e.preventDefault()` -- most buttons will submit the form/page unless you explicitly prevent that default behaviour. If that doesn't work, try `e.stopPropagation()`. – mpen Aug 09 '12 at 23:51
  • 2
    And you can't create an [SSCCE](http://sscce.org/) that demonstrates the problem? – Dave Newton Aug 09 '12 at 23:52
  • 1
    @ŠimeVidas: He said proprietary; I'm guessing made by him or his company. – mpen Aug 09 '12 at 23:53
  • @Mark That doesn't mean it can't be public. After all, it's open source, since it's a JavaScript script. – Šime Vidas Aug 09 '12 at 23:55
  • 1
    @ŠimeVidas: Could be "public" in that sense, but it's probably not one we're familiar with. But I suppose he can answer that himself :) – mpen Aug 09 '12 at 23:56
  • @Mark Well, I would like to see the source code of that widget. That's why I asked in the first place :) – Šime Vidas Aug 09 '12 at 23:57
  • At the moment the code, including the widget, is not yet released to the public. @Mark: It's interesting what you say about buttons. I tried `preventDefault()` and it worked! However, I've just created a simple form with a button, and the button does not submit the form. When does a simple button (which does not `preventDefault()`) submit a form, and when does it not? – Tom Aug 10 '12 at 00:16
  • @Dave: I guess I could create an SSCCE if I had to, but it seems we're managing to get somewhere without it, so maybe I don't have to. I apologised for not including code, and some people have given me very useful info based on what I did include in my question. – Tom Aug 10 '12 at 00:25
  • @Tom There weren't any answers when I posted that, and the answers address factors you specifically excluded--hence the call for something to work with still stands, otherwise it's random guessing. – Dave Newton Aug 10 '12 at 00:32
  • @Dave: indeed the answers given so far are not perfect - but still I got some very useful information from them and from the comments, namely the fact that buttons sometimes trigger a submit (even though I still don't know why sometimes they do that while at other times they don't), and several methods to prevent unwanted submitting. Each of these alone is enough for me to solve the problem and move on. In general, though, I agree with you that SSCCEs are a good thing - and I would try and make the effort and use one myself if I hadn't got enough useful info without it after some time :) – Tom Aug 10 '12 at 00:37
  • @Tom Then the things you excluded in the OP must not be correct, because the answers all address stuff those things. That's fine, but misleading. Glad you fixed it, though. – Dave Newton Aug 10 '12 at 00:50
  • This seems too obvious, but just for completeness, there aren't ` – JMM Aug 10 '12 at 01:12
  • @Dave: I'm not sure I follow you. However, it seems my questions have been repeatedly misunderstood, so I rephrased them a little, hoping it adds clarity. Thanks! – Tom Aug 10 '12 at 01:18
  • @JMM: I actually got it wrong; they're not ``, but `` elements - and apparently `button` elements have a default submit :-/ (I've got absolutely no idea why, but it seems that's how it works.) – Tom Aug 10 '12 at 01:41
  • @Mark: by now I got it - ` – Tom Aug 10 '12 at 01:57

5 Answers5

34

Sorry to answer my own question, but none of the given answers was complete, even though I've learnt from them and from the comments! Thanks for everyone who participated!

So:

1+2) Buttons defined by the <button> element cause submits (as if they had type="submit" set. At least in some browsers). If one wants a button not to cause a submit one should use <button type="button">, or the good old <input type="button" />.

3) (Unnecessary for me now, but it was part of the question.) There are many ways to prevent a form from submitting. Three of them are:

  • to handle the onsubmit event, preventing the submit (by return false; or - preferably! - by e.preventDefault();) in case a flag is not set; set the flag when handling the event(s) that should actually submit the form

  • to handle the onsubmit event and prevent the submit as above if the element that triggered the event is not (one of) the element(s) we want to cause a submit

  • to set the form action to non-action, i.e. action="#", and to have the handler for the event that should actually submit the form set the action to the proper address

Tom
  • 4,910
  • 5
  • 33
  • 48
  • 1
    `return false` is a jQuery thing. It calls both `e.preventDefault()` and `e.stopPropagation()`. No problem answering your own question; thanks for sharing your findings. – mpen Aug 10 '12 at 02:11
  • 2
    Thanks for your comment, @Mark. `return false;` is **not** a jQuery thing. It also works in plain JavaScript (maybe it's not cross-browser? I don't know. I've just tried on Firefox and it works, at least in preventing the default). I wrote that `preventDefault()` is preferable because indeed `return false;` stops the propagation as well (at least in jQuery. I'm not sure about plain JavaScript), which is not necessarily what we're after. We want to prevent the default. – Tom Aug 10 '12 at 08:52
  • Good to know, @Mark! So `return false;` as a means to prevent the default seems to be quite universal, if I get it right. The jQuery peculiarity is that it also stops the bubbling. – Tom Aug 10 '12 at 15:43
  • Yeah, looks that way. I guess it did prevent navigating to that link, so it is preventing the default action but not bubbling. I learned something too =) – mpen Aug 10 '12 at 18:00
  • This answer led me to solution of my problem - submit of the form was leading to an unwanted click event on a button inside. The button didn't have the `type="button"` property - and adding that fixed my issue. – pesho hristov May 31 '22 at 14:33
1

The calendar code isn't calling submit() somewhere?

3) As a workaround in case I don't manage to figure this out, is there a way to simply totally disable submitting the form (and then reenable it in an event handler attached to the submit key)?

Unfortunately, I'm not totally sure if it's reliable that the click handler will be called before the form submit event.

( function () {

  var prevent_submit = true;

  $( "form" ).on( 'submit', function ( event ) {

    if ( prevent_submit ) {

      event.preventDefault();

    }

  } );


  $( "input[type='submit']" ).on( 'click', function ( event ) {

    prevent_submit = false;

  } );

} )();

or

$( "form" ).attr( { action : "#", method : "post" } );

$( "input[type='submit']" ).on( 'click', function ( event ) {

  event.target.form.action = "...";

} );
JMM
  • 26,019
  • 3
  • 50
  • 55
  • The calendar code most certainly does NOT call `submit()` anywhere. Thanks for the tips on how to disable the submitting! – Tom Aug 10 '12 at 00:03
  • By now I've come to understand that `` buttons submit forms, and that one has to use `` or ``... – Tom Aug 10 '12 at 01:55
1

The calendar can submit your form in its JavaScript source code by calling form's submit() method using jQuery or plain JavaScript.

Here is an example how to disable the form submit and allow it only in case of pressing the button.

<form id="form">
    <input type="text" />
    <input type="button" name="submit-button" value="Submit"/>
</form>​
<script type="text/javascript">
    var form = document.getElementById('form'),
        button = form['submit-button'];
    form.onsubmit = function(e) {
        return !!form.getAttribute('data-allow-submit');
    };
    button.onclick = function() {
        form.setAttribute('data-allow-submit', 1);
        form.submit();
    };
</script>

Demo

Eugene Naydenov
  • 7,165
  • 2
  • 25
  • 43
  • I **don't** want the calendar to submit the form - that's the whole problem! Thanks for the example on how to prevent sources other than the submit button from submitting the form! – Tom Aug 10 '12 at 00:27
0

Hitting enter on text fields can sometimes trigger a form submit. See here. Especially if that is the only element in the form. One way to control the post back is to set the action to empty and fire off the event yourself with Javascript.

Visionary Software Solutions
  • 3,825
  • 2
  • 29
  • 35
  • Yes, I know that hitting enter submits forms. That's why I asked: "2) What things generally submit a form, **other than** clicking on the submit button or **hitting the enter key**?". Thanks for the tip regarding disabling the submitting. – Tom Aug 10 '12 at 00:06
  • Generally enter and hitting submit. Of course, 3rd party developers may wire up tab, space bar, or other such shortcuts depending on the application. If you want to take control of the behavior, you'll have to trigger `submit()` manually – Visionary Software Solutions Aug 10 '12 at 00:08
0

Check the placement of the closing form tags. I had this problem once and I finally figured out that there was some 'permissions' code within the form itself that prevented the user from reaching the closing tag because he didn't have the proper permission level to submit it. In effect this left an open form tag that then responded to other buttons elsewhere on the same page.

BPrice
  • 27
  • 4