Closed Bug 671298 Opened 9 years ago Closed 6 years ago

Extraneous attribute in XHTML input control breaks submission


(Web Compatibility :: Desktop, defect)

Not set


(Not tracked)



(Reporter: dlooney601, Unassigned)




(Whiteboard: [needaccount] [country-us])


(2 files)

Attached file
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  Page (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="" >
 <input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />
Attachment #545672 - Attachment mime type: text/plain → text/html
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?
OS: Other → Linux

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

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).
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.
Component: General → HTML: Parser
OS: Linux → All
Product: Firefox → Core
QA Contact: general → parser
Version: 5 Branch → Trunk
Makes sense - form IS an input attribute under HTML5.

Also works if you add id="PSWD" to the form on the otherwise "broken" page ( --- 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.
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
Maybe we need a tracker for all these @form bugs....
I'm not sure I'm following you. The original attached page does have:

<form NAME="PSWD" method="POST" action="" >
<input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />

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" />

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 and linked it to local images and scripts, so the relevant code should not be different.
> The original attached page 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" 
         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.
Does this differ from original ?  If input is filtered, is form="PSWD" being filtered out ?
$ grep -n PSWD
21:  document.PSWD.newpin1.value="";
22:  document.PSWD.newpin2.value="";
902:                <form NAME="PSWD" method="POST" action="" >
929:                    <input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />                 

David Looney
> Does this differ from original ? 

Yes, this is differenet from the first attachment on this bug.  How did you produce the two attachments?
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
22:  document.PSWD.newpin1.value="";
23:  document.PSWD.newpin2.value="";
903:                <form NAME="PSWD" method="POST" action="" >
930:                    <input type="image" class="btn" src="/tsp/resources/images/btnLogin_Submit.gif" name="Submit" alt="Submit" form="PSWD" align="absbottom" />
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?
I will submit a comment to the site.
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 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.
Considering comment13, can you please change the status of this bug?
Assignee: nobody → english-us
Component: HTML: Parser → English US
Ever confirmed: true
Product: Core → Tech Evangelism
QA Contact: parser → english-us
Version: Trunk → unspecified
dlooney, Has it been fixed?
Assignee: english-us → nobody
Component: English US → Desktop
Flags: needinfo?(dlooney601)
Whiteboard: [needaccount] [country-us]
Looks like it has.
Flags: needinfo?(dlooney601)
Thanks. :)
Closed: 6 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.