This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17845 - Some algorithms in the HTML Parser must also override the "reset the form owner" (e.g., Adoption Agency algorithm)
Summary: Some algorithms in the HTML Parser must also override the "reset the form own...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 07:01 UTC by contributor
Modified: 2013-05-28 23:07 UTC (History)
5 users (show)

See Also:

Attachments

Description contributor 2012-07-18 07:01:42 UTC 
This was was cloned from bug 16845 as part of operation convergence.
Originally filed: 2012-04-24 23:00:00 +0000
Original reporter: Travis Leithead [MSFT] <travil@microsoft.com>

================================================================================
 #0   Travis Leithead [MSFT]                          2012-04-24 23:00:02 +0000 
--------------------------------------------------------------------------------
We traced a real-world site issue [1] to an ambiguity in the HTML5 parsing spec regarding the magical "form owner". For a refresher, the HTML5 spec says:

4.10.18 >

| When a form-associated element's ancestor chain changes, e.g. because
| it or one of its ancestors was inserted or removed from a Document, 
| then the user agent must reset the form owner of that element. The 
| HTML parser overrides this requirement when inserting form controls.

...so, DOM operations that move elements around should reset the form owner. Cool. So, then what's the caveot with the HTML parser? It's here:

8.2.5.1 >

| If an element created by the insert an HTML element algorithm is a 
| form-associated element, and the form element pointer is not null, 
| and the newly created element doesn't have a form attribute, the 
| user agent must associate the newly created element with the form 
| element pointed to by the form element pointer when the element is 
| inserted, instead of running the reset the form owner algorithm.

...OK. This only identifies the "insert an HTML element algorithm" as meeting this requirement. This is what IE10 implemented. However, it turns out that the above exception is too narrow. 

4.10.18 should add that any algorithm employed by the HTML5 parser (such as the Adoption Agency algorithm), also overrides this behavior. Suggested text for the note:

"Note: The HTML parser overrides this requirement when inserting *or re-arranging* form controls, such as in the Adoption Agency algorithm."

The modified note above appears to match the behavior we are seeing currently in Firefox and Chrome, and is compatible with existing web content.

[1] http://www.elightbulbs.com/shopping_cart_process.cfm?action=pre_checkout
================================================================================
Comment 1 Ian 'Hixie' Hickson 2012-12-02 04:34:03 UTC 
Well the suggested change would do anything, since that note is non-normative.

Here's a test demonstrating the issue:
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1971

The <input> is part of a subtree that is regrafted by the AAA.

In WebKit and Gecko (and per the spec) the reset button shouldn't reset the input control, because they end up in different forms (the input doesn't end up in a form at all, in fact). In Opera and presumably in IE now, the input ends up in the form, so the reset does work; the idea being that the AAA avoids making mutations that trigger the form owner resetting code.

Travis, do you have a test case demonstrating that Gecko and WebKit do what you're proposing? The test above seems to suggest it doesn't.

hsivonen, abarth: Any opinions on whether we should change the spec here?

If this is the only compatibility issue we know of, I'm definitely leaning towards not changing it. Having said that, I looked at the page and couldn't work out which form control was the one with difficulties. Did it change? Are there steps to reproduce this problem?
Comment 2 Adam Barth 2013-02-12 23:24:34 UTC 
We haven't run into any compatibility problems with WebKit's current behavior.  I don't see any explicit code in the adoption agency implementation in WebKit that mentions the magical form owner but it's possible that there's something happening implicitly in the DOM machinery.
Comment 3 Ian 'Hixie' Hickson 2013-04-08 20:42:00 UTC 
Travis, please reopen this bug if you can provide more information on what exactly is the compatibility problem (e.g. steps to reproduce it in another browser) or if you can provide a test case that demonstrates how the behaviour you want matches more than one browser but doesn't match the spec. See comment 1.

In the meantime I'm marking this WORKSFORME based on the test in comment 1 and the information in comment 2.
Comment 4 Travis Leithead [MSFT] 2013-05-22 17:09:47 UTC 
(In reply to comment #3)
> Travis, please reopen this bug if you can provide more information on what
> exactly is the compatibility problem (e.g. steps to reproduce it in another
> browser) or if you can provide a test case that demonstrates how the
> behaviour you want matches more than one browser but doesn't match the spec.
> See comment 1.
> 
> In the meantime I'm marking this WORKSFORME based on the test in comment 1
> and the information in comment 2.

OK. I can't seem to drum up the old data, so this resolution is fine by me.
Comment 5 Ian 'Hixie' Hickson 2013-05-28 23:07:14 UTC 
Travis: Roger. Thanks for looking!