651115 - Form pointer reset on form controls when the Adoption Agency Algorithm changes the parent chain

Status: NEW

(Core :: DOM: HTML Parser, defect, P5)

Description

[Jim Garner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 GTB7.1
Build Identifier: Mozilla/5.0 (Windows NT5.1;RV:20) Gecko/20100101 Firefox/4.0

The actual line in the HTML is <input type="TEXT" name="initials" size="9" maxlength=8 value="%WWW.VAR.INITIALS%">, my server removes the %WWW.VAR.INITIALS% and sends only the two quotes for a null value.  Upon return the "initials" value is not returned.  This works under IE 8, Firefox 3.6.15 and only fails on Firefox V4.

Sent to Browser in both cases:

0174597036 14:26:09 8BAD90 00200540 Sendtrace(T): 118 - <input type="TEXT"                                              
 0174597037 14:26:09 8BAD90 00200540 Sendtrace(T): 119 - name="initials" size="9" maxlength=8 VALUE="">

Trace of Firefox V3 where it works shows the following coming back:

0174592251 13:00:29 8BAD90 00200514 URL   - rJATPHBRlTaKEtgyPcGSFIRov20wYN89hKgeW8YEXgMPKJx6gz2Vyo/xYGVtwDom2OBGx8dzeGs/
                                     8K/lPbmCuRbl+K1begcN5dmHzLPR35wkHWKZOKIPwn5s8dQx7zbsDZ26FJP/vkHE+v8am5umoPK/UgrhC4g8
                                     uvGEFF/KimoRHAbmRG7eUzN6PGxk4LHA0lqQ2I/23WLYGSgM9zi74Lme8LeCu8TIdYa7m/A7NwMOxAilBjlr
                                     nHrLrIi4AKVHEFBzxUB6y1FtJIFY/cgypjcForUY9INg9Ijar3pTMkUZDRGRDi3iH0AJgw5t3aWy7YnUDnLe
                                     TECfHw5EuC  Authorization: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  Content-Type: application
                                     /x-www-form-urlencoded  Content-Length: 136    function=RS&subtype=Submit+Initials+R
                                     equest&page=RESTORE&initials=garner9&likefn=Begins+With&fname=&likeln=BEG&lname=&Dis
                                     playnfo=Restore

Notice initials=garner9

on V4 the return is:

0174597101 14:26:17 8BAD90 00200542 URL   - 12861.23; __utmz=123533593.1301578730.9.2.utmcsr=google|utmccn=(organic)|utm
                                     cmd=organic|utmctr=dns; __utmc=123533593  Authorization: XXXXXXXXXXXXXXXXXXXXXXXXXX 
                                      Content-Type: application/x-www-form-urlencoded  Content-Length: 119    function=RS
                                     &subtype=Submit+Initials+Request&page=RESTORE&likefn=Begins+With&fname=&likeln=BEG&l
                                     name=&Displaynfo=Restore

Notice initials= is missing.

the next HTML stsatent was a </font>, I moved  this up before the <input> statement and now it works.

I'll include actual HTML before and after as an attachment (the button for an attachment is not present for some reason, I'll try to attach after submission, but if not send me a note and I'll supply the HTML), please note that the %WWW.VAR.INITIALS% are stripped by the server before being sent to the browser.




Reproducible: Always

Actual Results:  
Described above.

Expected Results:  
value of initials should have been returned.

Comment 1

[Jim Garner]

Attachment: This is the HTML that did not work. <input> statement is at line 112

Comment 2

[Jim Garner]

Attachment: THis is the version where I moved the </font> tag, <input> is now at line 110. I also removed the " around the value parameter, I had added the " in anattempt to fix the problem. it made no differenc

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

There's lots of wrongly nested <table>/<tr>/<td> tags.

My guess as to what's going on here is that the relevant <input> is moved around due to being in the wrong place in a <table> and moved out of the <form>.

So my guess is that implementing the HTML5 parser broke this.

Jim: would be great to have a smaller testcase to see what exactly broke this page. It's likely that most of the contents in your examples aren't relevant to reproducing the breakage here. With a smaller testcase it would be easier to see if this was an intentional change or not.

I *don't* think that actual form submission code changes are involved here. As far as I know none of the changes we made should be relevant to this testcase (i.e. there are no emptynamed or nameless <input>s, nor any <input type=image>)

Comment 4

[Jim Garner]

Attachment: Shortened version of HTML, this version fails. <input> at line 19

Comment 5

[Jim Garner]

Attachment: HTML that works. </font> moved up 2 lines, <input> now at line 20

By the way, this was written long ago by those no longer with us.  So, I'm not sensitive to any comments on how it is structured.  Probably a lot of this kind of stuff around the internet.

Let me know if you want me to do more.

Thanks,

Jim

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'll leave this up to Henri. I do think it would be interesting to know what type of markup stopped working. But it's not at all clear to me that we actually want to make any changes to firefox. A minimized testcase is needed to figure that out.

Like you say, there is a lot of this stuff on the internet. The HTML5 parsing algorithm does a really good job at being able to parse it all, but there is always room for improvement.

Comment 7

[Henri Sivonen (:hsivonen)]

The form association of the name=initials controls works exactly the same way in Chrome, so this has to be a feature of the HTML parsing algorithm. I haven't yet worked out why the placement of the </font> end tag affects the form association here.

Comment 8

[Henri Sivonen (:hsivonen)]

Minimized test case:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/939

I think what happens here is that </font> causes reparenting in the AAA and the reparenting resets the form pointer since the form pointer always resets when the parent chain changes.

So if we wanted to support this particular flavor of bogus markup, we should have a way for the parser to tell the DOM not to reset the form pointer on the form controls during a parent chain change. Apparently Opera Ragnarök doesn't reset the form pointer in this case.

Do we want to go there?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Apparently Opera Ragnarök doesn't reset the form pointer in this case.

On the face of it, this is a bug per the current spec text.

Also, shades of bug 635924.

Comment 10

[Henri Sivonen (:hsivonen)]

(In reply to comment #9)
> > Apparently Opera Ragnarök doesn't reset the form pointer in this case.
> 
> On the face of it, this is a bug per the current spec text.

Yes. Per spec, Opera is wrong and Firefox and Chrome are right.

Comment 12

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.