1224078 - script tag using sourceURL doesn't appear in debugger sources pane

Status: RESOLVED INVALID

(DevTools :: Debugger, defect, P3)

Description

[Jason Juang (:juangj)]

Attachment: HTML file for reproduction

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.49 Safari/537.36

Steps to reproduce:

When injecting a <script> tag containing JS and a "//# sourceURL" pragma, I would like the script to appear in the debugger (so I can view the script, set breakpoints, etc.).


Actual results:

In the attached HTML file, 'from-eval.js' appears in the Debugger, but the other two sources do not.


Expected results:

All three of from-eval.js, from-injected-script-tag.js, and from-script-tag.js should appear in the Debugger. This is the case in Chrome.

Comment 1

[Jeremy Danyow]

Attachment: test-case.html

Comment 2

[Jeremy Danyow]

This issue impacts developers using the SystemJS module loader with FireFox. Here are the related issues on GitHub:
https://github.com/systemjs/systemjs/issues/820
https://github.com/systemjs/systemjs/issues/450

Comment 3

[James Long (:jlongster)]

Thanks for the issue. I will take a look soon, but probably not for at least a week or two.

Comment 4

[Jithin Emmanuel]

I am seeing a bit different issue. FF is indeed showing the original source files, but I am not able to set any breakpoints. And using debugger in js code does break, but I have no idea where.

Comment 5

[Marcin Iwanski]

In FF47 I can see script loaded with sourceURL in the Dev Tools Debugger, but I still have a problem with sourceMappingURL in that script. Firefox shows me loaded script, but not the original version mapped by sourceMappingURL map file. It seems that Firefox doesn`t recognize relative sourceMappingURL (only the *.js.map file name). When I change sourceMappingURL to full URL, Debugger shows me original file.

In Chrome there is no such problem, so I assume that there is everything ok with my scripts.
Scripts are loaded by SystemJS loader.

Comment 6

[jmarti221]

Has there been any progress on this bug? The lack of parity with Chrome source maps is really affecting our ability to debug on FF with compiled/transpiled source files.

Comment 7

[Mariano Bianchi]

(In reply to Marcin Iwanski from comment #5)
> In FF47 I can see script loaded with sourceURL in the Dev Tools Debugger,
> but I still have a problem with sourceMappingURL in that script. Firefox
> shows me loaded script, but not the original version mapped by
> sourceMappingURL map file. It seems that Firefox doesn`t recognize relative
> sourceMappingURL (only the *.js.map file name). When I change
> sourceMappingURL to full URL, Debugger shows me original file.
> 
> In Chrome there is no such problem, so I assume that there is everything ok
> with my scripts.
> Scripts are loaded by SystemJS loader.

I tried that in my Firefox install, with a project I'm working on using SystemJS and changing relative url in sourceMappingURL for an absolute url did the trick. Is there any work in progress with this issue?

Comment 8

[Tom Tromey :tromey]

The test case here works in the console bug fails in the debugger.

Comment 9

[Tom Tromey :tromey]

I had to modify the test a bit to avoid script GC.
Otherwise test #2 randomly failed as well.

Comment 10

[Tom Tromey :tromey]

The basic problem is in getSourceURL, which ignores some sources which might validly have a display URL.

Comment 12

[David Spector]

I'm having this problem also, with just one eval acting on the returned JavaScript code from a PHP file acting as a JavaScript Include. I inserted the pragma immediately after the eval. Note that the official and only documentation (https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Debug_eval_sources) contains a clear syntax error. It writes the pragma by example as "//# sourceURL=my-foo.js`;" Note the lone accent grave just before the semicolon. I have tried omitting it, and I have tried putting the file pathname in apostrophe quotes. If someone reads this and knows the answer, is debugging really supported inside evals? If so, how is it done?

Comment 13

[David Spector]

Okay, I figured it out. When you are simulating a JavaScript Include, the included script will be in a variable. Step 1: In your app code, write a separate statement like "eval(IncludedScript);" so you can put a breakpoint on it. Step 2: In the Include file put a statement like the following at the very beginning: "//# sourceURL=FTAdjust.js". In this case, the Include file is FTAdjust.js. Note that there is no semicolon on the pragma. Step 3: reload your app, turn on the debugger, and put a breakpoint in the code that uses the simulated Include statement on the eval line. Step 4: Run your app so the simulated Include statement is executed. It will hit the breakpoint. Step 5: Step in then step over to begin stepping through your eval code. Note that the file name now shows up in the Sources pane.

Okay, so I didn't see the same bug as is reported here. But I did provide everyone with a useful debugging ability, yes?

Comment 14

[Jason Laster [:jlast]]

David, this sounds like the debugger works for you? Is that correct? If not, could you let me know what's not working?

Comment 15

[David Spector]

Sorry if I wasn't clear. What's not working is that when you write code that dynamically references code in another file, normally the debugger will fail to list that other file in the list of source files until it is actually referenced. A great solution would be to recognize a pragma to add a file to the list of source files. This is just what pragmas are for: to indicate information that cannot be calculated lexically by the debugger. This is a variant of the undecidability of the Halting Problem (https://en.wikipedia.org/wiki/Halting_problem).

Comment 16

[Jason Laster [:jlast]]

Attachment: Screen Shot 2019-06-10 at 1.57.01 PM.png

This is what I'm seeing. It is missing one of the eval'd scripts

Comment 17

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: image.png

(In reply to David Spector from comment #12)

(https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/
Debug_eval_sources) contains a clear syntax error. It writes the pragma by
example as "//# sourceURL=my-foo.js`;" Note the lone accent grave just
before the semicolon.

I copied the code from MDN and it works for me.

(In reply to David Spector from comment #13)

Okay, I figured it out. When you are simulating a JavaScript Include, the
included script will be in a variable. Step 1: In your app code, write a
separate statement like "eval(IncludedScript);" so you can put a breakpoint
on it. Step 2: In the Include file put a statement like the following at the
very beginning: "//# sourceURL=FTAdjust.js". In this case, the Include file
is FTAdjust.js. Note that there is no semicolon on the pragma. Step 3:
reload your app, turn on the debugger, and put a breakpoint in the code that
uses the simulated Include statement on the eval line. Step 4: Run your app
so the simulated Include statement is executed. It will hit the breakpoint.
Step 5: Step in then step over to begin stepping through your eval code.
Note that the file name now shows up in the Sources pane.

Okay, so I didn't see the same bug as is reported here. But I did provide
everyone with a useful debugging ability, yes?

Please file another report for this + a test case we can use to reproduce on our machines.

The original bug is fixed in new Debugger UI and I am closing this report.

Honza

Comment 18

[David Spector]

Honza, Thanks for your request for another report and a test case, but I have given up on my Webextensions programming after having too much frustration with its needless inter-process programming complications and difficulty in debugging. I truly am happy never to return to my attempt to write a simple Firefox extension.

Comment 19

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to David Spector from comment #18)

Honza, Thanks for your request for another report and a test case, but I have given up on my Webextensions programming after having too much frustration with its needless inter-process programming complications and difficulty in debugging. I truly am happy never to return to my attempt to write a simple Firefox extension.

I see, thanks for quick response!
Honza