Closed Bug 865313 Opened 12 years ago Closed 10 years ago

It is not possible to debug dynamically evaluated scripts

Categories

(DevTools :: Debugger, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 36

People

(Reporter: Honza, Unassigned)

References

Details

(Whiteboard: [shumway:p1][js:p2])

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: http://www.softwareishard.com/firebug/jsd2/tests/eval/eval.html (new Function() is also not working) Note, that this is quite important feature and it's also blocking Firebug from fully adopting JSD2 Honza
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?
Depends on: 637572
OS: Windows Vista → All
Priority: -- → P3
Hardware: x86 → All
(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 > JSDBG2? 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?). Honza
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? Honza
The diffs are (were?) a pain to read on github, so you may want to just check them out: https://github.com/jimblandy/DebuggerDocs/blob/Debugger.Source/api
Here's another test case: www.gwtproject.org/ (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: https://getfirebug.com/tests/manual/mozilla/bug865313/bug865313.html A similar test case can also be found here: http://code.google.com/p/fbug/issues/detail?id=7201 Sebastian
Depends on: dbg-source
No longer depends on: 637572
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.
Whiteboard: [shumway]
Whiteboard: [shumway] → [shumway:p1][js:p2]
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.
No longer blocks: shumway-m4
Marking as P2 to reflect the actual priority.
Priority: P3 → P2
This appears fixed now that bug 905700 has landed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Depends on: 1122222
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.