Chrome scripts silently fail to load with when they contain syntax errors

VERIFIED FIXED in mozilla0.9.1



18 years ago
8 years ago


(Reporter: bugzilla, Assigned: sfraser_bugs)


({regression, smoketest})

Windows 2000
regression, smoketest

Firefox Tracking Flags

(Not tracked)




18 years ago
Scripts referenced from chrome are failing to load.  I saw this in one case and 
so did Boris, and Doron saw it another.  This is blocking a lot of work.  
Trying to narrow it down now.

Comment 1

18 years ago
To clarify, it's just some scripts.  We haven't figured out the pattern yet.
Summary: Scripts are failing to load → Some scripts are failing to load


18 years ago
Keywords: smoketest

Comment 2

18 years ago
here is what I see (cvs pull from yesterday):

I load 2 .js (navigator.js and viewsource.js) files in a .xul. However, only the
first one seems to be actually loaded, as calling functions from the 2nd one did
nothing. Changing the order had the effect that only functions in the first one
were accesible.

bz was unable to see this with the same .xul, which leads me to think that my
hacked viewsource.js is at fault. Working on a simplified testcase. 
Keywords: regression
Just to rule out bug 74883, now fixed, could you guys who have builds update
js/src/jsdhash.c and xpcom/ds/pldhash.c, and rebuild incrementally (if you have
good dependencies)?

BTW, I'd expect crashes from 74883, not this -- so I'm pretty sure it won't help
but I wanted to mention it.


Comment 5

18 years ago
brendan/hyatt don't see this.  go clobber, marking critical
to get off blocker list.
Severity: blocker → critical

Comment 6

18 years ago
Blake, did you see this with today's release build?
(2001-05-16-10-trunk or 2001-05-16-12-trunk)
I've narrowed it down to a syntax error in the script that blake was seeing it
on (missing comma between items in the prototype section).  So what I'm seeing
is this:

If there's a syntax error in a script, the script fails to load, no code in it
is executed (I had an alert() at the very beginning) and there is nothing in the
JS console to indicate what's wrong.
Severity: critical → blocker
oops.  setting back to critical.
Severity: blocker → critical

Comment 9

18 years ago
Why would "clobber and try again" be a likely solution when three different 
people are seeing the problem?  I think this should be a blocker again because 
it's a major problem and is probably causing many other bugs.
Summary: Some scripts are failing to load → Scripts fail to load when they contain syntax errors

Comment 10

18 years ago
Upgrading this to blocker again because this is causing or probably will cause 
other bugs that we shouldn't waste time tracking down.   Aside from the fact 
that js errors are no longer output to the console, the js errors in the 
problematic file(s) aren't even reported by the jseng, nor is there any 
indication that they are failing to load.  So there's no easy way to tell when 
this bug is biting you.
Severity: critical → blocker

Comment 11

18 years ago
Ok, talked to the sheriff, we'll re-evaluate this before tree opening tomorrow 
in light of verifications.
Severity: blocker → critical
I'm sorry, but this is not a bug, this is just the way script loading works, and
always has worked, and always will work. The same issue exists when webpages
load script files, if the file contains *syntax* errors, the file is not loaded
and *no* part of the script is executed, this is how all browsers work, AFAIK
(verified in Mozilla and IE).

Last Resolved: 18 years ago
Resolution: --- → FIXED
er, no, not fixed.
Resolution: FIXED → ---
Last Resolved: 18 years ago18 years ago
Resolution: --- → INVALID
Johnny, the issue here is not that the scripts fail to load.  That's fine.  The 
problem is that the JS console contains no indication of the failure (for web 
content it shows the syntax error and the line the error occured on, for chrome 
it does not).

This leads to mysterious failures in loading chrome scripts and makes such 
failures very hard too debug.  Some error reporting would be immensely helpful.

Reopening and adjusting summary to reflect the real problem.
Resolution: INVALID → ---
Summary: Scripts fail to load when they contain syntax errors → Chrome scripts silently fail to load with when they contain syntax errors

Comment 16

18 years ago
This is killing me right now...

Comment 17

18 years ago
I'm seeing silent failure on script compilation; there is no error reporter set 
on script context that the nsXULDocument is using.

Comment 18

18 years ago
The XPCDOM landing broke this.

nsJSContext::InitContext() is bailing at the if (!aGlobalObject) clause, so we 
never get down to the code that sets the error reporter.

Comment 19

18 years ago

Index: mozilla/dom/src/base/nsJSEnvironment.cpp
RCS file: /cvsroot/mozilla/dom/src/base/nsJSEnvironment.cpp,v
retrieving revision 1.137
diff -b -u -2 -r1.137 nsJSEnvironment.cpp
--- nsJSEnvironment.cpp	2001/05/15 22:26:18	1.137
+++ nsJSEnvironment.cpp	2001/05/18 02:29:01
@@ -1031,4 +1031,6 @@
+  ::JS_SetErrorReporter(mContext, NS_ScriptErrorReporter);
   if (!aGlobalObject) {
     // If we don't get a global object then there's nothing more to do here.
@@ -1065,6 +1067,4 @@
   rv = InitClasses(); // this will complete global object initialization
-  ::JS_SetErrorReporter(mContext, NS_ScriptErrorReporter);
   mIsInitialized = PR_TRUE;

This allows me to find JS errors again. Not sure if it's totally correct (there 
is some other stuff at the bottom of Init() that looks like it should happen if 
aGlobalObject is NULL.


18 years ago
Keywords: nsbeta1

Comment 20

18 years ago
this bug just bit me, I've changed my mind, this is now a blocker.
Severity: critical → blocker
Thanks for the patch, Simon, and I'm sorry for not realizing that this really
was a problem earlier, fix checked in (and yes, the fix is good).
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.1


17 years ago
QA Contact: lchiang → stummala

Comment 22

17 years ago
marking verified based on Johnny's comments.
Assignee: jst → sfraser_bugs
Component: DOM: Abstract Schemas → DOM
You need to log in before you can comment on or make changes to this bug.