Created attachment 331163 [details] Expected output of the pending web-platform-test found in the link in this bug description Run the JavaScript appearing in the <script> tag in the test in https://github.com/w3c/web-platform-tests/pull/9008 Note that the behavior of Console format specifiers on Symbol objects is not spec-compliant.
Created attachment 331164 [details] Safari's "actual" output for the pending WPT
I'm not sure how much of this we intend to do. 1. I don't want to change `console.dir` to take a format string. 2. I think ultimately we should drop `console.dirxml` unless someone can actually define its primary use case. I'd guess that developers don't use it, or that its now irrelevant in tools (in which case, lets just map it to `console.dir`. 3. WebKit has always never performed the format string operations in the page's context. It serializes all the arguments, sends them to the developer tools, and the tools then apply the format string. We do this for one obvious reason: this allows the performance of console operations to be very fast if Web Inspector is not open. Likewise, changing this behavior to suddenly throw a type error could be a backwards incompatible change. It sounds like existing code in pages that currently never throws an exception could suddenly throw an exception even if the tools are not open. That doesn't sound like something we'd want to do.
> 1. ... I don't want to change `console.dir` either, that was a mistake in the tests (thanks for catching). > 2. ... Yeah I've never even heard of dirxml before working on the spec, maybe we could open an issue on the spec and try to get an idea of how widely used it is? I know Paul Irish had mentioned dirxml a bit so not sure if he'd have any input. Hmm I understand, and that's a good point. The spec currently calls %parseInt/Float% when the %i/%d/%f format specifiers are used so, and those operations can throw when invoked...but maybe we can consider changing the spec, but I'm not really sure...?