The default bug view has changed. See this FAQ.

unable to debug scripts loaded via loadSubScript in Browser Debugger

RESOLVED FIXED in Firefox 22

Status

()

Firefox
Developer Tools: Debugger
P2
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: rc, Assigned: past)

Tracking

unspecified
Firefox 22
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [chrome-debug])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

4 years ago
similar to bug 816988 and bug 808588.

Scripts loaded via the loadSubScript mechanism are not debuggable. This is kind of key for debugging addon sdk scripts.
(Reporter)

Updated

4 years ago
Whiteboard: [chrome-debug]

Comment 1

4 years ago
please fix this, it will sure make firefox extension development feel modern.
no more alert debugging.. :)
Filter on BLACKEAGLE2.
Assignee: nobody → past
Priority: -- → P2

Comment 3

4 years ago
This is frustrating to develop my extensions. To tests any code change to my JavaScript i have to completely restart Firefox and navigate back to the page i was testing on. I have all of the items set below and  even press the "Reload Chrome" button. My extension JavaScript loaded with loadSubScript() still is not get refreshed.

I have all of theses things set:
    argument: -purgecaches
    nglayout.debug.disable xul fastload = true
    nglayout.debug.disable_xul_cache = true
    browser.dom.window.dump.enabled = true

Comment 4

4 years ago
This is weird. What is Debugger.Script.prototype.findScripts returning? Is it somehow skipping those? Has the common global object that all the JSMs share been added as a debuggee?
(Reporter)

Comment 5

4 years ago
(In reply to Jim Blandy :jimb from comment #4)
> This is weird. What is Debugger.Script.prototype.findScripts returning? Is
> it somehow skipping those? Has the common global object that all the JSMs
> share been added as a debuggee?

Nope. Adding a dumpn inside our caller of findScripts, I'm getting a full spew of loaded files including scripts added via <script> and loadSubScript.

e.g., 
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:711-717
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:720
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:727-777
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:780-813
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:816-836
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:840-842
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:847-849
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:854-894
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:864-873
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:866-872
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:903-908
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:911-919
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:925-946
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:950-1008
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:978-982
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:275-352
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:307-317
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:356-360
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:364-396
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:407-430
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:433-442
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:445-452
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:455-471
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:475-502
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:494-499
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:506-526
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:530-546
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:550-566
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:569
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:570
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:571
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:572
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:573
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:574
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:577-586
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:590-615
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:39
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:40-52
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:56
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:57-84
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:95-101
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:104
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:106
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:107
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:108
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:110-115
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:118
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:120-122
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:125-133
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:136
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:138-175
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:178-181
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:184-185
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:188-208
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:211-237
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:240-247
DBG-SERVER: adding: chrome://browser/content/places/browserPlacesViews.js:251-271
DBG-SERVER: adding: chrome://global/content/viewZoomOverlay.js:14-17
DBG-SERVER: adding: chrome://global/content/viewZoomOverlay.js:20-22
DBG-SERVER: adding: chrome://global/content/viewZoomOverlay.js:25-27
DBG-SERVER: adding: chrome://global/content/viewZoomOverlay.js:30-31
DBG-SERVER: adding: chrome://global/content/viewZoomOverlay.js:34-36
DBG-SERVER: adding: chrome://global/content/viewZoomOverlay.js:39-40

little odd that the line runs are appearing out of sequence in some cases, but I didn't look at how findScripts is gathering these things.

I'm beginning to wonder if the error's in setBreakpoint().
(Reporter)

Comment 6

4 years ago
Confirmed that at least some files loaded via loadSubScript appear in the files list.

Also, some files are debuggable via the browser debugger. Was just able to debug orion.js by setting a breakpoint in the onMouseOver handler in the Ruler.
(Reporter)

Comment 7

4 years ago
this might be just because of the way we're referring to jarred js files. See bug 808960.
Depends on: 808960
I've also confirmed that some scripts appear multiple times, as Rob discovered, which could explain why the breakpoint is set, but not triggered.
Status: NEW → ASSIGNED
Created attachment 716776 [details] [diff] [review]
WIP 1

Work in progress. Breaks stuff.
Blocks: 808588
Created attachment 722489 [details] [diff] [review]
WIP 2

All tests now pass, but not yet improving things.
Attachment #716776 - Attachment is obsolete: true
Created attachment 724621 [details] [diff] [review]
WIP 3

Moar debug spew for Eddy.
Attachment #722489 - Attachment is obsolete: true
Created attachment 725136 [details] [diff] [review]
Refactor _setBreakpoint to bypass the script cache

Here's a patch that fixes the problem by bypassing the script cache for setBreakpoint.
Attachment #725136 - Flags: review?(past)
Comment on attachment 725136 [details] [diff] [review]
Refactor _setBreakpoint to bypass the script cache

Review of attachment 725136 [details] [diff] [review]:
-----------------------------------------------------------------

I'd like it with an abundance of comments like before, but I can fix that in the followup refactoring. A test would also be good, but testing chrome debugging is Really Hard, so I'm fine with it as it is.
Attachment #725136 - Flags: review?(past) → review+
Attachment #724621 - Attachment is obsolete: true
https://hg.mozilla.org/integration/fx-team/rev/b832bfd6fc24
Whiteboard: [chrome-debug] → [chrome-debug][fixed-in-fx-team]
Duplicate of this bug: 842040
Depends on: 851836
https://hg.mozilla.org/mozilla-central/rev/b832bfd6fc24
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [chrome-debug][fixed-in-fx-team] → [chrome-debug]
Target Milestone: --- → Firefox 22

Comment 17

4 years ago
Hi, I just tried to debug my xul plugin on the latest nightly, and I still could not run break points on the javascript.
am I missing something?
(In reply to omri.baumer from comment #17)
> Hi, I just tried to debug my xul plugin on the latest nightly, and I still
> could not run break points on the javascript.
> am I missing something?

The fix we came up with solved all the issues we know about, but its possible that there are other corner cases. Could you file another bug with steps to reproduce and cc me on it?
Also make sure that you are running a nightly with this fix, because AFAIK Nightly updates have been disabled for the past few days.

Comment 20

4 years ago
I think I have the correct version, its a nightly build from yesterday, 18.3.2013.
I downloaded it today.

as for how to reproduce: I just put a break point in a js file, thats loaded in the content.xul. the break point is on a function that is called on the dom finished loading event, and the breakpoint does not stop.

should I open another bug for it?
(In reply to omri.baumer from comment #20)
> I think I have the correct version, its a nightly build from yesterday,
> 18.3.2013.
> I downloaded it today.
> 
> as for how to reproduce: I just put a break point in a js file, thats loaded
> in the content.xul. the break point is on a function that is called on the
> dom finished loading event, and the breakpoint does not stop.
> 
> should I open another bug for it?

Yes please. And preferably attach your test addon code to the bug so we can reproduce.
The nightly build of 18.3.2013 doesn't include this commit. It's based on http://hg.mozilla.org/mozilla-central/rev/b03bb3ce8cee.

This commit will be included in 19.3.2013 (today's) one.
You should wait & confirm on 19.3.2013 before filing the bug.
The current nightly does include this patch, and does work:

https://www.evernote.com/shard/s1/sh/0188b6d7-3b7d-428e-b482-ea201f563541/e2d6cb6b627871d85f2678b894495644

This is just amazing! Jetpacks can now be debugged.

I see two current limitations:

1. main.js will not appear unless you coax it by disabling / enabling if the main.js code does not keep any references. Luckily most Jetpack code does establish some references to tabs, workers, etc.

2. breakpoints don't seem to be reached in some kinds of add-on code, for example jsterm.js, this code is never reached. This is noit a Jetpack, it is instead Paul's JS Terminal, a restartless add-on that does not use Jetpack.
(In reply to Jeff Griffiths (:canuckistani) from comment #23)
> The current nightly does include this patch, and does work:
> 
> https://www.evernote.com/shard/s1/sh/0188b6d7-3b7d-428e-b482-ea201f563541/
> e2d6cb6b627871d85f2678b894495644
> 
> This is just amazing! Jetpacks can now be debugged.
> 
> I see two current limitations:
> 
> 1. main.js will not appear unless you coax it by disabling / enabling if the
> main.js code does not keep any references. Luckily most Jetpack code does
> establish some references to tabs, workers, etc.

If this is a one-off script that gets GC'd before the debugger is opened, then yes, it will not be available for inspection.

> 2. breakpoints don't seem to be reached in some kinds of add-on code, for
> example jsterm.js, this code is never reached. This is noit a Jetpack, it is
> instead Paul's JS Terminal, a restartless add-on that does not use Jetpack.

I can set a breakpoint that triggers in jsterm.js:153 for instance. Can you share more details on what didn't work for you?
You need to log in before you can comment on or make changes to this bug.