[Webkit-unassigned] [Bug 142091] Web Inspector: Type information, code coverage, and pretty print don't work with source mapped files

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from Joseph Pecoraro <joepeck at webkit.org> ---
We only have a pretty printer for CSS / JS. If the resource you are looking at is a different type, then pretty printing would be disabled. Assuming we add a pretty printer for the particular mime type we could enable it. SourceCodeTextEditor has:

    canBeFormatted: function()
    {
        // Currently we assume that source map resources are formatted how the author wants it.
        // We could allow source map resources to be formatted, we would then need to make
        // SourceCodeLocation watch listen for mappedResource's formatting changes, and keep
        // a formatted location alongside the regular mapped location.
        if (this._sourceCode instanceof WebInspector.SourceMapResource)
            return false;
        ...
    }

Since source maps are almost always the user authored styles, it seems fine if pretty-printing is not enabled. Do you have a good counter-example?



As for code coverage / type information. I don't think we have tried yet to map JS code blocks back to the original. That will take some experimentation but seems worthwhile! For simple minification this should work well.

One issue with source mapping is variable renames are lost. If a function "foo(alpha, beta)" is minified to "f(a,b)" the variable names have changed. This is the best case, which we might be able to detect. But worst case, the code is transformed in a non 1-1 mapping, and variable names cannot be determined. Looking at some code in the source map resource, it may may have been expanded in multiple places (inlined for instance) in the generated resource. SourceMaps provide the mapping from generated resource back to original resource, not necessarily the other way around.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150227/70255a17/attachment-0002.html>