FireFox Submits Forms Twice?

Discuss how to use and promote Web standards with the Mozilla Gecko engine.
Post Reply
sparhawksdotcom
Posts: 6
Joined: May 27th, 2007, 12:19 am

FireFox Submits Forms Twice?

Post by sparhawksdotcom »

(see http://forum.powweb.com/showthread.php? ... post417534 where I have posted this same problem, but I have skipped to the most recent issue in that thread here)

I have a couple of forms that are misbehaving in FireFox, but work fine in IE.
In all the affected forms:
* The person enters data into forms, using any combination of text fields, textareas, radio buttons, and SELECT fields.
* The person clicks a submit button.
* A javascript function validates all of the fields entered, and stops the submission if there is an error.
* Once the validation is complete, and the form is ready for submission, the script submits the form.

Sample (obviously not working code):

<html>
<head>
<script>
function checkAndSubmitMe()
{
// do something, like form field validation before submitting
if (ready to submit) {
return true; // submits the form
} else {
return false; // do nothing, do not submit the form
}
}
</script>
</head>
<body>
<form id="myForm" name="myForm" action="form.cgi" method="post" onsubmit="return checkAndSubmitMe()">
Some form fields here<br/>
<input type="submit" value="Check First">
</form>
</body>
</html>


n FireFox (tested in v2.0.0.1 & v2.0.0.3):
* if the form validates correctly (tested by the "if (ready to submit)" above), it gets submitted twice: once with all of the data, and once with all fields blank (or default).

And, some more information:
My CGI "action" script sends an e-mail to me with the contents of the form. When the person uses IE, I get the one correct e-mail submission. When the user browses with FireFox, I get one correct submission and one blank submission.

I am using POST because some of the data fields can contain long data, and the URL gets messy with GET.

Using the Perl variable $ENV{'REQUEST_METHOD'}, I checked to see how the form was getting submitted. To do this, I simply appended the value of $ENV{'REQUEST_METHOD'} in the text of the e-mail submission.
On the first (correct) submission, the request method is POST, as I wrote in the above form.

On the second (blank) submission, the request method is GET. This is not written anywhere in my code.

Why is FireFox submitting the form once with POST (as my code requests), and then resubmitting it with GET, with no data?
old np
Posts: 0
Joined: December 31st, 1969, 5:00 pm

Post by old np »

Are you sure it's Firefox submitting the form twice and not your server doing a redirect or something? You can check the headers with LiveHTTPHeaders or Firebug,
sparhawksdotcom
Posts: 6
Joined: May 27th, 2007, 12:19 am

Post by sparhawksdotcom »

Doing a bit more troubleshooting (because I don't know how to use LiveHTTPHeaders or Firebug), I have found the following:

The form gets submitted to a perl script file (call it form.cgi) for processing. This page uses the data entered into the page (using POST) to create an e-mail that is sent to me. Once the e-mail is sent, the form.cgi page builds and displays a confirmation screen.

If I disable the confirmation screen display (and either have it show a simple white screen or an HTTP 500 message), the e-mail is only sent once, using the POST data. I have it show the simple white screen by coding:
print "Content-type: text/html\n\n";

I force the HTTP500 error simply by commenting out this line so nothing goes to the browser.


If I let the confirmation screen display, the e-mail gets sent twice, once with the POST data, and once with no data (but listed as GET).
sparhawksdotcom
Posts: 6
Joined: May 27th, 2007, 12:19 am

Post by sparhawksdotcom »

np wrote:Are you sure it's Firefox submitting the form twice and not your server doing a redirect or something? You can check the headers with LiveHTTPHeaders or Firebug,


If it was the server misbehaving, why would the problem only occur in FireFox?
Again, the double-submission does NOT happen in IE.
sparhawksdotcom
Posts: 6
Joined: May 27th, 2007, 12:19 am

Post by sparhawksdotcom »

I figured it out.
I posted the solution here.

To sum it up, though: on the confirmation screen (generated by the "form.cgi" which is run when the form is submitted) I had an image that was manipulated by Javascript.

The image tag was written like:
<img id="randompicimg" name="randompicimg" src="" height="50px" width="50px">


The SRC attribute was intentionally left blank because a couple lines down the page a javascript function generates a random image from a list and uses Javascript to load the image into that tag.

The problem comes from how IE and FireFox handle an IMG tag with an empty SRC attribute.

IE substitutes in the current URL without the current filename (like "www.myfakesite.com/currentfolder"). Since this would be (if it exists) an HTML file, and HTML files can't be displayed in an IMG tag, you get the 'broken image' picture.

FireFox substitutes the current URL with the current filename (like "www.myfakesite.com/currentfolder/form.cgi"). Since the CGI script doesn't return an image, FireFox shows the "broken image" picture. Since this page does exist, the script is run, but with no POST data. Since the script is run, the e-mails that the script generates are generated again, and since no POST data is passed through, it generates the e-mails without the needed data.

Follow this link for a more detailed explanation..
dtobias
Posts: 2098
Joined: November 9th, 2002, 3:35 pm
Location: Boca Raton, FL
Contact:

Post by dtobias »

It would be better, I think, to have the server-side script do the random image selection itself, and insert the correct image reference; that would avoid the need for a dummy image, and would work even for users that disable Javascript. If you're generating the whole page by a server-side process, there's no need to use client side scripting for some of the logic.
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/
Dan's Mail Format Site: http://mailformat.dan.info/
sparhawksdotcom
Posts: 6
Joined: May 27th, 2007, 12:19 am

Post by sparhawksdotcom »

I would normally agree, but the image is changed via javascript based on the location of the cursor on the page, similar to a rollover image, so server-side wouldn't work.
dtobias
Posts: 2098
Joined: November 9th, 2002, 3:35 pm
Location: Boca Raton, FL
Contact:

Post by dtobias »

In such cases there should be a reasonable "default" starting image to be used until it's replaced by the Javascript... that way it's never in a weird state like having a null image reference even for an instant.
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/
Dan's Mail Format Site: http://mailformat.dan.info/
sparhawksdotcom
Posts: 6
Joined: May 27th, 2007, 12:19 am

Post by sparhawksdotcom »

valid point
Billapepper
Posts: 3
Joined: February 25th, 2005, 6:41 pm

Post by Billapepper »

I'm having this same problem, however, it is with ANY broken image link... not just a "null" image. If you change your POSTs to GETs then there isn't any problems as well, because the form's get data will override the erroneous get data...
I think broken javascript, style sheet, etc files cause the problem as well... I had fixed it, and now all of a sudden the issue began again, and I can't seem to narrow it down because I can't find a broken <link>, <script> or <img> tags within the page.

Anybody know other causes to this problem?
User avatar
BenBasson
Moderator
Posts: 13671
Joined: February 13th, 2004, 5:49 am
Location: London, UK
Contact:

Post by BenBasson »

Interesting thread. According to the HTML spec, the src attribute of an image is a URI. The URI spec says this:

4.2. Same-document References

A URI reference that does not contain a URI is a reference to the current document. In other words, an empty URI reference within a document is interpreted as a reference to the start of that document, and a reference containing only a fragment identifier is a reference to the identified fragment of that document. Traversal of such a reference should not result in an additional retrieval action. However, if the URI reference occurs in a context that is always intended to result in a new request, as in the case of HTML's FORM element, then an empty URI reference represents the base URI of the current document and should be replaced by that URI when transformed into a request.

As far as I can tell, the implied base URI of a document is the document URI itself, and as images are all independent requests, it seems that Firefox has the "technically" correct behaviour in the case of a null src attribute, although IE is clearly doing the more desirable thing.

As for "any broken image", a working testcase might be the best plan.
Post Reply