Last Comment Bug 671298 - Extraneous attribute in XHTML input control breaks submission
: Extraneous attribute in XHTML input control breaks submission
Status: RESOLVED FIXED
[needaccount] [country-us]
:
Product: Tech Evangelism
Classification: Other
Component: Desktop (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://www.tsp.gov
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-13 09:15 PDT by dlooney601
Modified: 2014-09-21 22:31 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
newpin.do (34.50 KB, text/html)
2011-07-13 09:15 PDT, dlooney601
no flags Details
Password change form from tsp.gov (34.51 KB, text/plain)
2011-07-14 11:11 PDT, dlooney601
no flags Details

Description dlooney601 2011-07-13 09:15:29 PDT
Created attachment 545672 [details]
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] 2011-07-13 10:30:25 PDT
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 2011-07-13 13:39:41 PDT
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] 2011-07-13 15:43:26 PDT
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 2011-07-13 16:01:34 PDT
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 [:bz] 2011-07-13 20:58:45 PDT
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 [:bz] 2011-07-13 20:59:51 PDT
Maybe we need a tracker for all these @form bugs....
Comment 7 dlooney601 2011-07-14 08:38:14 PDT
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 [:bz] 2011-07-14 09:00:09 PDT
> 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 2011-07-14 11:11:13 PDT
Created attachment 545955 [details]
Password change form from tsp.gov

Does this differ from original ?  If input is filtered, is form="PSWD" being filtered out ?
Comment 10 dlooney601 2011-07-14 11:13:22 PDT
$ 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 [:bz] 2011-07-14 11:28:15 PDT
> 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 2011-07-14 11:43:06 PDT
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 [:bz] 2011-07-14 11:52:45 PDT
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 2011-07-14 13:34:35 PDT
I will submit a comment to the site.
Comment 15 Boris Zbarsky [:bz] 2011-07-14 19:53:38 PDT
Thanks!
Comment 16 dlooney601 2011-07-15 08:42:53 PDT
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] 2011-08-02 06:30:56 PDT
Considering comment13, can you please change the status of this bug?
Thanks.
Comment 18 Karl Dubost :karlcow 2014-09-21 17:36:50 PDT
dlooney, Has it been fixed?
Comment 19 dlooney601 2014-09-21 21:48:02 PDT
Looks like it has.
Comment 20 Karl Dubost :karlcow 2014-09-21 22:31:49 PDT
Thanks. :)

Note You need to log in before you can comment on or make changes to this bug.