In the future, make assert_class_string and idlharness class string tests stricter

[domenic]

For a long time, Web IDL "class string" behavior was non-interoperable. As such, currently assert_class_string only tests the interoperable subset: basically, does Object.prototype.toString() produce the right result on instances. This is good, because if it tested the full spec semantics, then every idlharness-based test would get a bunch of noisy failures for areas outside the interoperable subset. Instead, we tested the full spec semantics for one or two interfaces in the WebIDL/ directory.

However, we seem to be converging on interoperability. In particular, whatwg/webidl#357 has been merged, with implementer support. Once implementers implement it, we should consider expanding test coverage for class strings to test the full spec semantics.

We should not do this right away, to avoid the thousands-of-noisy-failures issue. But once implemented, we can do so, for the following benefits:

• Gives full coverage of all classes, not just a few. In particular this is important for classes like WebAssembly or Streams, which might be implemented using different technology. For example, we could revert WASM JS API: Test new Web IDL class string behavior #23205 and let idlharness take care of it.

• Lets us remove most of the class string tests in the WebIDL/ folder.

Note that this work was started in #23108, but I asked that it be put on hold. So this issue is basically to track reopening and merging that PR in a future time.

/cc @annevk @shvaikalesh @evilpie @TimothyGu

[TimothyGu]

Looks like all three browsers have implemented this change!

a = new URL('http://a/');
assert_equals(Object.prototype.toString.call(a), "[object URL]");
delete URL.prototype[Symbol.toStringTag];
assert_equals(Object.prototype.toString.call(a), "[object Object]");

[ExE-Boss]

See also: #27239