Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome latest stable M55-55.0.2883.95 by following steps mentioned in the original comment. 

This is a non-regression issue seen from past M35-35.0.1849.0, Hence marking it as untriaged.

Thanks! 

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

Thanks for reporting, updated the wiki.

I'd say this is rather an error in the API than in the documentation, since it would be more useful to have the CallSite in a structured form than a string that has to be parsed. It also would allow for to be called recursively in the case of nested eval's

I'm not sure I understand what you want to achieve, do you have an extended code example?


With nested evals, information about the caller is in the next CallSite object. For example:

d8> eval("eval(\"throw new Error();\");")
Error
    at eval (eval at <anonymous> (eval at <anonymous> ((d8):1:1)), <anonymous>:1:7)
    at eval (eval at <anonymous> ((d8):1:1), <anonymous>:1:1)
    at (d8):1:1

structuredStackTrace[0] shows the top frame, structuredStackTrace[1] its caller.


But the eval origin doesn't necessarily have to be on the call stack:

d8> eval("g = function() { throw new Error(); }");
d8> g()
Error
    at g (eval at <anonymous> ((d8):1:1), <anonymous>:1:24)
    at (d8):1:1


CallSite objects are intended to give information about a function on the call stack.
Returning a String for the eval origin seems reasonable to me since the eval origin
may not be on the call stack.

No, that makes sense