Closed Bug 679189 Opened 9 years ago Closed 7 years ago

Don't rely on only a window/url combination for finding source maps, aka support source maps for eval'd or script tag injected scripts

Categories

(DevTools :: Debugger, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: fitzgen, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [source-maps])

This way we will be able to see the mapped locations of eval'd or script injected code.
Blocks: 670002
Depends on: 677389
Depends on: 679031
No longer depends on: 677389
Perhaps it has been discussed before, but in order to achieve this and more, would it make sense to add a "hash: <sha1>" field to the file format ?
It could render the //@sourceMapFile=<URL> comment optional.

With such hash, there could be a guarantee that the source map file is up-to-date with the current script the developer is debugging/inspecting.

Also a developer could store all its source maps in one directory where hashes are looked up, and then be able to debug any version of the scripts (including production or third-party websites using the script where //@sourceMapFile might not make sense).
(In reply to Cedric Vivier [cedricv] from comment #1)
First off, I'd like to note that the spec is *this* close to being finalized, so I am hesitant to try and bring up anything new unless it is really worth it.

> Perhaps it has been discussed before, but in order to achieve this and more,
> would it make sense to add a "hash: <sha1>" field to the file format ?
> It could render the //@sourceMapFile=<URL> comment optional.

I'm not sure how it would make the @sourceMappingURL optional; how would you find the source map in the first place?

> With such hash, there could be a guarantee that the source map file is
> up-to-date with the current script the developer is debugging/inspecting.

True.

> Also a developer could store all its source maps in one directory where
> hashes are looked up, and then be able to debug any version of the scripts
> (including production or third-party websites using the script where
> //@sourceMapFile might not make sense).

I'm not sure exactly what you mean, here.
I mean that the hash could take precedence on //@sourceMappingURL (if even present).

In debug mode, a lookup of the script hash is done against a sourcemap repository (local and/or possibly remote).
For instance, it could be a ~/sourcemaps directory organized as ~sourcemaps/<friendly name>-<hash>.smap

This is a bit similar to how gdb debug symbols are automatically fetched on some Linux distributions.
If the sourceMappingURL is necessary for locating the source map, and the main benefit of the hash is the up-to-date guarantee, why not use standard HTTP means, like Etags and Last-modified headers, to achieve the same effect? Introducing the concept of a repository can open a can of worms.
As long as the format defines a 'hash' property, there is multiple ways to benefit from it, that different source map debugging tools/implementations can use later (possibly as add-ons to the tools themselves).

I'm not sure the up-to-date guarantee is *the* main benefit, not having to deal with adding and updating a comment - on scripts not necessarily under my control [eg. mashups]) sounds to me at least as handy.


Comparatively, it's a joy when I debug native code that uses third-party libfoo and that gdb automatically downloads debug symbols of that library when I crash in it, possibly because I use the API incorrectly.
This discussion might be better suited for d-a-f. I've realized that I named this bug poorly: I currently have a method something like `sourceMapURLForFilename(aFilename, aWindow)`, but I need to make it more generic and optionally take another parameter `aScript`. This is because it is possible to get the source map url for scripts which have been eval'd, but I just didn't code it that way when I should have. This is really a rather minor bug, pretty unrelated to this discussion...
yeah, I think it's a little late in the game to radically change the spec at this point. Might be worth discussing for Version 2 though.
Because eval'd and script tag injected scripts don't have source urls, we need another way to get the source map url. The way we get our info is through nsIScriptErrors, and the associated JSScript for those (which have the source map url) are long since gc'd by the time we get the nsIScriptErrors.
Depends on: 683733
Summary: Don't rely on only a window/url combination for finding source maps, it should be able to take scripts as well → Don't rely on only a window/url combination for finding source maps, aka support source maps for eval'd or script tag injected scripts
No longer blocks: 670002
No longer depends on: 683733
I'm going to move this into the debugger component for now. I think it's a good place to hold these.
Component: Developer Tools → Developer Tools: Debugger
Whiteboard: [source-maps]
cc'ing jimb. I suspect this will require some engine changes to make work.

filter on TAKETHATPAUL.
Priority: -- → P3
Just stumbled on this bug while doing research on this.

There seems to be a straightforward way to do dynamic source maps: include the sourcemap json in the comment, and also include the full original source(es) in that json. Since it's all automatically generated, it doesn't really matter how long the line becomes.

I've just outlined it at http://qfox.nl/weblog/280 , small example of how it would look:

//@ sourceMapping={version:4, source:'function foo(){\n...', names:[...], mappings: 'AAA...'}

This renders a few fields of version 3 useless (they are omitted above). It also pushes for making the source index optional in each segment (which is something that should have happened anyways, and I hope will for v4).

This way you can have dynamic source maps at, I feel, minimal effort. But I'm sure it won't actually be "minimal"...
Peter,

I am sorry that I haven't responded to you in a timely fashion, since you have been reaching out to me over a few different mediums. I have had the flu and been pretty bed ridden for the last few days, I hope that is a good enough excuse :)

Anyways, this bug is the wrong place to discuss the things that you are proposing. This bug can actually probably be closed since it is really a dup of bug 637572 or at least relies on that bug.

I will write up a proper response to your proposal and ping you with it.

Nick
We will need the ability to inject source maps (or at least a trivial subset thereof) to implement a module loader for workers (bug 872421), which is itself on one of the critical paths to making chrome workers useful for platform refactorings.

So, what is blocking this bug? Is there something we can do to get it to progress?

Note that getting this to work in workers means that we cannot rely on xpcom/xpconnect in client code.
Blocks: 872421
I'm going to close this bug because it was really created for something that was specific to how I was going to implement source mapped output in the webconsole almost two years ago.

Now that we have source map urls attached directly to Debugger.Script, you can get the source map for a script regardless of how it was introduced to the js engine.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
So, how do I eval() with a sourcemap?
Flags: needinfo?(nfitzgerald)
Add the "//@ sourceMappingURL=..." comment to the end of the source to be evaluated. You can use a data URI if the source map isn't accessible by any URL, and things should Just Work (tm).

The source map url is available via Debugger.Script.prototype.sourceMapURL.
Flags: needinfo?(nfitzgerald)
And will that be reflected in exceptions, too?
I assume you mean will the stack trace report the source mapped locations?

Source maps don't change anything in the engine except for the sourceMapURL property mentioned above. It is the responsibility of whatever tool wants to get source mapped information to query the sources/positions itself. For example, we do the querying in the server for the debugger, before we send the client the source.
Ok, so in that case, source maps are not what I'm looking for. Falling back to bug 583083.

Thanks.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.