324770 - submit button does nothing at http://www.pbtprofiler.net/notice.asp

Status: RESOLVED DUPLICATE of bug 22480

(Core :: DOM: HTML Parser, defect)

Description

[Corey Hickey]

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.

Comment 1

[Ben Fowler]

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.

Comment 2

[Martijn Wargers (dead)]

Attachment: testcase

Comment 3

[Martijn Wargers (dead)]

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.

Comment 4

[Martijn Wargers (dead)]

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

Comment 5

[Corey Hickey]

Attachment: libpcap (tcpdump/ethereal) capture of firefox POST

Comment 6

[Corey Hickey]

Attachment: libpcap (tcpdump/ethereal) capture of konqueror POST

Comment 7

[Corey Hickey]

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

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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?

Comment 10

[Boris Zbarsky [:bzbarsky]]

I filed bug 324828 on the flushing issue.

Over to parser; given the DOM being created here, the behavior is correct.

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

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