-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Named properties object: allow symbols in [[DefineOwnProperty]] and [[Delete]] #963
Named properties object: allow symbols in [[DefineOwnProperty]] and [[Delete]] #963
Conversation
|
||
1. Return <emu-val>false</emu-val>. | ||
1. If [$Type$](|P|) is String, then return <emu-val>false</emu-val>. | ||
1. Otherwise, return [=?=] [$OrdinaryDelete$](|O|, |P|). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unlike in legacy platform objects, we can call OrdinaryDelete
instead of reimplementing it, as it's reachable only for own symbol properties. I mildly prefer calling ordinary methods so the implementations can match the spec more closely.
@annevk do we want this in Firefox? I think this would mean creating an expando object for WindowNamedProperties, which we currently don't have. |
I would be fine keeping this as-is personally. Roughly what I care about for these legacy objects is:
And although this is a bit of 2, that could also be achieved by Chromium changing. @yuki3 was this intentional on the side of Chromium? |
Creating an expando object for
It feels a bit of 3 to me. |
About named properties and indexed properties, we're struggling to implement them correctly due to unique characteristics of V8 APIs (which sometimes do not have a clear mapping to ECMAScript spec). Clearly not all behaviors are implemented on purpose. I don't fully understand the issue and cannot say what's the best. If necessary, I'm happy to change the Chromium's behaviors. |
@shvaikalesh could you elaborate on why the specified semantics are weird with respect to the invariants? |
I like the idea of making |
Given the following example: <!DOCTYPE html>
<form name=foo></form>
<script>
const wp = Object.getPrototypeOf(Window.prototype);
wp.foo = 1;
</script> @yuki3 Is it possible to make the @annevk current spec does comply to invariants, but makes In perfect world, it would be nice to do the same for On implementation side, WebCore uses JavaScriptCore classes directly, without the API, so it's possible to implement anything that can be spec-ed. |
To my best understanding, this is simply a bug. We're forbidding IIUC, |
V8 interceptor's setter doesn't fallback to definer automatically, so we have to define both of setter and definer interceptors if we'd like to forbid properties to be set/defined on a named properties object. whatwg/webidl#963 Change-Id: I5386ffaac06c2275fd847c7d47cec87054a138d6
V8 interceptor's setter doesn't fallback to definer automatically, so we have to define both of setter and definer interceptors if we'd like to forbid properties to be set/defined on a named properties object. whatwg/webidl#963 Change-Id: I5386ffaac06c2275fd847c7d47cec87054a138d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2759574 Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#862830}
V8 interceptor's setter doesn't fallback to definer automatically, so we have to define both of setter and definer interceptors if we'd like to forbid properties to be set/defined on a named properties object. whatwg/webidl#963 Change-Id: I5386ffaac06c2275fd847c7d47cec87054a138d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2759574 Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#862830}
The throwing without
I don't feel great about fiddling with some of these legacy objects, but it doesn't seem too complicated for us to change this in Gecko I think (limited to symbols). Making @@toStringTag non-configurable is fine by me too. |
V8 interceptor's setter doesn't fallback to definer automatically, so we have to define both of setter and definer interceptors if we'd like to forbid properties to be set/defined on a named properties object. whatwg/webidl#963 Change-Id: I5386ffaac06c2275fd847c7d47cec87054a138d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2759574 Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#862830}
I've landed a fix. Chromium (tip of tree) is fixed. Canary (nightly) version containing the fix will be shipped in a day or two. |
…ed properties object, a=testonly Automatic update from web-platform-tests v8bindings: Fix indexed/named set on named properties object V8 interceptor's setter doesn't fallback to definer automatically, so we have to define both of setter and definer interceptors if we'd like to forbid properties to be set/defined on a named properties object. whatwg/webidl#963 Change-Id: I5386ffaac06c2275fd847c7d47cec87054a138d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2759574 Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#862830} -- wpt-commits: 398cdd520373bd27384419b6926be816637994e8 wpt-pr: 28078
Thank you @yuki3, it's a great fix that covers all
That's right, per step 3 of I've decided not to pursue this change: if we make
And even if we fix symbols, Instead, let's reach interop with the current spec. I've updated the tests and reported bugs regarding remaining minor issues: |
V8 interceptor's setter doesn't fallback to definer automatically, so we have to define both of setter and definer interceptors if we'd like to forbid properties to be set/defined on a named properties object. whatwg/webidl#963 Change-Id: I5386ffaac06c2275fd847c7d47cec87054a138d6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2759574 Reviewed-by: Kentaro Hara <haraken@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#862830} GitOrigin-RevId: f9ea840de1d561c3c95541c183a4f8affcf9b74e
Given that
X
is named properties object forWindow
, the following code:should throw
TypeError
per current spec. While being compliant with invariants of EIM, this behavior is very weird.The same snippet for
X
that is module namespace object doesn't throw, even though the namespace is non-extensible and itsSymbol.toStringTag
is non-configurable.While we could just special-case
Symbol.toStringTag
or own properties that are symbols, I suggest we treat symbols in[[DefineOwnProperty]]
and[[Delete]]
the same way as ordinary methods do. To prevent clashes with supported property names, it's critical forWindowProperties
to prohibit expando properties that are strings, but not symbols.Proposed change feels like an expected behavior, reducing divergence with ordinary methods, and aligns named properties object with legacy platforms objects & module namespace object. It is already implemented in Blink and also, with bug #222918, in WebKit.
Currently, no browser features spec-perfect
WindowProperties
object, so this change can be implemented along with fixing current spec incompatibilities.Tests: web-platform-tests/wpt#27970.
cc @domenic @evilpie