Alex Vincent [:WeirdAl] Reporter
	Description • 9 years ago

Testcase coming in a few minutes.  Note this works fine when debugged as a HTML page in the same browser session.

If I set a debugger keyword in a CoffeeScript file, and try the step in command after hitting that debugger keyword, the debuggee application is frozen forever, and the debugger itself locks up.

	Alex Vincent [:WeirdAl] Reporter
	Comment 1 • 9 years ago

Setup:
(01) Create an empty directory and cd to it.
(02) Download bug1167725-test.tar.bz2 to that directory.
(03) tar -xjvf bug1167725-test.tar.bz2
(04) mkdir profile1 profile2

Verify HTML debugging still works:
(05) firefox --no-remote -profile ./profile1 ./debugtest/index.html
(06) In the Firefox instance, start a debugger for the webpage that loads.
(07) Ensure "Show Original Sources" is checked.
(08) On the webpage, click the "Click me to start the test" button.  The page debugger will stop on the debugger keyword.
(09) Use the Step In command to move forward a few times, then close the debugger.
Expected results:  The HTML textarea of the webpage fills with a short list of prime numbers.

Attempt to debug a XUL remote application:
(10) firefox -app ./application.ini --no-remote -profile ./profile2 &
(11) In the Addons Manager window:
  *  Select the Extensions panel
  *  Open preferences for the Remote Debugger Extension
  *  Click the "Start Developer Tools Server" button twice.  (Ignore the lack of visible changes.)
  *  Close the preferences and Addons Manager windows.
(12) firefox --no-remote -profile ./profile1
  * Enable remote debugging in this session: https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/Debugging_Firefox_Desktop#Enable_remote_debugging
  * Tools > Web Developer > Connect...
  * Click the Connect button.
  * In the second Firefox instance, accept the incoming connection.
  * In the first Firefox instance, click on the "Main Process" link that appears.
  * A debugger window will appear.
(13) In the debugger window, select the debugger panel. Ensure "Show Original Sources" is checked.
(14) In the second Firefox instance (the "debuggee"), click the "Start test" button.
(15) In the debugger window, you should see you are stopped on the debugger keyword.  Click the "Step In" button.

Expected results:
You see the hitBreak button.  When you continue to step through, the script executes normally.  Clicking the Play button lets the script finish generating the short list of prime numbers.

Actual results:
Debugger and debuggee both become non-responsive.  Attempts to click the play button or the step-in button fail.  Even closing the debugger and debuggee windows does not quit the second Firefox instance.


The Remote Debugger Extension in the XUL app is based on https://addons.mozilla.org/en-US/thunderbird/addon/remote-developer-tools-server/ .  It has been repackaged for FF 38.

	Alex Vincent [:WeirdAl] Reporter
	Comment 2 • 9 years ago

[Tracking Requested - why for this release]:
Our company very badly needs debugging Coffee code, and we're trying to migrate to FF38 ESR.  It's impractical for us to upgrade our platform every six weeks.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 3 • 9 years ago

Does this affect other versions of Firefox -- from 39 onwards? It seems likely that it does.

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 4 • 9 years ago

Joe is this something your team can take a look at?

	Joe Walker [:jwalker]
	Comment 6 • 9 years ago

Thanks Liz, we'll work out where to fit this in.

	Alex Vincent [:WeirdAl] Reporter
	Comment 7 • 9 years ago

(In reply to Liz Henry (:lizzard) from comment #3)
> Does this affect other versions of Firefox -- from 39 onwards? It seems
> likely that it does.

FF39 beta, I cannot get the debugger to connect to the remote debuggee. So my results are inconclusive.

	Alex Vincent [:WeirdAl] Reporter
	Comment 8 • 9 years ago

Sorry, misspoke:  I can connect, but no source files show in up in the FF39 beta debugger.

	Joe Walker [:jwalker]
	Comment 9 • 9 years ago

I've taken a quick look, but don't have any concrete things to suggest yet, I'm afraid.
We're currently digging through a set of breakpoint issues and working on worker debugging as top priority, and my gut reaction is that XUL debugging isn't more important than those, which means we won't be quick getting this fixed, which isn't what you wanted to hear, I know. Sorry!

	Eddy Bruel [:ejpbruel]
	Comment 10 • 9 years ago

Worker debugging is currently blocked on reviews, so I have some time to look into this.

	Eddy Bruel [:ejpbruel]
	Comment 11 • 9 years ago

(In reply to Alex Vincent [:WeirdAl] from comment #1)
> Created attachment 8609593 [details]
> testcase (XUL application + HTML test page)
> 
> Setup:
> (01) Create an empty directory and cd to it.
> (02) Download bug1167725-test.tar.bz2 to that directory.
> (03) tar -xjvf bug1167725-test.tar.bz2
> (04) mkdir profile1 profile2
> 
> Verify HTML debugging still works:
> (05) firefox --no-remote -profile ./profile1 ./debugtest/index.html
> (06) In the Firefox instance, start a debugger for the webpage that loads.
> (07) Ensure "Show Original Sources" is checked.
> (08) On the webpage, click the "Click me to start the test" button.  The
> page debugger will stop on the debugger keyword.
> (09) Use the Step In command to move forward a few times, then close the
> debugger.
> Expected results:  The HTML textarea of the webpage fills with a short list
> of prime numbers.
> 
> Attempt to debug a XUL remote application:
> (10) firefox -app ./application.ini --no-remote -profile ./profile2 &
> (11) In the Addons Manager window:
>   *  Select the Extensions panel
>   *  Open preferences for the Remote Debugger Extension
>   *  Click the "Start Developer Tools Server" button twice.  (Ignore the
> lack of visible changes.)
>   *  Close the preferences and Addons Manager windows.
> (12) firefox --no-remote -profile ./profile1
>   * Enable remote debugging in this session:
> https://developer.mozilla.org/en-US/docs/Tools/Remote_Debugging/
> Debugging_Firefox_Desktop#Enable_remote_debugging
>   * Tools > Web Developer > Connect...
>   * Click the Connect button.
>   * In the second Firefox instance, accept the incoming connection.
>   * In the first Firefox instance, click on the "Main Process" link that
> appears.
>   * A debugger window will appear.
> (13) In the debugger window, select the debugger panel. Ensure "Show
> Original Sources" is checked.
> (14) In the second Firefox instance (the "debuggee"), click the "Start test"
> button.
> (15) In the debugger window, you should see you are stopped on the debugger
> keyword.  Click the "Step In" button.
> 
> Expected results:
> You see the hitBreak button.  When you continue to step through, the script
> executes normally.  Clicking the Play button lets the script finish
> generating the short list of prime numbers.
> 
> Actual results:
> Debugger and debuggee both become non-responsive.  Attempts to click the
> play button or the step-in button fail.  Even closing the debugger and
> debuggee windows does not quit the second Firefox instance.
> 
> 
> The Remote Debugger Extension in the XUL app is based on
> https://addons.mozilla.org/en-US/thunderbird/addon/remote-developer-tools-
> server/ .  It has been repackaged for FF 38.

While trying to reproduce this on the latest Nightly, I got stuck at step (11): the remote debugger server plugin could not be verified, and has therefore been disabled. How do I work around this?

	Alex Vincent [:WeirdAl] Reporter
	Comment 12 • 9 years ago

(In reply to Eddy Bruel [:ejpbruel] from comment #11)

> While trying to reproduce this on the latest Nightly, I got stuck at step
> (11): the remote debugger server plugin could not be verified, and has
> therefore been disabled. How do I work around this?

Your best bet is the attached jsdebugXPI script.  This script pulls the source code from comm-* (depending on the repo you specify) and quickly generates a new XPI based on what that repo has in its source code.  The --help option is supported, but not terribly helpful...

./jsdebugXPI central ./extensions/

Failing that, unpack ./extensions/remote-debugger@mozilla.org.xpi into a folder and update the install.rdf file's minimum and maximum version fields appropriately.  (Sometimes you have to do this, because jsdebugXPI uses the checked-in version number from mail/config/version.txt .)

	Eddy Bruel [:ejpbruel]
	Comment 13 • 9 years ago

For some reason, the "main process" link mentioned in step 12 does not appear for me. I tried this with a Nightly build (41.0). The original problem was reported for 38.0, so its possible that this is another regression.

Phillip, Alex tells me you are the person most knowledgeable about the remote debugger add-on. Do you know what code is responsible for showing the "main process" link, and why it does not seem to be working using the STR mentioned above?

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 14 • 9 years ago

(In reply to Eddy Bruel [:ejpbruel] from comment #13)
> For some reason, the "main process" link mentioned in step 12 does not
> appear for me. I tried this with a Nightly build (41.0). The original
> problem was reported for 38.0, so its possible that this is another
> regression.
> 
> Phillip, Alex tells me you are the person most knowledgeable about the
> remote debugger add-on. Do you know what code is responsible for showing the
> "main process" link, and why it does not seem to be working using the STR
> mentioned above?

There was an issue with the "main process" option not appearing on the Connect screen that was just fixed recently (bug 1170495).  If you have an older Nightly, it may not have the fix yet.

It seems it's been broken since 39.

WebIDE also offers a "main process" option that remained working during this time frame, so potentially you could use that instead.

	Philipp Kewisch [:Fallen] [:📆][:🧩]
	Comment 15 • 9 years ago

Yes, I need to release a new version of the addon for later gecko versions. I ported support for this in bug 1131997. In the meanwhile, you can either add the lines manually, or build it via comm-central. Leaving needinfo so I don't forget to update the addon.

	Alex Vincent [:WeirdAl] Reporter
	Comment 16 • 9 years ago

(In reply to Philipp Kewisch [:Fallen] from comment #15)
> Yes, I need to release a new version of the addon for later gecko versions.
> I ported support for this in bug 1131997. In the meanwhile, you can either
> add the lines manually, or build it via comm-central. Leaving needinfo so I
> don't forget to update the addon.

He's using the jsdebugXPI.py script I provided to you, Philipp, and that downloads tip.tar.bz2 from comm-central, so building comm-central shouldn't strictly be speaking necessary (unless something else has changed enough that the packaging script is no longer enough).

	Philipp Kewisch [:Fallen] [:📆][:🧩]
	Comment 17 • 9 years ago

Ah ok, I didn't read the remaining comments, sorry. If it works in webide but not on the connect page, then it must be a different issue. And if you are using the output of the jsDebugXPI script, then that should contain the ported fix for allowChromeProcess.

	Eddy Bruel [:ejpbruel]
	Comment 18 • 9 years ago

So, what you are saying is: I should already have the version of the add-on that contains the fix. Therefore, if it still doesn't work, it must be a different issue than what you thought it was?

It's not clear to me what I can do to move forward with this bug. I've tried repeating the STR on a recent fx-team, but that doesn't seem to make any difference. I can try it on top of a recent nightly, by jryans suggestion, but if that doesn't help either, I'm going to need some guidance here.

	Alex Vincent [:WeirdAl] Reporter
	Comment 19 • 9 years ago

Regarding the disappearance of the Main Process link at step 12:

mozregression helped me find this:
48:38.84 LOG: MainThread Bisector INFO Narrowed inbound regression window from [d20e1484, 43fb1f92] (3 revisions) to [1e4b7691, 43fb1f92] (2 revisions) (~1 steps left)
48:38.85 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :(
48:38.85 LOG: MainThread Bisector INFO Last good revision: 1e4b76918021
48:38.85 LOG: MainThread Bisector INFO First bad revision: 43fb1f92e8d4
48:38.85 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1e4b76918021&tochange=43fb1f92e8d4

this is with mozregression --bad-rev tip --good-rev FIREFOX_AURORA_38_BASE
and jsdebugXPI.py release extensions/ # and manually updating install.rdf to allow versions 38.0 to 41.* .

	Alex Vincent [:WeirdAl] Reporter
	Comment 20 • 9 years ago

Eddy, appparently the Main Process link is fixed in FF41 nightly builds.

	Philipp Kewisch [:Fallen] [:📆][:🧩]
	Comment 21 • 9 years ago

bug 1059308 is in the pushlog you linked, which is precisely the issue I fixed with bug 1131997. Sorry I haven't yet had a chance to test this, but I'm happy to hear it works in 41.

	Eddy Bruel [:ejpbruel]
	Comment 22 • 9 years ago

WeirdAl, I know you've been pinging me to cooperate you on this bug, but I've been preoccupied with other duties (mainly implementing worker debugging). Unfortunately, I will be on PTO for the next 2 months, starting tomorrow, so I don't think I'll be able to help you with this any time soon :-(

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 23 • 9 years ago

Let's track this and try to see if we can get this fixed for ESR38 release.

Joe, can you please help find an owner? Thanks!

	Joe Walker [:jwalker]
	Comment 24 • 9 years ago

(In reply to Ritu Kothari (:ritu) from comment #23)
> Let's track this and try to see if we can get this fixed for ESR38 release.
> 
> Joe, can you please help find an owner? Thanks!

Sorry, but I'm going to need some really good reason why we should prioritize over things like service-worker debugging, fixing the debugger UI, fixing important problems with interactions between XHR and breakpoints, etc.

So this is low priority until someone can explain why it's important. Thanks!

	Tom Tromey :tromey
	Comment 25 • 7 years ago

I don't think this is critical, marking accordingly.

However - the old debugger had some issues using source maps when debugging the browser itself,
eventually leading to source-mapping being force-disabled in this case; see bug 1225160.

The new debugger front end doesn't have these problems, so I wonder if this bug was fixed by
virtue of the new debugger landing.

	Alex Vincent [:WeirdAl] Reporter
	Comment 26 • 7 years ago

I think it's gone, yes.  I certainly haven't observed it in the past few months  (Sorry for the long delay in responding.  I've  been absolutely swamped with work and study!)