New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 764633 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
OoO until Feb 4th
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Task

Blocked on:
issue v8:7612

Blocking:
issue 645542
issue 618305


Show other hotlists

Hotlists containing this issue:
Hotlist-Bindings-IDLCompiler


Sign in to add a comment

bindings: Instantiate named properties and indexed properties with the same prototype

Project Member Reported by raphael....@intel.com, Sep 13 2017

Issue description

In V8, NamedPropertyHandlerConfiguration and IndexedPropertyHandlerConfiguration both have two different constructors each. One of them takes getter, setter, query, deleter and enumerator callbacks, while the other takes getter/setter/descriptor/deleter/enumerator and definer callbacks instead.

A query callback is used to determine if a given property is present and, if it is, return an integer corresponding to v8::PropertyAttribute. Descriptor and definer callbacks were added later; the former returns a v8::Value created out of a v8::PropertyDescriptor object and is used in calls to e.g. Object.getOwnPropertyDescriptor(), and the latter is used to intercept calls when a new property is defined in an object.

In the bindings layer, we add both indexed and named property handlers depending on what a given IDL interface supports. We used to use the same constructor prototype for both NamedPropertyHandlerConfiguration and IndexedPropertyHandlerConfiguration, but with https://codereview.chromium.org/2832923003 (and  bug 695385 ), IndexedPropertyHandlerConfiguration started being instantiated with the descriptor+definer prototype instead.

We should probably do the same to NamedPropertyHandlerConfiguration. Doing things symmetrically is helpful for a handful of reasons:
- The code is easier to understand.
- The definer/descriptor signature matches the slots for legacy platform objects in WebIDL spec more closely (https://heycam.github.io/webidl/#es-legacy-platform-objects).
- Even if an interface only supports named properties, we still install a handler for indexed properties due to the way V8 works: a property like 0 or "0" will always go to an indexed property handler. When an interface only supports named properties, we make the indexed property callbacks just fall back gracefully to the named property ones, and doing so is more difficult when each HandlerConfiguration sets different callback types (with different signatures). See https://chromium-review.googlesource.com/c/chromium/src/+/660497, for example.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Sep 13 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf8a4164dc2d7dc306b094fadf84052d482d44b7

commit cf8a4164dc2d7dc306b094fadf84052d482d44b7
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Wed Sep 13 10:48:39 2017

bindings: Expose an indexed property descriptor handler for named properties.

Follow-up to https://chromium-review.googlesource.com/576183 ("bindings:
Return the right property descriptors for legacy platform objects"), which
introduced the indexed descriptor callbacks for bindings.

Even if a given IDL (such as Storage.idl) only supports named properties,
our bindings layer installs a handler for indexed properties that, in this
case, mostly just ends up falling back to the named property handlers.

However, we were not defining a descriptor callback for indexed properties
when the IDL only supports named properties. Consequently, we were not
setting the right property descriptor values for a given numeric property,
leading to bizarre cases where, e.g. if Storage only had numeric keys,
Object.values() and Object.keys() would return arrays of diffferent
lengths (the latter would be an empty one, actually).

This change is a bit complicated because we install our indexed and named
property handlers differently: the former is created with descriptor and
definer callbacks, whereas the latter uses the query callback signature
instead. This means the indexed property descriptor callback for named
properties needs to call the query callback and translate its return value
into a format suitable for descriptor callbacks, which is not very
efficient. Ideally, both named and indexed properties should converge in
terms of how their handlers are declared.

Despite the fact that this is a follow-up commit, the original CL did not
introduce a regression; interfaces that only support named properties were
just behaving like they did in the past, with an indexed descriptor callback
not being set.

Bug:  719703 , 764633
Change-Id: I1ebaabe61f5f8b6cadb0cfa8b41664a64e49e51b
Reviewed-on: https://chromium-review.googlesource.com/660497
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Hitoshi Yoshida <peria@chromium.org>
Reviewed-by: Kenichi Ishibashi <bashi@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#501591}
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/LayoutTests/external/wpt/webstorage/storage_enumerate.html
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/templates/interface.cpp.tmpl
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/templates/interface.h.tmpl
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/templates/interface_base.cpp.tmpl
[add] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/tests/idls/modules/TestNotEnumerableNamedGetter.idl
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/tests/results/core/V8TestSpecialOperations.cpp
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/tests/results/core/V8TestSpecialOperations.h
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInheritedLegacyUnenumerableNamedProperties.cpp
[modify] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/tests/results/modules/V8TestInheritedLegacyUnenumerableNamedProperties.h
[add] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/tests/results/modules/V8TestNotEnumerableNamedGetter.cpp
[add] https://crrev.com/cf8a4164dc2d7dc306b094fadf84052d482d44b7/third_party/WebKit/Source/bindings/tests/results/modules/V8TestNotEnumerableNamedGetter.h

Blockedon: v8:7612
Blocking: 618305
I'm marking this is as blocking  bug 618305  because we need descriptor callbacks to properly implement all the intricacies of Window/WindowProxy/Location property handling.

Namely, https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-) shows that some properties need to be access property descriptor rather than data ones. That is not possible with query callbacks, which only allow one to return an int manipulating v8::PropertyAttribute (and it's actually the reason why descriptor callbacks were added to V8 in the first place).

(Location/Window will likely need a custom property descriptor but that's orthogonal to the issue at hand)
Project Member

Comment 5 by bugdroid1@chromium.org, Apr 3 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5b84e88a070e40a1a74576a6cf41109d29a8035a

commit 5b84e88a070e40a1a74576a6cf41109d29a8035a
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Tue Apr 03 13:14:36 2018

Remove custom bindings for CSSStyleDeclaration.

Attempt to remove these custom bindings again after 2015's
https://codereview.chromium.org/1119653002 and others.

At the time the CLs were reverted because of performance regressions; I seem
to be unable to trigger the perf trybots myself, so we will need to see if
there is anything to fix after landing.

There was nothing in the custom bindings that really required custom code,
so the existing implementations of the named setter/getter/enumerator/query
were moved almost as-is to CSSStyleDeclaration.cpp.

The local supporting functions were almost untouched as well, except for the
fact that they were moved into an anonymous namespace instead of being made
static, and they all take AtomicString's in their arguments rather than
String's.

Removing these custom bindings helps get rid of named property queries (this
was the only custom named query implementation in the tree), which we need
to do in order to be able to instantiate indexed and named property handlers
the same way and simplify our bindings code.

Bug: 345519, 764633

Change-Id: I76171bb4c2ae23fc672748dc11b26094f16e573e
Reviewed-on: https://chromium-review.googlesource.com/984232
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#547683}
[modify] https://crrev.com/5b84e88a070e40a1a74576a6cf41109d29a8035a/third_party/WebKit/Source/bindings/bindings.gni
[modify] https://crrev.com/5b84e88a070e40a1a74576a6cf41109d29a8035a/third_party/WebKit/Source/core/css/BUILD.gn
[rename] https://crrev.com/5b84e88a070e40a1a74576a6cf41109d29a8035a/third_party/WebKit/Source/core/css/CSSStyleDeclaration.cpp
[modify] https://crrev.com/5b84e88a070e40a1a74576a6cf41109d29a8035a/third_party/WebKit/Source/core/css/CSSStyleDeclaration.h
[modify] https://crrev.com/5b84e88a070e40a1a74576a6cf41109d29a8035a/third_party/WebKit/Source/core/css/CSSStyleDeclaration.idl

Project Member

Comment 6 by bugdroid1@chromium.org, Apr 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a21878dbbdb4f3ebe979d63b690f5a499bbd02fd

commit a21878dbbdb4f3ebe979d63b690f5a499bbd02fd
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Wed Apr 11 22:34:10 2018

CSSStyleDeclaration: Remove [RaisesException] from setter

Previously, the custom bindings code for CSSStyleDeclaration only
create an ExceptionState locally to pass to SetPropertyInternal().

Go back to this behavior and drop [RaisesException] from the setter due
to performance issues: [RaisesException] causes an ExceptionState to be
generated automatically in namedPropertySetter(), and an expensive
CString needs to be created to set the ExceptionState's |property_name|
argument.

By creating an ExceptionState ourselves in AnonymousNamedSetter(), we
can avoid creating a CString altogether and use a custom value for
|property_name|. This brings some performance tests back to the values
they used to report when we had custom bindings for CSSStyleDeclaration,
namely:
- blink_perf.css' CSSPropertySetterGetter and CSSPropertyUpdateValue
- blink_perf.layout's SimpleTextPathLineLayout

Bug: 764633,  829408 
Change-Id: I99db6021d4483c5743daa452f9cb532eacda79a7
Reviewed-on: https://chromium-review.googlesource.com/1002881
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549955}
[modify] https://crrev.com/a21878dbbdb4f3ebe979d63b690f5a499bbd02fd/third_party/blink/renderer/core/css/css_style_declaration.cc
[modify] https://crrev.com/a21878dbbdb4f3ebe979d63b690f5a499bbd02fd/third_party/blink/renderer/core/css/css_style_declaration.h
[modify] https://crrev.com/a21878dbbdb4f3ebe979d63b690f5a499bbd02fd/third_party/blink/renderer/core/css/css_style_declaration.idl

Project Member

Comment 7 by bugdroid1@chromium.org, Apr 12 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc2b8eaf154bbb50ae28adf35b456f763d65b91c

commit fc2b8eaf154bbb50ae28adf35b456f763d65b91c
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Thu Apr 12 07:54:29 2018

CSSStyleDeclaration: Add [TreatNullAs=NullString] to the setter

Follow-up to 5b84e88a0 ("Remove custom bindings for CSSStyleDeclaration").
The custom bindings code used to convert the property value to a string via

    V8StringResource<kTreatNullAsNullString>

even though that does not match the setter's signature in the IDL file.

Now that the bindings are being generated automatically, the IDL's signature
was being respected and causing property values to be converted via

    V8StringResource<kTreatNullAndUndefinedAsNullString>

Update the signature in the IDL so that we maintain compatibility with the
older code.

Bug: 764633
Change-Id: Ief868d4d3a0655f56e844d3b05cfbd771b2cf8da
Reviewed-on: https://chromium-review.googlesource.com/1002878
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550088}
[modify] https://crrev.com/fc2b8eaf154bbb50ae28adf35b456f763d65b91c/third_party/blink/renderer/core/css/css_style_declaration.idl

Blocking: 645542
Labels: Hotlist-Bindings-IDLCompiler

Sign in to add a comment