Only 'form associated' elements have a potential form owner.

Only 'form associated' elements have a potential form owner.

The spec tells us that only certain elements have the notion of a form
owner,

 http://www.whatwg.org/specs/web-apps/current-work//#form-owner
 http://www.whatwg.org/specs/web-apps/current-work//#form-associated-element

Implement that selective notion of 'form owner' over elements. This aligns
with Gecko and Trident (IE11.)

For the associated bug, use such form ownership to provide the
expected chain of lexical environments when compiling event handlers.
Or, more to the point, not provide an enclosing form's scope if the
elemen isn't a form-associated element.

While making the required changes here, a slight bug in the handling of
an <option>'s ".form" property was spotted & is addressed here also.
i.e., a "free-floating" <option> (no <select> parent) within a form
should have a ".form" property mapped to null,

  http://www.whatwg.org/specs/web-apps/current-work//#dom-option-form

All other implementations follow the spec in this regard.

R=
BUG=324828
TEST=fast/forms/form-associated-element
TEST=fast/forms/form-attribute

[sof, 2013-12-09 17:41:09]

Please take a look when you have a chance.

[To make the spec correspondence clear, formOwner() is now provided over
HTMLElement instead of form(). IMHO, the renaming helps disambiguating what's
being implemented/provided when reading the code, but should using 'form()' be
preferable overall, I can readily be convinced to change it back.]

[tkent, 2013-12-10 02:01:36]

On 2013/12/09 17:41:09, sof wrote:
> Please take a look when you have a chance.
> 
> [To make the spec correspondence clear, formOwner() is now provided over
> HTMLElement instead of form(). IMHO, the renaming helps disambiguating what's
> being implemented/provided when reading the code, but should using 'form()' be
> preferable overall, I can readily be convinced to change it back.]

It's ok to rename it. However it makes the patch larger.  I prefer separating a
bug fix CL and a function renaming CL.

[sof, 2013-12-10 06:17:39]

On 2013/12/10 02:01:36, tkent wrote:
> On 2013/12/09 17:41:09, sof wrote:
> > Please take a look when you have a chance.
> > 
> > [To make the spec correspondence clear, formOwner() is now provided over
> > HTMLElement instead of form(). IMHO, the renaming helps disambiguating
what's
> > being implemented/provided when reading the code, but should using 'form()'
be
> > preferable overall, I can readily be convinced to change it back.]
> 
> It's ok to rename it. However it makes the patch larger.  I prefer separating
a
> bug fix CL and a function renaming CL.

Will do; renaming first, then changes to make formOwner() be form-associated
sensitive.

[sof, 2013-12-10 14:51:11]

Split up into

  https://codereview.chromium.org/93723003/
  https://codereview.chromium.org/102263006/
  https://codereview.chromium.org/106423005/

Closing this one as a result.