324142 - [FIX]Chrome javascript syntax errors not shown in javascript console

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Dave Townsend [:mossop]]

Certain errors in chrome JavaScript files are no longer shown in the JavaScript console. These errors are the kind that basically makes the whole JavaScript file unusable because of syntax errors.

An example of an error that causes this is:

function badfunction(var badargument)
{
}

I will attach a testcase that demonstrates the problem.

Comment 1

[Dave Townsend [:mossop]]

Attachment: Extension that should show an error.

Web pages work as expected, this error only exists for chrome scripts (making extension development quite a challenge).

This extensions simply adds an overlay to the main browser that loads a bad script. Firefox 1.5 shows the following error in the JavaScript console:

Error: missing formal parameter
Source File: chrome://test/content/browser.js
Line: 45, Column: 25
Source Code:
function broken_function(var badargument)

Current trunk builds show no error in the console. The regression occured between the nightly of 28th Nov and 29th Nov, which is the following checkins:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-11-28+05%3A00&maxdate=2005-11-29+05%3A30&cvsroot=%2Fcvsroot

Comment 2

[Dave Townsend [:mossop]]

Blake, bug 317476 and bug 317533 are the only JavaScript checkins I can see in this range, can you shed any light here?

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Neither of those should have affected reporting of errors (except those reported through JS_ReportError, and then only for the better). I think I blame another checkin, though I haven't verified this at all.

Comment 4

[gekacheka]

Maybe this should be in a Core component... This is also happening in other apps (Thunderbird, Sunbird), so it is not specific to Firefox.  It's pretty frustrating.  

The only clue may be an error that just says "xxx is not defined" for some function xxx, such as onLoad --- a syntax error anywhere in a javascript file prevented the whole file from being evaluated.

(Has anyone found workarounds for diagnosing the syntax error once you guess that one exists?  My current diagnosis technique is to paste the whole file into Javascript Shell, which tells me if there is a syntax error but not where it is, so I have to do binary search pasting parts of the file to localize it.)

Comment 5

[Dave Townsend [:mossop]]

My current workaround involves opening the same extension in Firefox 1.5 and looking in the javascript console. Hardly efficient

Comment 6

[Arend van Beelen jr.]

I can confirm this bug in the XULRunner nightly of 2006/05/15. Very annoying when trying to develop a XULRunner app as well (especially as it's no extension and the code is less easy to try in Firefox).

Comment 7

[Jesse Ruderman]

Related to bug 344335?

Comment 8

[Jason Barnabe (np)]

This is the probably the same as bug 344335 - the only difference is that this bug says it's being chrome that causes the problem while that one says it's being XUL that causes the problem (and includes a content XUL testcase to prove it).

Comment 9

[Brendan Eich [:brendan]]

*** Bug 344335 has been marked as a duplicate of this bug. ***

Comment 10

[Brendan Eich [:brendan]]

Is this trunk only, or is the 1.8 branch regressed too?

/be

Comment 11

[Dave Townsend [:mossop]]

(In reply to comment #10)
> Is this trunk only, or is the 1.8 branch regressed too?

Appears to be trunk only. The testcase from this and bug 344335 correctly show errors in a current Firefox 2b2 build.

Comment 12

[Brian Crowder]

I think the interesting change in this regression range is in nsJSEnvironment.cpp which now tries to use a win, instead of the global object.  Is it possible we should fall back on using the global object if no win is available (or fallback on printf or SOMETHING)?

Adding jst to cc:

Comment 13

[Ben Bucksch (:BenB)]

FWIW, I don't see them on the (shell) console in opt either, but in debug builds.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: Crowder is spot-on. This should fix it.

Comment 15

[Boris Zbarsky [:bzbarsky]]

And yeah, this is a regression from bug 316794.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Attachment: Same as diff -w

Basically, in this case the global is a XUL proto global.  So it's not at all a window, but it's a perfectly fine global object we can use for everything except the onerror event.

Comment 17

[Ben Bucksch (:BenB)]

This fixes it for me. Thanks!

before patch:
  debug:
    shell console: yes
    JS console: no
  opt:
    shell console: no
    JS console: no (!)
after patch:
  opt:
    shell console: no
    JS console: yes (!)
  debug:
    shell console: yes
    JS console: yes


Nice would be to also output it on shell console in opt when dump is enabled - I'd assume it would be there: if I get all my own debug crap, I surely want to know about JS syntax errors there, and I don't have the JS console open always. But that may be controversial, I don't know.

Comment 18

[Brian Crowder]

Handing off to bz, since he coded the patch.  Feel free to toss it back if you'd like me to land it or handle nits, etc.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Fixed.