Add getPropertyNames to v8 Dictionaries and make use of in Keyframes processing.

WebIDL Dictionaries should access prototype chains when searching for properties. This change adds getPropertyNames to the v8 Dictionary class.

Web Animations Keyframes should make use of prototype chains when looking for CSS properties to animate. This change makes use of getPropertyNames to ensure this happens.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=184350

[shans, 2014-10-24 00:39:37]

shans@chromium.org changed reviewers:
+ dstockwell@chromium.org, haraken@chromium.org

[dstockwell, 2014-10-24 02:25:05]

animation changes lgtm

[haraken, 2014-10-24 02:33:45]

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

[haraken, 2014-10-24 02:33:46]

+bashi

It's a bit inconsistent that some Dictionaries use getOwnPropertyNames and
others use getPropertyNames. Can we probably deprecate getOwnPropertyNames?

[bashi, 2014-10-24 03:03:31]

On 2014/10/24 02:33:46, haraken wrote:
> +bashi
> 
> It's a bit inconsistent that some Dictionaries use getOwnPropertyNames and
> others use getPropertyNames. Can we probably deprecate getOwnPropertyNames?

BTW, I'm not sure we can call 'KeyFrame' is an IDL dictionary (in terms of Web
IDL's spec), even though the animation spec says it is a dictionary. It has
special conversion.

http://www.w3.org/TR/web-animations/#processing-a-keyframe-object

It seems that keyframe objects can have arbitrary properties, which means we
can't auto-generate v8 -> impl conversion. Not related to this CL, but I
personally feel this special casing spoils the benefit of IDL dictionary (we can
auto-generate JS <-> C++ conversion if an IDL type is statically defined).

[haraken, 2014-10-24 04:50:05]

This CL LGTM.

Next action items would be:

- Revisit the Keyframe spec. It violates the Web IDL spec about IDL dictionary.
- Consider if we can deprecate getOwnPropertyNames. I guess Dictionary should
always use getPropertyNames.

bashi and I will take the latter part.

[bashi, 2014-10-24 04:52:35]

On 2014/10/24 04:50:05, haraken wrote:
> This CL LGTM.
> 
> Next action items would be:
> 
> - Revisit the Keyframe spec. It violates the Web IDL spec about IDL
dictionary.
> - Consider if we can deprecate getOwnPropertyNames. I guess Dictionary should
> always use getPropertyNames.
> 
> bashi and I will take the latter part.

I'll try if we can remove getOwnPropertyNames later.

[shans, 2014-10-24 05:10:21]

The CQ bit was checked by shans@chromium.org

[commit-bot: I haz the power, 2014-10-24 05:10:57]

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

[shans, 2014-10-24 05:12:23]

On 2014/10/24 04:52:35, bashi1 wrote:
> On 2014/10/24 04:50:05, haraken wrote:
> > This CL LGTM.
> > 
> > Next action items would be:
> > 
> > - Revisit the Keyframe spec. It violates the Web IDL spec about IDL
> dictionary.
> > - Consider if we can deprecate getOwnPropertyNames. I guess Dictionary
should
> > always use getPropertyNames.
> > 
> > bashi and I will take the latter part.
> 
> I'll try if we can remove getOwnPropertyNames later.

Thanks, on the CQ.

With regards to the correctness of the Keyframe spec - we've run this past
public-script-coord@w3c.org and they're happy with it. The alternative is to
specify every single CSS property in a dictionary, which is both expensive and
brittle.

There's even talk about adding a new OpenEndedDictionary type to webIDL to
support this sort of use case (see for example
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26190).

[bashi, 2014-10-24 05:48:46]

On 2014/10/24 05:12:23, shans wrote:
> On 2014/10/24 04:52:35, bashi1 wrote:
> > On 2014/10/24 04:50:05, haraken wrote:
> > > This CL LGTM.
> > > 
> > > Next action items would be:
> > > 
> > > - Revisit the Keyframe spec. It violates the Web IDL spec about IDL
> > dictionary.
> > > - Consider if we can deprecate getOwnPropertyNames. I guess Dictionary
> should
> > > always use getPropertyNames.
> > > 
> > > bashi and I will take the latter part.
> > 
> > I'll try if we can remove getOwnPropertyNames later.
> 
> Thanks, on the CQ.
> 
> With regards to the correctness of the Keyframe spec - we've run this past
> mailto:public-script-coord@w3c.org and they're happy with it. The alternative
is to
> specify every single CSS property in a dictionary, which is both expensive and
> brittle.

I understand you need something like that, but my point was that if we need
special-conversion, why don't we call it any or object? What's the benefit of
saying 'this is a dictionary, but we need a special conversion'? Maybe I can
find the reason in the mailing list. Is there any archive online?

> 
> There's even talk about adding a new OpenEndedDictionary type to webIDL to
> support this sort of use case (see for example
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26190).

[commit-bot: I haz the power, 2014-10-24 07:29:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-24 07:29:24]

Try jobs failed on following builders:
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/33420)

[shans, 2014-10-24 11:20:43]

On 2014/10/24 05:48:46, bashi1 wrote:
> On 2014/10/24 05:12:23, shans wrote:
> > On 2014/10/24 04:52:35, bashi1 wrote:
> > > On 2014/10/24 04:50:05, haraken wrote:
> > > > This CL LGTM.
> > > > 
> > > > Next action items would be:
> > > > 
> > > > - Revisit the Keyframe spec. It violates the Web IDL spec about IDL
> > > dictionary.
> > > > - Consider if we can deprecate getOwnPropertyNames. I guess Dictionary
> > should
> > > > always use getPropertyNames.
> > > > 
> > > > bashi and I will take the latter part.
> > > 
> > > I'll try if we can remove getOwnPropertyNames later.
> > 
> > Thanks, on the CQ.
> > 
> > With regards to the correctness of the Keyframe spec - we've run this past
> > mailto:public-script-coord@w3c.org and they're happy with it. The
alternative
> is to
> > specify every single CSS property in a dictionary, which is both expensive
and
> > brittle.
> 
> I understand you need something like that, but my point was that if we need
> special-conversion, why don't we call it any or object? What's the benefit of
> saying 'this is a dictionary, but we need a special conversion'? Maybe I can
> find the reason in the mailing list. Is there any archive online?

Keyframes act exactly like a dictionary for 3 properties (easing, composite,
offset), and a lot like a dictionary for the rest of the CSS Property names.

Having said that, I'd be happy enough to convert to an any or object in code -
but I recall we made the opposite decision with Kenji and Haraken when first
implementing this class.

> 
> > 
> > There's even talk about adding a new OpenEndedDictionary type to webIDL to
> > support this sort of use case (see for example
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=26190).

[shans, 2014-10-24 11:21:06]

The CQ bit was checked by shans@chromium.org

[commit-bot: I haz the power, 2014-10-24 11:21:22]

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

[commit-bot: I haz the power, 2014-10-24 12:03:00]

Committed patchset #2 (id:20001) as 184350