671298 - Extraneous attribute in XHTML input control breaks submission

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[dlooney601]

Attachment: newpin.do

User Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0.1) Gecko/20100101 Firefox/5.0.1
Build ID: 20110707182747

Steps to reproduce:

Tried to change password on https://www.tsp.gov.  Page newpin.do. (Attached. You can't get there without an account and password).


Actual results:

Pressing submit button with Firefox 5.0 and 5.01 resulted in no action. Control is dead. Extremely annoying.


Expected results:

Pressing submit in IE8, Safari, and Google Chrome resulted in form submission.

Editing the form and removing the nonstandard attribute (form="PSWD") resulted in the submit button being active in Firefox 5.0/5.0.1.  Firefox should ignore nonstandard attributes in xhtml input controls or handle them as IE8, Safari, and Google chrome do (interestingly, Opera 11.01 also chokes on this attribute).

Relevant code follows and page attached:
<form NAME="PSWD" method="POST" action="newpin.do?acttype=y&_name=custpin" >
....
 <input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />
....
</form>

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Can't reproduce against 5/Trunk with the attached Site's Copy.
You can't hook up a reduced Testcase showing the Issue by Chance, do you?

Comment 2

[dlooney601]

http://molbiocore.ucsd.edu/testinput/broken.html

Nothing happens when password fields are completed and submit is pressed. 

http://molbiocore.ucsd.edu/testinput/fixed.html

Submits passwords to script when submit button is pressed.

Pages differ only by presence of form="PSWD" in submit input in broken version vs. absence in fixed version (at least under firefox 5.0.1 linux i686).

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110713 Firefox/8.0a1 ID:20110713030741

It works with html5.parser.enable;false.

Comparison: Opera Next behaves like Firefox, Google Chrome 14 like Firefox 3.6.

Comment 4

[dlooney601]

Makes sense - form IS an input attribute under HTML5.

Also works if you add id="PSWD" to the form on the otherwise "broken" page (http://molbiocore.ucsd.edu/testinput/fixed2.html) --- so it's broken if the html5 parser is running and looks for the PSWD element to submit the form data to and doesn't find it.

Comment 5

[Boris Zbarsky [:bzbarsky]]

If the HTML5 parser is not enabled, that input ends up associated to its ancestor form even though it has an @form, which is wrong.  The HTML5 parser behavior on the "broken" testcase in comment 2 is correct.

That said, the testcase in comment 2 doesn't have the same structure as the site attached in comment 0.  That site doesn't have a "form" attribute on the element...  What does the actual site source look like?

Also of note, Chrome's implementation of @form appears to just be broken: see https://bugs.webkit.org/show_bug.cgi?id=64509

Comment 6

[Boris Zbarsky [:bzbarsky]]

Maybe we need a tracker for all these @form bugs....

Comment 7

[dlooney601]

I'm not sure I'm following you. The original attached page newpin.do does have:

<form NAME="PSWD" method="POST" action="newpin.do?acttype=y&_name=custpin" >
...
<input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />
...
</form>

though it's a bit hard to find.  The "broken" testcase has:
<form NAME="PSWD" method="POST" action="/cgi-bin/showpin.cgi" >
...
<input type="image" class="btn" src="./img/submit.png" name="Submit" alt="Submit" form="PSWD" align="absbottom" />
...
</form>

The fixed.html testcase just removes form="PSWD" from the input.  The fixed2.html testcase inserts id="PSWD" in the corresponding <form ... > statement. I just cut and pasted the password section code from newpin.do and linked it to local images and scripts, so the relevant code should not be different.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> The original attached page newpin.do does have:

Could you please tell me what line of that HTML you see that on?  Because I've just looked again, just to make sure, and while there is a form NAME="PSWD"> , the image input inside that <form> looks like this:

  <input type="image" class="btn" 
         src="/tsp/resources/images/btnLogin_Submit.gif"
         name="Submit" alt="Submit" align="absbottom" />

It has no attribute named "form".  And clicking the 'Submit' alt text on the attachment submits the form fine, as expected.

Comment 9

[dlooney601]

Attachment: Password change form from tsp.gov

Does this differ from original ?  If input is filtered, is form="PSWD" being filtered out ?

Comment 10

[dlooney601]

$ grep -n PSWD newpin.do
21:  document.PSWD.newpin1.value="";
22:  document.PSWD.newpin2.value="";
902:                <form NAME="PSWD" method="POST" action="newpin.do?acttype=y&_name=custpin" >
929:                    <input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />                 

David Looney

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Does this differ from original ? 

Yes, this is differenet from the first attachment on this bug.  How did you produce the two attachments?

Comment 12

[dlooney601]

I saved the source (Ctrl-U) from the page. I was playing with the page, maybe I uploaded a version where I deleted the form attribute (sorry, thought I renamed to testinput.html before changing) ?  The attachment type was changed after uploading.  The form="PSWD" is definitely in the input control originally saved from the site.

Hhmm, just redownloaded it.  Pages differ by ~1000 bytes in size (??) but still has the form attribute in the input:

$ grep -n PSWD newpin.do.2
22:  document.PSWD.newpin1.value="";
23:  document.PSWD.newpin2.value="";
903:                <form NAME="PSWD" method="POST" action="newpin.do?acttype=y&_name=custpin" >
930:                    <input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />

Comment 13

[Boris Zbarsky [:bzbarsky]]

OK, thanks.  Yeah, that sounds like the site is just broken...  Are you willing to send them mail about, since you're a customer and all?

Comment 14

[dlooney601]

I will submit a comment to the site.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Thanks!

Comment 16

[dlooney601]

One last suggestion - I know you consider firefox is "doing the right thing", and it is consistent with the flow indicated for changing the form owner at www.whatwg.org to leave the input unassigned (though I'm not sure I understand the rationale of leaving the input unassigned vs. reverting to assigning to the proximate form element); however, it would be very helpful for debuging  if the unassigned input would show up in the error console (form "whatever" not found for input foobar, leaving unassigned ...."), as I suspect misuse of the input form attribute may be quite common for a while.

Comment 17

[Vlad [QA]]

Considering comment13, can you please change the status of this bug?
Thanks.

Comment 18

[Karl Dubost💡 :karlcow]

dlooney, Has it been fixed?

Comment 19

[dlooney601]

Looks like it has.

Comment 20

[Karl Dubost💡 :karlcow]

Thanks. :)