Maximally minimal stack trace standardization

John Lenz concavelenz at gmail.com
Tue Sep 30 09:28:17 PDT 2014


I don't believe we want source map involved as, as you say, that
information needs to be retrieved separately.
On Sep 30, 2014 5:17 AM, "Fitzgerald, Nick" <nfitzgerald at mozilla.com> wrote:

>  On 9/30/14, 3:44 AM, John Lenz wrote:
>
> It is a defacto standard.
> On Sep 29, 2014 6:36 PM, "Brendan Eich" <brendan at mozilla.org> wrote:
>
>> Carl Smith wrote:
>>
>>> If the source URL hack, or some cleaner wrapper for it, was
>>> standardised, it'd make all the difference.
>>>
>>
>> Why don't we just make the source URL hack a de-facto standard? That's
>> how evolution happens, in the best case. Cc'ing @fitzgen.
>>
>> /be
>>
>
> I remember web compat concerns, but if Chrome is exposing the `//#
> sourceURL` to the web in error stacks, maybe we can get away with it as
> well. I'd defer to jorendorff's opinion on this.
>
> We've also discussed exposing the source mapped location of stack frames
> to JS, but that's even trickier:
>
> * We don't do any source mapping unless devtools are open, so exposing
> this would leak whether the user is using devtools or not. Not sure how
> serious that is, but it makes me hesitant. On the other hand, always source
> mapping seems impractical, but maybe that's a false assumption.
>
> * It is a nonstarter to block JS on fetching a source map, so early stack
> traces would not be source mapped, while later ones would be. This sort of
> non-determinism makes me feel :( We could introduce a new async method for
> getting stacks and only source map for these async stacks (or make the new
> method that other branches of this thread are discussing async).
>
> Interested in hearing everyone's thoughts on this.
>
> Cheers,
>
> Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140930/82eaa111/attachment.html>


More information about the es-discuss mailing list