Symphony.

Does a redirect also prevent form-data from being submitted twice when using the back-button?

AFAIK: yes. As soon as you redirect the POST data is gone. Going back will not magically resubmit.

My point is, even if you submit a form and navigate away to a different page manually, as soon as you go back to the page containing the form using the back-button, the browser asks to resubmit the post. So I guess it's more a browser related issue and a simple redirect would not really solve this.

My point is, even if you submit a form and navigate away to a different page manually, as soon as you go back to the page containing the form using the back-button, the browser asks to resubmit the post.

Yes, I've noticed this too. Firefox does that, IE returns a "Webpage has expired", Safari and Opera simply reopen the page, with all POST data preserved.

This probably depends on what redirection is used. Maybe it could be prevented if the POST returns a rideraction, 302 or 303 response, not 301...

So I guess it's more a browser related issue and a simple redirect would not really solve this.

For me, a redirect does fix it in Firefox and Chrome. The POST-action simply disappears from the history and both reload and back-button will never execute a resubmit.

@Jensscherbl I'm not sure if it's a browser- or server-related issue, but it's a very well known behaviour. The work-around ("post-redirect-get" - google it) is also a very well known pattern to 'fix' this. This Wikipedia Article on "post/redirect/get" pattern explains it nicely.

AFAIK this behaviour is not limited to some browsers (although browsers differ in how they implement the re-submission message).

A redirect (GET) (and preferably 303) does solve it.

PS: I've found a neat little test-page where you can test this in your browser.

Allright, good to know. Thanks for clearing this up.

Usually I tend to rely no AJAX for form submission; I create a /ajax/ page in symphony to which I attach all my events; then through JavaScript(jQuery) I send all my forms to this page. This way I reduce the number of people sending their data twice, as when they refresh they see the original page. When they submit I show either a pop-up or a message near/instead of the contact form.

In addition to this it also cuts out a lot of automated spam; since if the form is automatically submitted by a bot I do not have any event attached to the page; never needed any other anti-spam measures so far so pretty happy with the approach.

@Gunglien this is certainly an easy way to deal with the issue (and deal with spam) but since the form does not 'work' without JS it is less accessible I guess…

Maybe yes but nowadays most mobile browsers also support JS and there are very few browsers/system that do not support JS.

Some of the websites I work on are pretty heavy on JS to be honest with stuff like slideshows etc; plus any system that does not have JS enabled is most likely to have a broken design if its a pretty old browser/system.

Where I work they haven't really moved on to the mobile bandwagon, especially since we have quite some heavy data going on in some pages, so unless its a smartphone it wouldn't really be rendered properly. Then smartphones also support JS so its not that big a deal.

So far never had any complaints on the ways the forms work; so we never had to look into providing support to browsers without enabled js.

Would be interesting if someone could pinpoint what doesn't support JS nowadays. (excluding some old phones) As switching off JS in modern browsers is an 'advanced' option and most normal users do not even know what it is. And those who are knowledgeable enough to switch it off I hope know they cannot live without it to use major websites. Google/Facebook and anything else uses JS nowadays so... it will probably be switched on.

Gunglien. You are right: most people (by far!) have JS enabled (even most screenreaders execute JS nowadays). I did not mean to come acros as pedantic but just a little side-note.

IMO Progressive Enhancement should be basic approach in these issues: support the most basic functionality (in your case: have a functional, submittable, form without JS) and enhance for UA's that support that.

Again: I guess support for JS-off scenario should be a discussed per-project (there's many issues involved). However: a Progressive Enhancement approach is a great baseline.

Apart from the issue of JS support there's the issue of JS functionality: at the moment one bug in your (site-wide) JS could prevent your form from submitting.

Especially with forms (often related to the most important conversions in one's site) I would not want to risk forms not submitting when there's a bug in JS. And there could be a lot of issues preventing proper JS execution: (bugs in) third-party plugins, JS-loading issues, etc.

Again: not to be pedantic, just a side-note on why I personally believe forms should be able to submit without JS.

Well fairly true about the JS breaking if there is an issue. However most breaks are not site-wide.

In my day-job I work mainly one one site whose complete business model is based on the website and web-forms. (more or less) new clients are gained by opening accounts via forms - which we submit to a third-party system. So if we break these form we're guaranteed to lose potential clients to forms are critical to us.

However it has enabled us to provide a better client interaction as we do not take them away from the current page; eg having a contact form on fixed position on every page - if a potential client has a question we never take him away from his current page.

To prevent JS breaking usually we work on a 2 tier level before going to production. First Local - then to a staging environment & after that we go live. If we have a problem in the JS usually its spotted in the first two stages as the files are minified (js) and any break would stop the rest of JS from working. However when we do in-page JS this does not break other functionality most of the time. So you can have broken blocks whilst the rest of the stuff still works.

But as you say its a per-project consideration, and depends on personal opinion as well. Ideally a form should work on any browser; similarly to the fact that a website should look the same on all browsers.

But then i'd take into account feasibility - Nowadays I've dropped support for IE6 for example because it's not worth the time anymore. Similarly considering the widespread support of JS there's a question weather it is worth going for dual support rather then for a simple approach taking into consideration spam and other arising issues which to choose.

Not saying that I'm doing the correct thing; but I like to keep things time-friendly. Less time spent the better - hence the use of Symphony :)

ps sorry if this looks like a rant :)

No rant, valid points. So, (back to the topic ;) ) we can conclude there are a couple of valid ways around the 'form resubmission issue':

1. Make use of the post/redirect/get pattern: redirect (pref. 303) to a different page after submit
2. Hijack the form submit with JS and handle the submission with JS (e.g. AJAX)
3. Construct some Unique ID and check that on submit. Submit is allowed only once per ID

That should give most people running into this issue some options to work with ;)

Regarding JS, yesterday I was getting frustrated because I couldn't submit a simple form on a website - the form was being handled with JS.

Only later I found out that I'd forgotten to restart the browser after some updates, and apparently JS was not loaded correctly.

So, it's not always a bug in the website; as David suggested it could be an issue on the client's computer, so maybe an important thing such as form submission shouldn't rely on JS.