[Webkit-unassigned] [Bug 137297] New: Allowing eval'ed code to be named in stack traces

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137297

           Summary: Allowing eval'ed code to be named in stack traces
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore JavaScript
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: carl.input at gmail.com
                CC: fpizlo at apple.com


Following a discussion on es-discuss [http://esdiscuss.org/topic/maximally-minimal-stack-trace-standardization], Filip Pizlo asked me to bring this here. That discussion is about improving stack traces generally long term, but this ticket is to do with some specifics that can be dealt with sooner.

In applications that allow the user to enter and execute code ~ shells, interactive educational environments, scriptable applications ~ the app needs certain information on errors to provide tracebacks to the user, basically where the error occurred, which amounts to the filename, the line number and the column number for each call on the stack.

Because these applications use `eval` to execute the users' inputs, often repeatedly, there needs to be a way to name the eval'ed code strings, else they are not distinct in the traceback, and any line and column numbers are then useless.

V8 now allows applications to use the source URL directive `// #sourceURL=<filename>` in eval'ed code strings, and will use the given name in tracebacks [instead of eval, eval, eval...].

For an example of how this is useful, in a shell I work on, each user input gets internally given an incremented name like input1.js, and the input string and any meta is stashed for later. If any of the user's inputs end up in a stack trace [not uncommon] the app can grab the information about the original input from the stash using the 'filename'. This allows for source maps too, so you can have languages like CoffeeScript mixed into the stack trace and still produce a consistent traceback, with the original source code, and line and column numbers mapped correctly. It works really nicely, but only in Chrome/Opera.

Different engines currently vary in what they do regarding line and column numbers too. V8 does line and column numbers on runtime errors, but not syntax/compilation errors, though I'm told that's now fixed, but not stable yet. Gecko does line and column numbers for both kinds of error, but doesn't expose the source URL in tracebacks provided to apps. A couple of Moz guys seem at least open to following Chrome on that now, and making it a de-facto standard.

TL;DR: All errors should pass `window.onerror` an `error` object with a `stack` that includes a filename ~ either the actual filename or a given filename if it's provided as a source URL and the item is eval'ed code ~ and the line and column numbers, for each item in the stack.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.