65179 - JS exceptions not flushed to console

Status: NEW

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

Description

[[e-mail]]

If you redirect Mozilla's output then JS exceptions are buffered.
They could get completely lost if Mozilla crashes.

Comment 1

[Mike McCabe]

Can you give an example of the kind of exception you want to have flushed?  I'll
put in an #ifdef DEBUG fflush there.

I almost marked this WONTFIX; JS exceptions going to the console is something
I'd like to see go away altogether.  Certainly for content JavaScript, though it
might be justifiable for the XUL JavaScript that makes up the browser.

Comment 2

[[e-mail]]

Yes, it was exceptions that happen in XUL/XBL that I was thinking of.
I was using a Windows "tee" program to capture Mozilla output.
(I don't think Windows has "script" or I would have used it.)
I was trying to write some chrome and wondering why my script didn't work.
I ended up resorting to the following code:
try {
	// some code that doesn't work for some reason
} catch (e) {
	dump(e);
}
This way I was able to see and log exceptions at the time they happened.

Comment 3

[Mike McCabe]

I checked in an fflush to nsJSEnvironment.cpp:189 after the print, #ifdef
DEBUG.  You'll still see the old behavior with non-DEBUG (distribution) builds. 
Marking FIXED; thanks for the suggestion.

Comment 4

[Phil Schwartau]

Neil, if this works OK for you now, could you mark this bug "Verified"? 
Thanks -

Comment 5

[kurros (Wade Majors)]

McCabes check-in broke the BeOS porthttp://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Ports/979696920.15348.gz

Comment 6

[Mike McCabe]

Did my subsequent checkin fix it?  My first was missing a semicolon.

Comment 7

[kurros (Wade Majors)]

oops, sorry. looks like we're green now :)

Comment 8

[[e-mail]]

Sorry, I don't use the debug build so could you remove the #ifdef DEBUG? Thanks.

Comment 9

[Mike McCabe]

Not until somebody can assure me that there are no performance consequences! 
You're aware of the js console, right?

cc'ing jband, in case he can cast light.

Comment 10

[[e-mail]]

I'm trying to log exceptions to a file, but they all appear at the end,
after other output e.g. dump (assuming Mozilla doesn't crash first).

Comment 11

[Mike McCabe]

It's quite likely you're seeing the difference between stderr and stdout; the
tee program may treat them differently (I've seen it before...)

Also, it may have something to do with the fact you're not running a debug
version.

Comment 12

[[e-mail]]

This is the relevant code from the tee program (Win32 API):
CreatePipe(&hReadPipe, &si.hStdError, &sa, 0)
si.hStdOutput = si.hStdError; // redirect child process stdout and stderr
CreateProcess(NULL, lpszCmdLine, NULL, NULL, TRUE, NORMAL_PRIORITY_CLASS, NULL,
NULL, &si, &pi);

Comment 13

[Phil Schwartau]

Reassigning Mike's JS Engine bugs to Patrick, as per recent meeting - 

Comment 14

[Patrick C. Beard]

This is really a problem of Mozilla's embedding of the JS engine. Given that end 
users won't find these exception messages useful, I don't agree that they should 
be printed when DEBUG isn't defined. This bug should probably be reassigned to 
the DOM component.

Comment 15

[Phil Schwartau]

Per above comment, reassigning to DOM component for disposition - 

Comment 16

[[e-mail]]

I don't mind if they are printed or not as long as they are flushed when printed.

Comment 17

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 18

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.