Starting with the DOM component, but cc'ing brendan just in case it's really a JS engine issue. Maybe this has something to do with the window.arguments object conflicting with the core arguments object. (Isn't window.arguments an IEism?) Problem: core JavaScript arguments object is not defined for js functions embedded in XUL. To reproduce: 1) save arguments.xul on your disk 2) load it in Mozilla The following message will be displayed on the console: "JavaScript Error: ReferenceError: arguments is not defined URL: file:///home/rginda/src/HTML/moztests/arguments.xul LineNo: 9" This is a Bad Thing. To compare, load arguments.html instead. You should see: "bar: arguments: [object Arguments]" on the console. This is what is expected.

Just noting that this same bug blows up the new profile wizard (for 1999121708 WinNT). See bug #22080

This is a brutal sharing bug -- should it be fixed for M12? What XUL in M12 actually needs the arguments object? /be

If I'm awake enough, I read the other bug 22080 as a dup of this, and also not an M12 stopper (cuz the new profile wizard code didn't go into M12). Someone check my sleepy sanity here. I'll fix this tomorrow. Sorry about the regression. /be

This affects beng's profile manager ( bug 22080 ), so I'd guess it's M12 material.

This seems to make any parameter passed into the function undefined as well (not just the arguments object.) I would say this is DEFINATELY M12 material. I see this in some chatzilla routines as well. I assume it must show up elsewhere.

brendan: sorry, I misread your last comment, and didn't realize the new profile manager wasn't in M12, but this does seem to be more than just a profile manager issue. I'd bet there are other bugs that are as-yet-unknown dups of this. For example, 22048.

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

rginda: do you mean function arguments appear to be undefined in all XUL, or only in XUL for those functions that refer to the arguments object? /be

See bug 22117 which is related to this problem. The cookie viewer just stopped working because of the arguments array being undefined. I assumed that somebody intentionally removed arguments from the javascript interpreter in the past few days because it is marked as a deprecated function in the javascript reference manaual. Therefore I solved the cookie viewer problem by changing the javascript code of the cookie viewer. But my fix was on the tip, not the M12 build. So if this bug is also breaking the cookie viewer on the M12 branch (I don't have a build of the branch to test it), I would like to cast my vote for fixing this bug on the M12 branch.

yeah. I have an update for the Profile Wizard as well that sidesteps the insanity at the script level. Like cookieviewer, if this is broken on the M12 branch, it's probably worth me checking the fix into both.

brendan: I had thought it affected arguments in all xul functions, but this doesn't seem to be the case. But there is certainly more broken than just the arguments object. Adding the following lines to the foo() function in arguments.xul dump ("instanceof regexp: " + (/some regexp/ instanceof RegExp) + "\n"); dump(/some regexp/ + "\n"); results in instanceof regexp: false JavaScript Error: TypeError: can't convert RegExp to string URL: file:///home/rginda/src/moztests/arguments.xul LineNo: 10 This seems to be what broke chatzilla in bug 22048. Also, "dump(/some regexp/);" (without the + "\n") produces no output. All of this works in an HTML file and the shell. Is it really just a coincidence that these two things broke at the same time, or are they related? On your say-so I'll file a new bug for the regexp issue, and repoen 22048.

The RegExp instanceof test is failing because the proto for the RegExp is set to null. In fact, the global object that exists at compilation time doesn't have constructors for RegExp Or Object, which is a little sad.

Waterson and shaver fixed memory leak bugs by compiling XUL scripts against a pretty-blank object (owned by the XUL document). I assured them that the JS compiler does not side-effect that object at compile time, which is true, but I forgot that it does expect the standard RegExp class constructor to be defined there, because the compiler creates RegExp objects. Couple of thoughts: 1. Call JS_InitStandardClasses(cx) in the XUL code that makes this "prototype global" object against which XUL scripts are compiled. 2. Change JS so the compiler never constructs RegExp instances for /re/ literals -- instead it emits prolog bytecodes to define these using the runtime RegExp constructor binding. ECMA ed 3. may in fact require this -- rogerl and waldemar please comment. /be

Section 7.8.5 says: "A regular expression literal is an input element that is converted to a RegExp object (section 15.10) when it is scanned. The object is created before evaluation of the containing program or function begins. Evaluation of the literal produces a reference to that object; it does not create a new object." I think that implies option 1. is the right path.

Rob, can you verify that this bug and 22048 are both fixed, either already, or by the same (attached) patch? Thanks, /be

Patch fixes both bugs. (They weren't fixed already.)

Fixed in rdf/content/src/nsXULPrototypeDocument.cpp. /be

Robert do you want to verify this one ?

verified fix.