The current JSDBGAPI/RDP don't support debugging of dynamically evaluated scripts. Those are not available in the list of scripts and so, there is no way to see them and e.g. create a breakpoint.
A simple test page is available on my site here:
(new Function() is also not working)
Note, that this is quite important feature and it's also blocking Firebug from fully adopting JSD2
From what I've found out looking through old bugs, we need bug 637572 (Debugger.Source) for this to work. See also the bugs that one blocks for more history.
(In reply to Jan Honza Odvarko from comment #0)
> Note, that this is quite important feature and it's also blocking Firebug
> from fully adopting JSD2
As I understand it, JSD didn't do anything about this problem either, so Firebug must be doing something special to work around it. If that is the case, then you could presumably just reapply that workaround on top of JSDBG2?
(In reply to Panos Astithas [:past] from comment #1)
> As I understand it, JSD didn't do anything about this problem either, so
> Firebug must be doing something special to work around it. If that is the
> case, then you could presumably just reapply that workaround on top of
Uh, yeah, as also mentioned in the first comment of bug 637572 that's Firebug does *a lot* of special and hairy logic to have support for various kinds of dynamically evaluated scripts. That's something I'd like to avoid also because the code wouldn't probably have long future.
I am not even user if JSD2 has support for all necessary stuff Firebug needs from JSD1 (e.g. how to get source for the evaluated script?).
Debugger.Source was intended to help us move beyond what I understand to be some of the hairiest bits of Firebug. If we could help Honza avoid bringing all that kludegery forward, it would be great.
Debugger, without Debugger.Source, does create distinct Debugger.Script instances for the code passed to eval and the Function constructor, so it's possible to set breakpoints on them.
However, this isn't really sufficient for debugging. To begin with, I don't see that Debugger has any way for a debugger to recognize that a given script is dynamic --- the URL and line number are, as Honza says, simply inherited from the eval/Function caller. Debugger.Source introduces the concept of an "introduction call", a call to eval/Function/Worker/importScripts/etc. that introduced the code into the system; a debugger can use a Debugger.Source's 'introductionKind', 'introductionScript', and 'introductionScriptOffset' properties to identify exactly where the code came from, and produce a description meaningful to developers.
The protocol spec makes some attempt to say how this information would be exposed, but it's not implemented yet, and probably needs expansion; the Debugger.Source draft specification has much more detail, which would be nice to expose.
(In reply to Jim Blandy :jimb from comment #3)
> the Debugger.Source draft specification has much more detail
Where I can read the details?
The diffs are (were?) a pain to read on github, so you may want to just check them out:
*** Bug 968599 has been marked as a duplicate of this bug. ***
Here's another test case:
(Turn source maps off.)
FWIW here's a test case covering eval()'ed scripts, scripts created via 'new Function()' and by injecting a <script> tag:
A similar test case can also be found here:
This is one of the most wanted features for Shumway -- added whiteboard tag. The JS code is generated from the AVM2 or AVM1 bytes, which makes current devtools unusable to troubleshot most of the defects connected with this component.
Is this moving forward? At the moment it's essentially impossible to debug large parts of Shumway because we can't see generated code, and we JIT-compile AVM bytecode to JS functions, as Yury said in comment 9.
(In reply to Till Schneidereit [:till] from comment #10)
> Is this moving forward? At the moment it's essentially impossible to debug
> large parts of Shumway because we can't see generated code, and we
> JIT-compile AVM bytecode to JS functions, as Yury said in comment 9.
The dependent bug 905700 is in progress, and if this doesn't start to Just Work after that, it will be a high priority follow up.
Marking as P2 to reflect the actual priority.
*** Bug 815992 has been marked as a duplicate of this bug. ***
*** Bug 1044522 has been marked as a duplicate of this bug. ***
This appears fixed now that bug 905700 has landed.