Bug 156021 - Web Inspector: sourceMappingURL not used when sourceURL is set
Summary: Web Inspector: sourceMappingURL not used when sourceURL is set
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: WebKit Nightly Build
Hardware: Mac OS X 10.11
: P2 Normal
Assignee: Joseph Pecoraro
Keywords: InRadar
Depends on:
Reported: 2016-03-30 04:59 PDT by eelco
Modified: 2016-04-15 12:01 PDT (History)
12 users (show)

See Also:

Example to reproduce the bug. (1.27 KB, application/zip)
2016-03-30 04:59 PDT, eelco
no flags Details
[PATCH] Work In Progress - Better BaseURL for resolving Source Mapping URL (931 bytes, patch)
2016-04-13 20:47 PDT, Joseph Pecoraro
no flags Details | Formatted Diff | Diff
[PATCH] Proposed Fix (36.62 KB, patch)
2016-04-14 23:05 PDT, Joseph Pecoraro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description eelco 2016-03-30 04:59:54 PDT
Created attachment 275193 [details]
Example to reproduce the bug.

If both `sourceURL` and `sourceMappingURL` are set in a script, the mapping is not used.

To reproduce:
- Unzip the attached project.
- Host it by executing 'python -m SimpleHTTPServer 1234'
- Go to
- Open the Web Inspector Console (option-cmd-C)
- Look at the first error

- The error is reported as originating from app.js:3

- The error is reported as originating from app.coffee:1

While adding `sourceURL` in this case is not necessary (the script was not generated), it should also not break the source mapping.  Removing the `sourceURL` from `app.js` will lead to the expected behavior.
Comment 1 Radar WebKit Bug Importer 2016-03-30 05:00:48 PDT
Comment 2 Joseph Pecoraro 2016-04-13 20:10:36 PDT
Wow, thanks for the great reduction!

This was actually originally fixed in WebKit but got lost when we changed frontends right before this change landed, see bug 107939. In this case, we have a non-absolute sourceURL ("app.js" instead of something like "http://example.com/js/app.js") so we don't actually resolve the correct URL to the source map resource.
Comment 3 Joseph Pecoraro 2016-04-13 20:46:36 PDT
Hmm, so fixing this first issue gets us to download the source map, but exposes other problems.

The way WebKit's Web Inspector deals with resources is it prefers a Resource over a Script whenever possible. It relates Scripts to Resources based on their URL. However, the "sourceURL" in this case overrides the actual resource URL to this resource, and so this Script never gets associated with the Resource.

So the Resources Sidebar ends up with:

        app.js (this is the Resource)

    Extra Scripts
        app.js (this is the Script)

Had they been correlated correctly we would expect to see just the Resource:

        app.js (this is the Resource, Script associated)

Then when the error comes in, we try to find SourceCodeLocations for that, and prefer a Resource over a Script. Currently the Resource doesn't have the SourceMap associated with it, so we still show the Resource source code location "app.js:3".


On a related note, we have always had this FIXME in Script.js that relating the Script to the Resource by just "URL" is not good enough. To really relate the Script to the correct Resource you have to know at least know the Frame it came from as well to select the correct one.

    // FIXME: We should be able to associate a Script with a Resource through identifiers,
    // we shouldn't need to lookup by URL, which is not safe with frames, where there might
    // be multiple resources with the same URL.
    // <rdar://problem/13373951> Scripts should be able to associate directly with a Resource

So while we can fix the very basic problem that the SourceMap doesn't get downloaded (part of this and bug 156022), addressing the other more systemic issue will take more thought and move us in the right direction. Note this will probably also be needed for bug 150010 as well.

I think now is the time to either:

  1. Figure out a proper way to relate a Script to its Resource
  2. Move the frontend off of requiring this hard relationship to work properly

I'm more for (1) because I think having that relationship is important (the Type Profiler for example requires it).
Comment 4 Joseph Pecoraro 2016-04-13 20:47:23 PDT
Created attachment 276371 [details]
[PATCH] Work In Progress - Better BaseURL for resolving Source Mapping URL
Comment 5 Joseph Pecoraro 2016-04-14 16:48:24 PDT
By providing both the resource URL and sourceURL separately, I get this case working as expected. However, since I'm already changing Debugger.sourceParsed in a non-backwards compatible way, I want to see if I can go a step further and provide the frameIdentifier as well for the script.

Maybe I should do that in a follow-up patch though, since that will likely mean a bunch of tests orthogonal to this specific issue.
Comment 6 Joseph Pecoraro 2016-04-14 23:05:48 PDT
Created attachment 276463 [details]
[PATCH] Proposed Fix
Comment 7 Timothy Hatcher 2016-04-15 11:10:18 PDT
Comment on attachment 276463 [details]
[PATCH] Proposed Fix

View in context: https://bugs.webkit.org/attachment.cgi?id=276463&action=review

> Source/WebInspectorUI/UserInterface/Protocol/InspectorBackend.js:429
> +    hasEventParameter(eventName, eventParameterName)

Comment 8 WebKit Commit Bot 2016-04-15 12:01:29 PDT
Comment on attachment 276463 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 276463

Committed r199602: <http://trac.webkit.org/changeset/199602>
Comment 9 WebKit Commit Bot 2016-04-15 12:01:32 PDT
All reviewed patches have been landed.  Closing bug.