source mapping incoherency caused by "Syntax tree visitor" uncaught exception: TypeError: this[aNode.right.type] is not a function

[RodMcGuire]

I have some local code that goes into infinite recursion. When I try to point the Firefox debugger to the problem file the mapping from breakpoints to source is badly screw up.

Only by looking in the "Browser Console" (not "Web Console") do I find the message:

"Syntax tree visitor for file:///C... threw an exception: TypeError: his[aNode.right.type] is not a function

with a long stack report.

When I load the files into the Chrome browser the debugging mapping is fine (though it takes much longer to decide I've reached the recursion limit.)

Does this problem ring any bells? I think I may have gotten around it in the past by rearranging the order of things in a file. A Google search on "Syntax tree visitor" only turns up a few complaints that nobody has responded to.

I'm hoping that I don't have to reduce ~3000 lines of (junky) code down to a simple test case.

[Jaroslav Šnajdr]

On Wednesday, April 20, 2016 at 1:38:56 PM UTC+2, RodMcGuire wrote:
> Only by looking in the "Browser Console" (not "Web Console") do I find the message:
>
> "Syntax tree visitor for file:///C... threw an exception: TypeError: his[aNode.right.type] is not a function

Hello Rod, you've most likely ran into bug 1260756 or 890913 - the syntax tree visitor in the source editor fails when processing some ES6 constructs - spread expressions, template literals, function default arguments... These bugs have been fixed in Nightly approx 2 weeks ago. Please try out the Nightly build and let me know if it still happens. If it still does, the most likely culprit is some other ES6 feature used in your code.

Jarda

[RodMcGuire]

On Thursday, April 21, 2016 at 5:16:32 AM UTC-4, Jaroslav Šnajdr wrote:
> try out the Nightly build and let me know if it still happens.

Many Thanks

I installed Windows 32-bit (Standard) Firefox Nightly: 48.0a1 (2016-04-21) and the debugger seems to have regained its sanity.

(UGH: Why do I have to put a "-no-remote" in the Windows target property for the Nightly icon in order to run it simultaneously with Stable while I don't have to for Developer?)

[RodMcGuire]

On Thursday, April 21, 2016 at 5:16:32 AM UTC-4, Jaroslav Šnajdr wrote:

> ... try out the Nightly build and let me know if it still happens.

Many Thanks

I installed Windows 32-bit (Standard) Firefox Nightly: 48.0a1 (2016-04-21) and the debugger seems to have regained its sanity.

(UGH: Why do I have to put a "-no-remote" in the Windows target property for the Nightly icon in order to run it simultaneously with Stable while I don't have to for Developer?)