Closed Bug 1224078 Opened 9 years ago Closed 5 years ago

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

Categories

(DevTools :: Debugger, defect, P3)

Product:
DevTools
Component:
Debugger
Version:
42 Branch
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: juangj, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

HTML file for reproduction
(deleted), text/html
Details
test-case.html
(deleted), text/plain
Details
Screen Shot 2019-06-10 at 1.57.01 PM.png
(deleted), image/png
Details
image.png
(deleted), image/png
Details
Attached file HTML file for reproduction (deleted) —
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.
Component: Untriaged → Developer Tools: Debugger
Attached file test-case.html (deleted) —
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
Thanks for the issue. I will take a look soon, but probably not for at least a week or two.
Assignee: nobody → jlong
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
Assignee: jlong → nobody
(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?
Blocks: source-maps
The test case here works in the console bug fails in the debugger.
Priority: -- → P3
I had to modify the test a bit to avoid script GC. Otherwise test #2 randomly failed as well.
The basic problem is in getSourceURL, which ignores some sources which might validly have a display URL.
Product: Firefox → DevTools
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?
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?

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

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED

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).

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

Whiteboard: needs-review
Attached image image.png (deleted) —

(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

Status: REOPENED → RESOLVED
Closed: 6 years ago → 5 years ago
Resolution: --- → INVALID
Whiteboard: needs-review

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.

(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

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: