638842 - NetConductor Login broken due to <input </form> parsing as <input form=""> and disassociating field from form

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Joel Gerber]

User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

On a proprietary vendor website, they have a login form that asks for a username and password. When you click on ok, it logs you into the system.

On their form, they have an input field that looks like this:
<input type="hidden" name="action" value="login"
Notice the missing closing '>'.

On Firefox 3.6 it still worked fine, but in Firefox 4 Beta 12, it does not send action=login through to the login script. I have verified that this is the issue, because when I save the source code, add a base href in the top to locate me on their web-server, and then add the closing '>' the form works.

Reproducible: Always

Steps to Reproduce:
1. Try to login to website
Actual Results:  
The form reloads as if I hadn't inputted anything.

Expected Results:  
Logged me into the website.

Comment 1

[Ed Morley [:emorley]]

Firefox 4 uses the new html5 parser, which is more strict about incorrectly written html. You will likely find that the page does not function in Chrome 11 dev latest and other new browsers, since the general direction has been (correctly in my opinion) towards being more strict about web standards.

In short: The vendor just needs to update their website and include the extra ">".

Comment 2

[Joel Gerber]

Is there anyway to use the html4 parser for a particular site?

Comment 3

[Boris Zbarsky [:bzbarsky]]

That said, this should still work in many cases...  Joel, can you attach the relevant HTML snippet (e.g. what comes after the <input> tag in comment 0)?

Ed, the HTML5 parser is not "more strict".  It's just strict in some cases where our old parser was lax (but IE's parser, say, was strict)...  It's laxer than our old parser in other cases.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Joel, there is not.  And the old parser is going away entirely in a few months, note.

Comment 5

[Ed Morley [:emorley]]

(In reply to comment #3)
> Ed, the HTML5 parser is not "more strict".  It's just strict in some cases
> where our old parser was lax (but IE's parser, say, was strict)...  It's laxer
> than our old parser in other cases.

Thanks for the clarification :-)

I was just looking to see who was most appropriate to CC for confirmation on whether this break was expected, but guess that's been answered now!

Comment 6

[Boris Zbarsky [:bzbarsky]]

Well, most appropriate is Henri, but I think he watches this component.

Comment 7

[Joel Gerber]

Attachment: This is the entire HTML file for the problem login page

Comment 8

[Joel Gerber]

Boris, check the attached file and let me know if there is anything else I can do.

Comment 9

[Boris Zbarsky [:bzbarsky]]

That's perfect.  The relevant markup is:

  <input type="hidden" name="action" value="login"</form>

which parses the same way as:

  <input type="hidden" name="action" value="login" form="">

(well, it also has an attribute named '<' but that's not important.

The key part here is that HTML5 allows an <input> to explicitly specify the form it belongs to by putting its id in the attribute named "form"; http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#reset-the-form-owner describes how this works.  In particular, since form="" doesn't match any of the forms in this document, the <input> is not considered to be part of any form, and hence is not submitted.

So far this all looks correct per spec to me.

Comment 10

[Joel Gerber]

Thanks for everyone's input!

I'll forward this off to the vendor and hopefully get a fix for it before I die of old age :) Have a great weekend.

Comment 11

[Henri Sivonen (:hsivonen)]

(In reply to comment #9)
> That's perfect.  The relevant markup is:
> 
>   <input type="hidden" name="action" value="login"</form>
> 
> which parses the same way as:
> 
>   <input type="hidden" name="action" value="login" form="">

Interesting how a new feature and IE-compatible tokenization conspire together to break existing content. Unfortunately, at this point both Firefox 4 and the HTML5 spec are too committed to both behaviors to change either because of this.

> So far this all looks correct per spec to me.

Agreed. Over to evang.

Comment 12

[Mounir Lamouri (:mounir)]

Joel, could you give us the URL of the website? Googling "NetConductor" didn't give me a straightforward answer (first result is Rue de Net which doesn't really seem to be related).
If you did contact them, could you keep us informed of the answer here?

Comment 13

[Joel Gerber]

Hello Mounir,

NetConductor is an Element Management System for a VoIP Media Gateway. The following URL is a product description for the device it manages: http://www.audiocodes.com/products/orca-btx-4k

I will make sure to update this bug when I've managed to contact them and have opened a case.

Comment 14

[Joel Gerber]

I've just opened a case. I'll let you know what I hear from the vendor.

Comment 15

[Hixie (not reading bugmail)]

Any news on this?

Comment 16

[Joel Gerber]

Unfortunately, not yet. The equipment vendor is dragging their feet big time on this.

Comment 17

[Karl Dubost💡 :karlcow]

Joel, was it solved?

Comment 18

[Joel Gerber]

(In reply to Karl Dubost :karlcow from comment #17)
> Joel, was it solved?

No, and they've discontinued the product so I'm not likely going to get a fix.

Comment 19

[Karl Dubost💡 :karlcow]

Thanks.
closing as INVALID then.