As John alluded to, the original idea (way back in the old days of V1) was
to do the more-detailed mapping out of band, given the variety and
complexity of the possible translations. For example, having either a
server API that understood how to do additional mapping of error messages
after the fact or having the running debugger provide real-time mapping via
its own API.
I'm new to the recent discussion (so I apologize if this has been suggested
before), but perhaps a solution is to allow the source map to call a
predefined external API that can perform these additional calculations;
that way, there isn't any untrusted code running on the user's machine,
there is no need to ship the full AST/compiler information and it allows
for flexible mappings. If the API were to run on top of a websocket, it
could even be done in real-time. Local debuggers could then translate
locally, while production code (that's being debugged) could provide their
own pre-loaded state via extra endpoint(s).
On Fri, Mar 14, 2014 at 12:49 AM, John Lenz wrote:
> Two things:
> I'm very interested in prior art in this area. This isn't a new problem we
> are trying to solve.
> The original source map deliberately ignore these features to all multiple
> levels of translation and at a mid level there might not be a JS AST
> representation to hook on to.
> On Mar 12, 2014 5:31 PM, "Brian Slesinsky" wrote:
> > On Wed, Mar 12, 2014 at 5:04 PM, Fitzgerald, Nick
> > wrote:
> > > On 3/12/14 2:40 PM, Brian Slesinsky wrote:
> > > > Interesting. I think the sticky part will be providing the
> > > > getLocals(), getDisplayValue(), and eval() functions. I think it's
> > > > by the compiler, since this allows a lot of flexibility. But which
> > > > to? I think it would have to be a sandbox of some sort and there may
> > > > be security implications for curious developers who run untrusted
> > > > with the debugger window open.
> > >
> > > I was imagining it would run in the frame the debugger was paused in.
> > >
> > However that means the debugger's view of things could possibly be broken
> > by someone monkey-patching a prototype in the web page itself (or
> > by an extension changing something). A debugger or a debugger plugin
> > work even when things have gone very wrong in the program being debugged.
> > But it's hard to write code sufficiently paranoid to work in any
> > environment.
> > > Perhaps I am missing something, but if you are already running a site's
> > > code, why would they need to send the bad stuff via the debugging
> > > information?
> > >
> > developers wouldn't suspect it, which sounds like an interesting target
> > a hacker.
> > It would be a problem if it somehow ran with higher privileges than the
> > code being debugged. For example, suppose the debugger called the plugin
> > code when it's looking at the local variables of a function that's
> > in an iframe that came from a different origin? Now we have an
> > way to get around same-origin restrictions.
> > So I think running each compiler's custom code as a separate
> > extension makes the most sense, both to protect it from outside
> > interference and to make sure it can't do anything malicious.
> > - Brian
> > _______________________________________________
> > dev-js-sourcemap mailing list
> > firstname.lastname@example.org
> > https://lists.mozilla.org/listinfo/dev-js-sourcemap
> dev-js-sourcemap mailing list