bindings: Moves [OverrideBuiltins]'s attributes to the prototype chain.

bindings: Moves [OverrideBuiltins]'s attributes to the prototype chain.

In short, [OverrideBuiltins] extended attribute requires that
indexed/named properties appear on the instance object.  Attributes
which are not named properties should be placed on the prototype obejct
as same as regular attributes.

4.3.12. [OverrideBuiltins]
http://heycam.github.io/webidl/#OverrideBuiltins
"..., properties corresponding to all of the object’s
<supported property names> will appear to be on the object"
where <supported property names> are indexed/named properties in our words.

BUG=43394
Committed: https://crrev.com/2eebf0fc41ac05f4b827d4bdf93a33372221970c
git-svn-id: svn://svn.chromium.org/blink/trunk@199650 bbb929c8-8fbe-4397-9dbb-9b2b20218538

[Yuki, 2015-07-27 12:16:28]

yukishiino@chromium.org changed reviewers:
+ haraken@chromium.org

[Yuki, 2015-07-27 12:16:29]

Could you review this CL?

[haraken, 2015-07-27 12:59:05]

This change looks conformant to the spec. Just to confirm, but does this new
behavior align with Firefox?

[Yuki, 2015-07-28 07:42:07]

On 2015/07/27 12:59:05, haraken wrote:
> This change looks conformant to the spec. Just to confirm, but does this new
> behavior align with Firefox?

Yes, at least for HTMLFormElement.

Currently we have [OverrideBuiltins] on the following interfaces.

- HTMLAppletElement
- HTMLEmbedElement
- HTMLObjectElement
  These interfaces should NOT have [OverrideBuiltins] according to the spec.

- DOMStringMap
  This also doesn't have [OverrideBuiltins].
 
http://www.w3.org/TR/2011/WD-html5-20110525/common-dom-interfaces.html#domstr...

- HTMLFrameSetElement
  This also doesn't have [OverrideBuiltins].
  https://html.spec.whatwg.org/multipage/obsolete.html#frameset

- HTMLFormElement
  https://html.spec.whatwg.org/multipage/forms.html#the-form-element
  YES, THIS MUST HAVE [OverrideBuiltins].

On Firefox,
HTMLFormElement.prototype.acceptCharset => exists, thus TypeError.
form = document.createElement('form')
form.hasOwnProperty('acceptCharset') => false

So, attributes (non named properties) are placed on the prototype object.

[haraken, 2015-07-28 07:55:10]

On 2015/07/28 07:42:07, Yuki wrote:
> On 2015/07/27 12:59:05, haraken wrote:
> > This change looks conformant to the spec. Just to confirm, but does this new
> > behavior align with Firefox?
> 
> Yes, at least for HTMLFormElement.
> 
> Currently we have [OverrideBuiltins] on the following interfaces.
> 
> - HTMLAppletElement
> - HTMLEmbedElement
> - HTMLObjectElement
>   These interfaces should NOT have [OverrideBuiltins] according to the spec.
> 
> - DOMStringMap
>   This also doesn't have [OverrideBuiltins].
>  
>
http://www.w3.org/TR/2011/WD-html5-20110525/common-dom-interfaces.html#domstr...
> 
> - HTMLFrameSetElement
>   This also doesn't have [OverrideBuiltins].
>   https://html.spec.whatwg.org/multipage/obsolete.html#frameset
> 
> - HTMLFormElement
>   https://html.spec.whatwg.org/multipage/forms.html#the-form-element
>   YES, THIS MUST HAVE [OverrideBuiltins].
> 
> On Firefox,
> HTMLFormElement.prototype.acceptCharset => exists, thus TypeError.
> form = document.createElement('form')
> form.hasOwnProperty('acceptCharset') => false
> 
> So, attributes (non named properties) are placed on the prototype object.

Thanks for the clarification :) Given that this CL improves the correctness
(although it's still not correct), LGTM.

[Yuki, 2015-07-29 08:19:56]

The CQ bit was checked by yukishiino@chromium.org

[commit-bot: I haz the power, 2015-07-29 08:20:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1258863003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1258863003/20001

[commit-bot: I haz the power, 2015-07-29 09:41:02]

Committed patchset #2 (id:20001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=199650

[Yuta Kitamura, 2015-07-29 10:47:22]

On 2015/07/29 09:41:02, commit-bot: I haz the power wrote:
> Committed patchset #2 (id:20001) as
> https://src.chromium.org/viewvc/blink?view=rev&revision=199650

This change has caused some layout test (possibly flaky) failures:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=web...

[Yuta Kitamura, 2015-07-29 11:03:51]

On 2015/07/29 10:47:22, Yuta Kitamura wrote:
> On 2015/07/29 09:41:02, commit-bot: I haz the power wrote:
> > Committed patchset #2 (id:20001) as
> > https://src.chromium.org/viewvc/blink?view=rev&revision=199650
> 
> This change has caused some layout test (possibly flaky) failures:
> 
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=web...

I have to leave now without dealing with this issue. The results
from bots are not complete and the best way to handle this issue
is unknown at this moment.

If the issue persists, feel free to take any appropriate action
(rebaseline or edit TestExpectations).

[Yuki, 2015-07-29 12:36:45]

On 2015/07/29 11:03:51, Yuta Kitamura wrote:
> On 2015/07/29 10:47:22, Yuta Kitamura wrote:
> > On 2015/07/29 09:41:02, commit-bot: I haz the power wrote:
> > > Committed patchset #2 (id:20001) as
> > > https://src.chromium.org/viewvc/blink?view=rev&revision=199650
> > 
> > This change has caused some layout test (possibly flaky) failures:
> > 
> >
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=web...
> 
> I have to leave now without dealing with this issue. The results
> from bots are not complete and the best way to handle this issue
> is unknown at this moment.
> 
> If the issue persists, feel free to take any appropriate action
> (rebaseline or edit TestExpectations).

Thanks for your attention.
It looks green now.

[commit-bot: I haz the power, 2015-09-23 11:53:12]

Patchset 2 (id:??) landed as
https://crrev.com/2eebf0fc41ac05f4b827d4bdf93a33372221970c