Extraneous attribute in XHTML input control breaks submission

RESOLVED FIXED

Status

Tech Evangelism
Desktop
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: dlooney601, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
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>
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
(Reporter)

Comment 2

6 years ago
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).
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
(Reporter)

Comment 4

6 years ago
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.
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
Maybe we need a tracker for all these @form bugs....
(Reporter)

Comment 7

6 years ago
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.
> 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.
(Reporter)

Comment 9

6 years ago
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 ?
(Reporter)

Comment 10

6 years ago
$ 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
> Does this differ from original ? 

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

Comment 12

6 years ago
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" />
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?
(Reporter)

Comment 14

6 years ago
I will submit a comment to the site.
Thanks!
(Reporter)

Comment 16

6 years ago
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

6 years ago
Considering comment13, can you please change the status of this bug?
Thanks.
Assignee: nobody → english-us
Status: UNCONFIRMED → NEW
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]
(Reporter)

Comment 19

3 years ago
Looks like it has.
Flags: needinfo?(dlooney601)
Thanks. :)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.