domenic at domenicdenicola.com (2014-03-30T16:16:00.887Z)
supposedly https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript and http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl document the emerging de facto std for providing this name to the existing API. However, I have not seen it work on any browser. See point #5 at https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html. Am I doing something wrong here that account for my not seeing this, or does it in fact not work anywhere?
Hi John, supposedly < https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#breakpoints-dynamic-javascript> and < http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/#toc-sourceurl> document the emerging de facto std for providing this name to the existing API. However, I have not seen it work on any browser. See point #5 at < https://mail.mozilla.org/pipermail/es-discuss/2014-March/036642.html>. Am I doing something wrong here that account for my not seeing this, or does it in fact not work anywhere? On Fri, Mar 28, 2014 at 9:41 AM, John Barton <johnjbarton at google.com> wrote: > Notice that the eval stack trace is not very useful in the common case > that the buffer is more complex than a single line and the eval is called > more than once. For eval, new Function(), document.write(<script>), > document.appendChild(<script>), and System.module() successful debugging -- > and thus stack traces -- require unique, stable names for the buffers. > With these names, debugging with these features is no different than > normal source; without names, stack traces have limited value. > > Stable automatic naming is difficult, since the code that uses these > features often does so inside of asynchronous loops (for loading). Making > it easy for developers to provide names is the simplest improvement for > these dynamic features. We could have names provided to eval() and new > Function(); we should ensure that new API has names, like System.module(). > That would make a standard stack trace more useful. > > jjb > > > > On Thu, Mar 27, 2014 at 11:59 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > >> On 3/27/14 12:31 PM, Mark Miller wrote: >> >>> Mozillians, why did you add this extra information? >>> >> >> Looks like it was added in https://bugzilla.mozilla.org/ >> show_bug.cgi?id=332176 >> >> Before that, the stack claimed the url of the caller of eval() but a line >> number which was the sum of the line number of the eval() call itself and >> the line number of the code throwing the exception inside the eval string, >> I believe, or some such insanity. >> >> There's a lot of noise there in the discussion, but I think the key >> recent part is https://bugzilla.mozilla.org/show_bug.cgi?id=332176#c40which summarizes what I think we implemented. Note that per >> https://bugzilla.mozilla.org/show_bug.cgi?id=332176#c42 we do something >> similar for new Function() as well, so you can get a stack trace like so: >> >> anonymous at http://example.com line 3 > Function:1:1 >> @http://example.com:3:5 >> >> >> for a testcase like this: >> >> <script> >> >> try { >> new Function("throw new Error()")(); >> } catch (e) { >> document.write(e.stack); >> } >> </script> >> >> -Boris >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140328/6919846e/attachment.html>