From 36d22d82aa202bb199967e9512281e9a53db42c9 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 21:33:14 +0200 Subject: Adding upstream version 115.7.0esr. Signed-off-by: Daniel Baumann --- .../class-string-named-properties-object.window.js | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 testing/web-platform/tests/webidl/ecmascript-binding/class-string-named-properties-object.window.js (limited to 'testing/web-platform/tests/webidl/ecmascript-binding/class-string-named-properties-object.window.js') diff --git a/testing/web-platform/tests/webidl/ecmascript-binding/class-string-named-properties-object.window.js b/testing/web-platform/tests/webidl/ecmascript-binding/class-string-named-properties-object.window.js new file mode 100644 index 0000000000..a427a2f814 --- /dev/null +++ b/testing/web-platform/tests/webidl/ecmascript-binding/class-string-named-properties-object.window.js @@ -0,0 +1,23 @@ +"use strict"; + +const namedPropertiesObject = Object.getPrototypeOf(Window.prototype); + +test(() => { + assert_own_property(namedPropertiesObject, Symbol.toStringTag); + + const propDesc = Object.getOwnPropertyDescriptor(namedPropertiesObject, Symbol.toStringTag); + assert_equals(propDesc.value, "WindowProperties", "value"); + assert_equals(propDesc.configurable, true, "configurable"); + assert_equals(propDesc.enumerable, false, "enumerable"); + assert_equals(propDesc.writable, false, "writable"); +}, "@@toStringTag exists with the appropriate descriptor"); + +test(() => { + assert_equals(Object.prototype.toString.call(namedPropertiesObject), "[object WindowProperties]"); +}, "Object.prototype.toString"); + +// Chrome had a bug (https://bugs.chromium.org/p/chromium/issues/detail?id=793406) where if there +// was no @@toStringTag, it would fall back to a magic class string. Tests for this are present in +// the sibling class-string*.any.js tests. However, the named properties object always fails calls +// to [[DefineOwnProperty]] or [[SetPrototypeOf]] per the Web IDL spec, so there is no way to +// trigger the buggy behavior for it. -- cgit v1.2.3