929116 - Setting breakpoints on eval scripts with a sourcemap

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Kannan Vijayan [:djvj]]

Currently, if we |eval| a script with a //# sourceMappingURL=... annotation, then the foreign source file is added to the debugger.

However, breakpoints set on the foreign source file, in functions introduced by the eval-ed string, are not property set on the actual script.

Example:

test.coffee:
  window.fun = () -> {
    ...
  }

test.coffee is compiled to js, generating a source-map file "test.map", and the js-code evaled with:

eval(TEST_COFFEE_JS + "//# sourceMappingURL=test.map")

This causes test.coffee to show up as a file in the debugger, but breakpoints set within the coffeescript function aren't property set on the generated js code (and thus don't trigger when calling the eval-introduced function).

Comment 1

[Brian Slesinsky]

This is necessary for GWT debugging as well.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

This is unrelated to the old, deprecated JSD API, so I'm updating the summary to avoid confusion.

Comment 3

[Kannan Vijayan [:djvj]]

Nick, I can help out with implementing this functionality.  Jim indicated that there were a number of steps required to fix this up (changing how the debugger associates filenames with scripts to use displayName as well as fileName, fixing line number info for eval scripts, etc.).

If you could describe those steps in more detail in the bug, and give me a heads up on where to get started, I can begin work on resolving them.

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

The displayName is irrelevant here, that is for //# sourceURL directives.

Currently, all breakpoints are stored server side in the BreakpointStore[0]. The BreakpointStore saves the generated locations of breakpoints. One of the large (and false) assumptions we make in the debugger server is that sources are uniquely identifiable by URL. It was a compromise we had to make at the time. However, it is also what causes issues with eval'd scripts, since we don't end up storing them in the BreakpointStore because they don't have a URL.

I'm going to start cleaning up this mess and getting rid of that assumption sometime next quarter, but in the meantime we could make the assumption that D.Script#sourceMapURL can be a unique id for a source. Then, when we have an eval'd script with a source map, we can store the breakpoints in BreakpointStore by { sourceMapURL, line, column }. You'll also need to handle when we are adding new scripts (say because of a reload) and we are re-setting breakpoints[1] on those scripts.

As far as the line number offsets goes, I think that is just lineWhereTheEvalOccurs + lineInTheEvaledSource, Jim would know this stuff better than me. I think we would probably want to account for this in _setBreakpoint[2].


[0] http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js#9

[1] http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js#2206

[2] https://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js#1358

Comment 5

[Brian Slesinsky]

What do you mean by D.script? The unique ID has consequences for apps since we want to make sure breakpoints can be preserved across recompiles.

In GWT the URL containing the JavaScript that executes the eval() contains a sha1 hash based on the source code, so it's not stable across recompiles. The //#sourceURL should be stable. The //# sourceMappingUrl may or may not be stable, depending on whether it contains the hash.

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Brian Slesinsky from comment #5)
> What do you mean by D.script? The unique ID has consequences for apps since
> we want to make sure breakpoints can be preserved across recompiles.

D.Script is Debugger.Script, part of SpiderMonkey's debugger API: https://wiki.mozilla.org/Debugger

Agreed, we want to ensure that breakpoints can be preserved across recompiles.

> 
> In GWT the URL containing the JavaScript that executes the eval() contains a
> sha1 hash based on the source code, so it's not stable across recompiles.
> The //#sourceURL should be stable. The //# sourceMappingUrl may or may not
> be stable, depending on whether it contains the hash.

The idea I laid out above is for when we do not have //# sourceURL=... and only have a //# sourceMappingURL=..., if we had sourceURL, we could just use that in the BreakpointStore. We have a separate bug for supporting //# sourceURL=... directives: bug 833744.

Comment 7

[Eddy Bruel [:ejpbruel]]

This should be fixed automatically once bug 865313 lands, so what you proposed in comment 6 is a temporary workaround, correct?

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I believe so.

Comment 9

[Tom Tromey :tromey]

I think this has been fixed for a while now, maybe even bug 865313 like Eddy said in comment #7.
I gave it a try locally using a source mapped eval and it seems to work fine.
Please reopen if I'm in error.