Check to see if "X-SourceMap" HTTP response header was sent with script resource. Header value will be used as auto suggestion for source map url in UI.
Created attachment 118399 [details] Patch
Comment on attachment 118399 [details] Patch Attachment 118399 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10786302 New failing tests: inspector/debugger/raw-source-code.html
Created attachment 118571 [details] Patch
See https://bugs.webkit.org/show_bug.cgi?id=74181 for how it is going to be used.
Comment on attachment 118571 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=118571&action=review > Source/WebCore/ChangeLog:8 > + Check to see if "X-SourceMap" HTTP response header was sent with script resource. Is there a discussion on the X-SourceMap name? > Source/WebCore/inspector/Inspector.json:1994 > + { "name": "sourceMapURL", "type": "string", "description": "URL of source map associated with script (if any)." }, We should not process sourceMapURL on the backend (node.js won't have it). User should listen to the network and get it from there.
(In reply to comment #5) > (From update of attachment 118571 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=118571&action=review > > > Source/WebCore/ChangeLog:8 > > + Check to see if "X-SourceMap" HTTP response header was sent with script resource. > > Is there a discussion on the X-SourceMap name? > > > Source/WebCore/inspector/Inspector.json:1994 > > + { "name": "sourceMapURL", "type": "string", "description": "URL of source map associated with script (if any)." }, > > We should not process sourceMapURL on the backend (node.js won't have it). User should listen to the network and get it from there. We will need to process sourceMapURL on the backend to support //@sourceMapURL comment to avoid loading all the script sources to frontend. X-SourceMap header is sent to frontend only for the very first time. After resource is cached, it would not be sent again.
Comment on attachment 118571 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=118571&action=review >> Source/WebCore/inspector/Inspector.json:1994 >> + { "name": "sourceMapURL", "type": "string", "description": "URL of source map associated with script (if any)." }, > > We should not process sourceMapURL on the backend (node.js won't have it). User should listen to the network and get it from there. You should at least make this optional.
Committed r103405: <http://trac.webkit.org/changeset/103405>
Reverted r103405 for reason: it broke WorkerDevToolsSanityTest.InspectSharedWorker Committed r103500: <http://trac.webkit.org/changeset/103500>
Committed r103532: <http://trac.webkit.org/changeset/103532>
Is there an example of source map file? Say, for CoffeeScript.
(In reply to comment #11) > Is there an example of source map file? Say, for CoffeeScript. There is nothing for CoffeeScript as far as I know, but podivilov@ was going to help with generating one. Here is the source map v3 proposal: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US&pli=1&pli=1
Who does need/use source maps currently?
(In reply to comment #13) > Who does need/use source maps currently? SourceMaps are used by: 1) web developers that use compiled languages such as CoffeeScript, Closure Compiler, GWT, etc for their day to day development. The tool is converting sources from compiled JavaScript back to the original source code and allow debugging in term of the original source. 2) web developers for debugging production (minified) code. Developers load private mapping and see the original source code while debugging. Web Inspector is the first source map implementation I know of that is in production. We still need to work on particular use cases with the compiled framework owners. Mozilla is on board with the standard and I think I've seen their working prototype with CoffeeScript SourceMaps somewhere.
Thanks Pavel. Would be nice to have at least one example for minified javascript. I haven't found one in the tests. Mozilla's work on it: https://wiki.mozilla.org/DevTools/Features/SourceMap https://github.com/mozilla/source-map Source map generator
(In reply to comment #14) > (In reply to comment #13) > > Who does need/use source maps currently? > > SourceMaps are used by: > 1) web developers that use compiled languages such as CoffeeScript, Closure Compiler, GWT, etc for their day to day development. The tool is converting sources from compiled JavaScript back to the original source code and allow debugging in term of the original source. > > 2) web developers for debugging production (minified) code. Developers load private mapping and see the original source code while debugging. Just a note that these are "needs" and not "uses", since I'm not aware of anyone using SourceMaps in the field today. > ... I think I've seen their working prototype with CoffeeScript SourceMaps somewhere. I don't believe there exists a version of CoffeeScript that generates SourceMaps, but there's a bug open for it: https://github.com/jashkenas/coffee-script/issues/558 (In reply to comment #15) > Would be nice to have at least one example for minified javascript. Yes. I'd like to see something that works in a browser available today. Perhaps someone can post a blog entry describing how us mortals can use it? I think the closure compiler generates sourcemaps, so an example minizing a couple of js files together, but debugging them as separate files, would be good enough. In fact, I've been cautioning folks that I don't believe SourceMaps are real until I see them working. Not quite true - I'm sure it'll work in theory, but theory !=practice. Like, do we need an .html wrapper so you can JSONP the sourcemap data (per a previous discussion in a Web Inspector bug)?