Last Comment Bug 865313 - It is not possible to debug dynamically evaluated scripts
: It is not possible to debug dynamically evaluated scripts
Status: RESOLVED FIXED
[shumway:p1][js:p2]
:
Product: Firefox
Classification: Client Software
Component: Developer Tools: Debugger (show other bugs)
: unspecified
: All All
: P2 normal with 2 votes (vote)
: Firefox 36
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 815992 968599 1044522 (view as bug list)
Depends on: 1122222 dbg-source
Blocks: 1021373 800200
  Show dependency treegraph
 
Reported: 2013-04-24 09:34 PDT by Jan Honza Odvarko [:Honza] PTO 07/23 - 08/08
Modified: 2015-01-20 12:47 PST (History)
19 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jan Honza Odvarko [:Honza] PTO 07/23 - 08/08 2013-04-24 09:34:56 PDT
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
Comment 1 Panos Astithas [:past] 2013-04-25 02:38:09 PDT
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?
Comment 2 Jan Honza Odvarko [:Honza] PTO 07/23 - 08/08 2013-04-25 06:25:40 PDT
(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
Comment 3 Jim Blandy :jimb 2013-04-26 16:50:36 PDT
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.
Comment 4 Jan Honza Odvarko [:Honza] PTO 07/23 - 08/08 2013-04-29 04:25:14 PDT
(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
Comment 5 Jim Blandy :jimb 2013-04-29 11:31:45 PDT
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
Comment 6 Brian Slesinsky 2014-02-10 14:22:46 PST
*** Bug 968599 has been marked as a duplicate of this bug. ***
Comment 7 Brian Slesinsky 2014-02-10 14:26:32 PST
Here's another test case:

www.gwtproject.org/

(Turn source maps off.)
Comment 8 Sebastian Zartner [:sebo] 2014-02-25 00:08:29 PST
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
Comment 9 Yury Delendik (:yury) 2014-03-11 19:01:31 PDT
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.
Comment 10 Till Schneidereit [:till] (pto July 23 - July 31) 2014-07-12 04:53:38 PDT
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.
Comment 11 Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7] 2014-07-12 09:23:36 PDT
(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.
Comment 12 Panos Astithas [:past] 2014-07-14 02:44:56 PDT
Marking as P2 to reflect the actual priority.
Comment 13 Nick Fitzgerald [:fitzgen] [⏰PDT; UTC-7] 2014-07-14 15:00:21 PDT
*** Bug 815992 has been marked as a duplicate of this bug. ***
Comment 14 Panos Astithas [:past] 2014-07-28 03:00:01 PDT
*** Bug 1044522 has been marked as a duplicate of this bug. ***
Comment 15 Matt Brubeck (:mbrubeck) 2014-12-03 12:40:27 PST
This appears fixed now that bug 905700 has landed.

Note You need to log in before you can comment on or make changes to this bug.