User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20060112 Debian/1.5.dfsg-4 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20060112 Debian/1.5.dfsg-4 Firefox/1.5 Upon going to the URL listed and clicking on the button that says "I have read and understand", the server sends me straight back to the same page. I don't know if this is a bug in Firefox or in the web page, but, for what it's worth, it works fine in Konqueror. Reproducible: Always Steps to Reproduce: 1. go to http://www.pbtprofiler.net/notice.asp 2. click the big button near the bottom: "I have read and understand..." Actual Results: The server sends Firefox the same page. I suspect Firefox isn't posting the right information, but I don't really know for sure. Expected Results: The server should send Firefox a different page. This isn't an amd64-specific bug; I've tested it on i386 Linux as well.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050822 Firefox/1.6a1 I suspect that the problem is that the form has two MoreText hidden fields. This may confuse either the javascript or the origin sites POST data parsing. If you want to take this further, you may want to check the actual POST data being sent (using a network sniffer) and see whether these differ between Firefox and Konqueror. In principle, there may be no objection to matching Konqueror's behaviour provided that it is standards compliant, but there may be no willingness to do this if it simply turns off another set of faulty pages when turning on ones like this.

This regressed between 2005-04-05 and 2005-04-06: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-05+05%3A00%3A00&maxdate=2005-04-06+07%3A00%3A00&cvsroot=%2Fcvsroot I suspect bug 286000 to be the culprit. Maybe this is also a parser issue. Mozilla insists on putting the second input tag in the form (this behavior did not change), while IE6 just keeps it outside of the form.

Testcase needs to be tested locally, to be able to see the bug.

Thank you for your responses -- I really wasn't expecting anything so soon. :) I have attached capture files of firefox and konqueror behavior on the site in question. Also, I downloaded the test case and viewed it locally -- the URL in the URL bar is indeed: file:///tmp/324770_submit_does_nothing.htm?MoreText=failed&MoreText=failed Thanks, Corey

So on the testcase attachment, I see us change behavior between 2005-01-24-07 and 2005-01-25-07 builds. In the 2005-01-24 build both inputs are kids of the <form>, but document.Form1.MoreText is an HTMLInputElement, not a NodeList (which is what it is in later builds). Not sure yet what checkin in that range caused the change. But the old behavior seems to me to be pretty clearly wrong. On the original URL (the site), I do NOT see the 2005-01-25 build fail. So something else is possibly going on there? The site did regress in the range indicated in comment 3.

Regression range for the testcase: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-01-24+05&maxdate=2005-01-25+06&cvsroot=%2Fcvsroot Though again, I think the behavior of the testcase before was clearly wrong given the DOM it ends up with. I suspect bug 139568 "fixed" it in that it led to the content model being up to date when things ran... The real issue there was that nsHTMLFormElement::ResolveName does not flush. It should. Then the BindToTree changes landed and changed the ordering of content insertion, which made things consistent (and made the site consistently break). Blake, don't we have a bug on the parser issue here?

I filed bug 324828 on the flushing issue. Over to parser; given the DOM being created here, the behavior is correct.

*** This bug has been marked as a duplicate of 22480 ***