I should note, with some guidance I'd like to help contribute some fixes for this stuff!!

P.S. The tests have been updated to

  1. Be more inclusive to all console methods using format specifiers
  2. To ensure we're not testing console.dir, since console.dir is not spec'd to take in format specifiers. This was a mistake in the original tests. I'm noting this here since there has been some confusion on this.

Thanks for filing the issue!

We tried checking the issue by navigating to https://github.com/w3c/web-platform-tests/pull/9008 on reported chrome version 63.0.3239.108 and on the latest canary 65.0.3323.0 Using Mac 10.13.1 with the below mentioned steps.
1. Downloaded the code/file and unzipped it.
2. We did not find any javascript appearing in the <script> tag to test

@Reporter: Could you please share a sample test file which helps us to triage the issue in a better way.

Hmm, I'm not entirely sure what the problem with the PR is...the PR adds two files to the repository; one is a manual test that can be seen from this jsbin: https://jsbin.com/tisorisopa/edit?html,console,output and the other which basically says:

console.METHOD(FORMAT, Symbol.for("description")) should throw for all possible combinations of the following:

METHOD = {log, dirxml, trace, group, groupCollapsed}
FORMAT = {"%i", "%d", "%f"}

Hopefully this makes sense, but let me know if I can help clarify further. Also, by running a local copy of the WPT repository checked out to my fork's PR branch, running `./wpt run chrome console` should give a pretty good idea of the failures.

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Adding some more info and bumping this thread. The test PR not only enforces error-throwing behavior for the aforementioned specifiers and their application on Symbols, but also accompanies the Console spec change (https://github.com/whatwg/console/pull/123) that specifies a Symbol's descriptor should be used when applying the %s% format specifier.

Erik, mind taking a look?

Thanks for the report.  After reading the discussions on Github/WebKit tracker, I'd like to clarify what needs to be done.  Based on the last comment in this thread [1],
"it seems we've decided not to throw when the %s specifier is applied to Symbols"

So it sounds like "%s" string formatter has been decided, but numeric formatters (%i/d/f) have not.  The spec thread includes 2 proposed paths forward for Symbols: they should either
- always throw error whether DevTools are open/closed (revise this crbug or file a V8 bug)
OR
- print 'NaN' (what Chrome does today, we could close this crbug)

Since it hasn't settled yet, it looks like we need to wait.  dom@, please let me know if I'm wrong here, or if I'm not be up to date.


[1] https://github.com/whatwg/console/issues/113

You're up to date as far as I can tell! I've posted another comment in that thread to see if we can get some more info from Gecko and Edge, but it looks like we'll probably move down the path of showing `NaN` for the %d/f/i format specifiers, so likely nothing will change here.

Gotcha, I'll close this crbug for now then.  If things change and we know what to change, let us know and we can reopen or file a new one!