tor-browser

The Tor Browser
git clone https://git.dasho.dev/tor-browser.git
Log | Files | Refs | README | LICENSE

class-string-named-properties-object.window.js (1137B)


      1 "use strict";
      2 
      3 const namedPropertiesObject = Object.getPrototypeOf(Window.prototype);
      4 
      5 test(() => {
      6  assert_own_property(namedPropertiesObject, Symbol.toStringTag);
      7 
      8  const propDesc = Object.getOwnPropertyDescriptor(namedPropertiesObject, Symbol.toStringTag);
      9  assert_equals(propDesc.value, "WindowProperties", "value");
     10  assert_equals(propDesc.configurable, true, "configurable");
     11  assert_equals(propDesc.enumerable, false, "enumerable");
     12  assert_equals(propDesc.writable, false, "writable");
     13 }, "@@toStringTag exists with the appropriate descriptor");
     14 
     15 test(() => {
     16  assert_equals(Object.prototype.toString.call(namedPropertiesObject), "[object WindowProperties]");
     17 }, "Object.prototype.toString");
     18 
     19 // Chrome had a bug (https://bugs.chromium.org/p/chromium/issues/detail?id=793406) where if there
     20 // was no @@toStringTag, it would fall back to a magic class string. Tests for this are present in
     21 // the sibling class-string*.any.js tests. However, the named properties object always fails calls
     22 // to [[DefineOwnProperty]] or [[SetPrototypeOf]] per the Web IDL spec, so there is no way to
     23 // trigger the buggy behavior for it.