Firefox Form Difficulty

// November 4th, 2005 // Technology Bits

I had this form that I kept getting reports about it not working.  I knew the form had not changed in over a year, so was confused by the report.  I fired up Internet Explorer, tested it, it worked perfect.  However, the form didn’t work at all in Firefox.  Looking at it, it seemed pretty simple, so what was the issue?

So, I took the form and started some known array debugging techniques, mainly a simple print_r($_POST) which showed all the array elements with proper values in IE, but with Firefox they all had the default form values.  Strange.

So, I copied the form out of the overall application, dropping included functions, libraries, and global variables.  Just taking the standalone form and posting it to a PHP script that only print_r()’d the $POST array.  Still did it.

It then dawned on me that I should try just a simple hand coded form unrelated to this example to make sure I didn’t have a flawed Firefox install, and in turn be certain it could process forms.  Of course it could, this was good.  Something was wrong with my form specifically.

I then boiled the form down to be extremely simple, removing various elements one at a time until the form functioned properly, which it eventually did.  I had then narrowed it down to be related to the <input type=”reset” name=”reset” value=”reset” /> button.  At this point I jumped to the conclusion that maybe Firefox had messed up the reset button implementation, so made a simple form using it, and it worked fine…

Now I knew the reset was related, but not the sole cause, so what was different?  For some reason, the reset and submit buttons had a <label> tag around them.  I know, this doesn’t make any sense, but it also shouldn’t cause this level of difficulty.

Anyway, here’s a simplified version of a troubling form:

<form method=”post” action=”show_post.php”>
 <input name=”example” type=”text” size=”40″ value=”{something default}” />
 <label>
  <input type=”reset” name=”reset” value=”Reset” />
  <input type=”submit” name=”Submit” value=”Submit” />
 </label>
</form>

Test it out here and you’ll see what I mean (hopefully).
PHP, firefox, internet explorer, html, xhtml, form

Related items

21 Responses to “Firefox Form Difficulty”

  1. Matt says:
    November 4, 2005 at 3:38 pm

    Yeah, it doesn’t work in Firefox. However, its probably an intentional bug to cause f-tards that build forms like that to have a hard time forcing them to leave the web development community forever. Anyone that places label tags around reset and submit buttons should be taken out and shot.

    Some people are squirrel handed. Thank you. That is all.

  2. zbtirrell says:
    November 4, 2005 at 7:02 pm

    You may have a point…

  3. dts says:
    May 4, 2006 at 5:54 pm

    firefox having lots of other javascript issues.

  4. Allan says:
    May 26, 2006 at 2:25 pm

    I’m having a similar problem that I had working in test scenarios, then I went to a full implementation (with very little code change) and it stopped working correctly in Firefox. The form is an auto-looping form that works with AJAX to request data from a database. In Firefox the autorun() function runs through once and the document.form[0].submit() function works the first time. When I recall the autorun function for the second iteration the document.form[0].submit() function fails, but Firefox does not specify an error. I know the code is correct and everything works in IE, but Firefox gives issues.

    The strange part is I have a similar function to submit data to a database which works perfectly with the same structure. I believe it’s a major Firefox issue with Javascript and forms that should be resolved sometime soon.

  5. zbtirrell says:
    May 26, 2006 at 3:43 pm

    What is your purpose for doing that?

  6. Gurvinder Singh Manjotra says:
    July 4, 2006 at 3:03 am

    Of course form submission wouldn’t work out in FireFox. The solution behind is write all html tags like ….. which recognizes & will submit the document.

    Gurvinder Singh Manjotra
    Project Manager
    Contact : gs_manjotra@yahoo.com

  7. Badfox says:
    July 17, 2006 at 1:46 pm

    Firefox is so buggy, I wish I didn’t have to write pages that support it. It takes up so much extra development time it’s ridiculous. World Firefox Day is when I tell people to stay the hell away from it.

  8. lego says:
    September 13, 2006 at 10:44 am

    according to the w3c specification you are never allowed to have an end tag on the tag which you have with the in your example.

    check out http://www.w3.org/TR/html4/interact/forms.html

  9. zbtirrell says:
    September 13, 2006 at 1:31 pm

    You are absolutely correct. The above code is 100% bad. But… as anyone knows who writes much HTML, mistakes happen. I merely posted so others may be able to find their problem through my ignorance.

  10. Troy Farrell says:
    January 16, 2007 at 12:38 am

    Actually, the behavior you describe is not a bug in Firefox. It is a bug in the HTML. Only one input element is allowed inside a label element. You will find similar behavior if you try to put two radio buttons inside a label element. The second cannot be clicked in Firefox.

    I’m thankful that the browser is actually forcing us to write proper code.

  11. zbtirrell says:
    January 16, 2007 at 10:08 am

    It still seems like bizarre reaction to the improper code. The button appears, but is not clickable? The browser bothers to render it, but doesn’t attach action to it appropriately? The counterintuitive nature of the way this renders is the bug here.

    Obviously the HTML is incorrect, but a significant power of HTML and browsers is their ability to carry on regardless of the ineptness of the code. The way this acts leads one on wild goose chases with debugging.

  13. Godkillah says:
    April 30, 2007 at 3:28 pm

    What a nonsense am i reading here?!
    Firefox is the best browser there is and spoken about javascript issues Internet explorer has lots more of them! for example with writing rows in tables, in firefox it could be as simple as
    document.getElementById(”test”).innerHTML+=”test”
    in IE it would require a page full of lines with DOM.
    im not saying FF doesnt have any issues at all but it has less than IE.

  14. foxhunter says:
    August 23, 2007 at 8:13 am

    :O Does FF even recognise JS? :O

  15. Manta says:
    November 21, 2007 at 8:22 pm

    I really don’t care who wins this silly browser war. All I want to see is a STANDARD, ONE STANDARD.
    I’ve been writing code for over twenty years now and it seems everyone is so wrapped up in being exclusive that they end up creating standards over and over again. In the end the only trueth is there are no standards, and until a true universal standard is adheared to all of us programmers will continue to curse ALL the platforms.

    IE: how many different compressors do you own? (zip, rar, ace, lha, arj, gzip, tar, gtar, dms, and about 10 others I can’t call off the top of my head).

    Standards? WHat Standards, they are a myth LMAO

    sorry, just my two sense worth

  16. Mel says:
    December 13, 2007 at 12:00 am

    good work manta…how much simpler would life be if the same code worked on all browsers?! Whoever has thought while designing a browser ‘now i know there are standards for this function, but hey…lets make up a new one specifically for this browser’ should make a career change to garbage collecting.

  17. Marc Ferguson says:
    December 17, 2007 at 5:11 pm

    Lots of IE/FF bashing going on (I’m on the winning side of course -> FF), but what about the solution to this problem? It seems that using a LABEL tag with multiple INPUT tags is a no no. I have a simple form used to take the user from one page to the next, not passing any values - it just uses onClick=’document.location={URL}’. The form works fine for IE, but FF doesn’t make the button clickable. Am I missing something? Here’s the code:

    I do apologize, I know this is not a forum, but I’m desperate for answers and desperate times calls for desperate measures, or something like that!

  18. Manta says:
    December 10, 2008 at 7:43 pm

    Meaning no disrespect Marc, but neither FF or IE are the winning side.
    In fact you seem to be as I was when I was an AMIGA enthusiast back in the 80’s, you might remember the AMIGA, it was light years ahead of its competition.
    In 1986 ir was out performing the PC with full stereo sound, 24bit graphics, and most importantly it was the FIRST computer to have a FULL pre-emptive multitasking OS. Alas, the marketing sucked and the major player was not really IBM or APPLE it was a company named Microsoft, who even though many of us hated Gates, had to admit was fast becoming the standard and even though they would not catch up until windows 95 in 1996 they still are the top dog.
    I agree in the respect that loyalist will continue to fiercly defend FireFox, Apple, Linux and other platforms, but in reality as long as CompUSA, Frys, BestBuy and others continue to market VISTA on every new computer built, that just like Beta vs VHS, the winner does not necessarily mean the best.
    I’m not sure where I was going with this other than to say IE will probably be around for a long time to come and just like FF both are not exactly standard compliant. In IEs case they invent new proceedures and in FFs case they just omit a lot of them.
    Neither are the winners in my opinion and we ALL end up being the losers because of stupid capitalist wars. (Making things different in order to make prisoners out of buyers). :-(

  19. Manta says:
    December 10, 2008 at 7:44 pm

    PS: sorry this comment is so late in coming, but I get involved with programming projects that use up more hours than I have in a day.

  20. Viermeariant says:
    January 2, 2009 at 7:54 pm

    mcxfzmcsdgnbuggnwell, hi admin adn people nice forum indeed. how’s life? hope it’s introduce branch ;)

  21. Manta says:
    March 13, 2009 at 5:04 am

    heheh, I was just cruising by and I reread this and wanted to add a more positive note for those struggling with forms and FF.
    Just a small point to remember I use it religiously and I don’t usually run into to many FF/IE form porblems, other crap yes, form problems no.
    My one stead fast rule is to make sure my form elements have both name=”" AND id=”", this is a big help in communicating with forms that are being manipulated by Javascript. Appearantly some, if not all (havent really paid attention) versions of FF do not handle form elements well unless they hav an id tag. So as a matter of practice I always include both.
    One other tip: watch out for javascript routines that generate an error while parsing form elements. IE: seems to just toss the error and move on (some errors) FF will not. for instance parsing values of form elements where one my be disabled. IE will handle it, FF will crap out. Not waying either is the better here, just offering this tip.. use a try/catch to deal with the exception so FF doesnt abort.

    Anyway thats my lighter note. :)

Leave a Reply

Sponsored Links