Bug 142091 – Web Inspector: Type information, code coverage, and pretty print don't work with source mapped files

• Component: Web Inspector
• Status: ASSIGNED

[Ronald Jett]

Created attachment 247523 [details]
Screenshot of how the buttons look when looking at a source mapped file

I've yet to successfully get any of the new Web Inspector features working in our project. I think it has something to do with source mapping (we use inline). If I click on the built file the the Resources pane, the type and pretty print buttons become available, but if I drill down in to a particular file I can't enable them.

[Radar WebKit Bug Importer]

<rdar://problem/19986753>

[Timothy Hatcher]

What is the mime type of the source mapped resource?

[Joseph Pecoraro]

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.

[Ronald Jett]

The source mapped files are JavaScript files. 

It makes sense that the the pretty printer doesn't work for source mapped files. It just felt odd that it didn't work. Maybe it should be hidden when viewing source mapped files? 

We never work with the original JavaScript files in our projects. All files are built in to a single debug file that gets included on the page, so it might be nice if the code coverage and type information worked here. 

The type / code coverage info is available if I look at my top level built file, but if I set breakpoints, when they hit I'm taken in to the source mapped file. So if I want to see that info I have to go back to the single file and scroll through my source looking for that particular point in code.

[Timothy Hatcher]

If the source mapped files are JavaScript, we should be able to pretty print them. I suspect we just don't have the right MIME-type or some other bugs here.

[Joseph Pecoraro]

(In reply to comment #5)
> If the source mapped files are JavaScript, we should be able to pretty print
> them. I suspect we just don't have the right MIME-type or some other bugs
> here.

See the code snippet from Comment #3.

[Timothy Hatcher]

Oh, sorry Joe. Didn't see that. Makes sense.