913519 - Parallel parsing regressed SyntaxError output for XUL files

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Tom S]

This is very annoying, since recently (Bug 898811) we logged parsing errors for xul files in the console. Without this they can be very hard to find.

Comment 1

[Brian Hackett [Laid off!]]

I included a fix which should take care of this in the patch for bug 912719.

Comment 2

[Frank Wein [:mcsmurf]]

So just to get this right: Is this bug here about JS parsing/syntax errors being not displayed for everything JS-related that's triggered by a XUL file? As an example from some SeaMonkey code I made I syntax mistake in: I get this error in Error console
Error: FullZoom is not defined
Source File: chrome://navigator/content/nsBrowserStatusHandler.js
Line: 343

as I made a syntax mistake in the file viewZoomOverlay.js which defines FullZoom. nsBrowserStatusHandler.js gets loaded in a <script> tag in a .xul file. In trunk builds I get no syntax error for the viewZoomOverlay.js file itself (this used to work fine a few weeks ago). So does this issue belong to this bug here? Then probably the "regression" keyword should be added.

Comment 3

[Frank Wein [:mcsmurf]]

I forgot: viewZoomOverlay.js gets loaded via viewZoomOverlay.xul via <xul-overlay> tag in navigatorOverlay.xul via <xul-overlay> tag in navigator.xul.

Comment 4

[Frank Wein [:mcsmurf]]

Additional info: When setting the javascript.options.parallel_parsing pref to false, a syntax error appears once in the Error Console before the four FullZoom errors in my case (the event handler inside nsBrowserStatusHandler.js gets called multiple times due to tab restore I think).

Comment 5

[:Gijs (he/him)]

This is still broken, and it's really annoying. Brian, any idea what's needed to fix this?

Comment 6

[Brian Hackett [Laid off!]]

This should have been fixed by the patch in bug 921171, can you retry with a current nightly?  I think the problem was that the syntax error was not immediately reported but we ended up with a dangling exception that was reported by whatever JS ran next, unless that JS 'caught' the exception or reported a different exception.  Sorry for not noticing comment 4.

Comment 7

[:Gijs (he/him)]

This seems to be fixed now, indeed. Thanks!