[Webkit-unassigned] [Bug 30933] New: Web Inspector: support for debugging alt-JS files which generate JS

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30933

           Summary: Web Inspector: support for debugging alt-JS files
                    which generate JS
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Web Inspector
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pmuellr at yahoo.com
                CC: timothy at hatcher.name, rik at webkit.org,
                    casey.hattori at gmail.com, pmuellr at yahoo.com,
                    joepeck at webkit.org, pfeldman at chromium.org,
                    bweinstein at apple.com


There are quite a few alt-JS language implementations available today -
Objective-J (like Objective-C, but for JS), EGL (4GL from IBM), Clamato
(Smalltalk), Schemes, Pythons, and Rubys.  It would be nice to be able to
support these somehow in Web Inspector.

Here's the thought.  For alt-JS implementations which generate JavaScript code
and then eval() it, we can have those implementations make additional debug
information available that can map the generated JavaScript code back to the
original source.  Information such as a URL to the original alt-JS source
file(s), a line number map (from original to generated code), etc.

The additional information, or pointers to it, would be added to the generated
JS files, perhaps in the same kind of comment/directive format used for
//@sourceURL= that allows naming your evals.

An initial implementation which just supported an alternate source
representation and line number map could be used for setting breakpoints and
stepping through the code.  Dealing with mapping locals and other
variables/properties, as well as stack manipulation, would be a lot more work. 
As a point of reference, some alt-JVM languages make use of existing Java
bytecode facilities to handle just the source code/line numbers, and the
resulting debugger experience is acceptable (eg, Groovy).

Given the alternative source and line number mappings, we can translate
requests to/from the the JS engine to render the original source in the
debugger views, supporting setting breakpoints, stepping, etc.

Tom Robinson noted that Caja seems to be generating debug info like this: 

  
http://code.google.com/p/google-caja/source/browse/trunk/tests/com/google/caja/parser/quasiliteral/testModule.co.js

Should also check with FireBug folks to see if they're doing anything.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.