tested on linux and win32 builds from 11/26/99 launching mozilla.exe with no existing profile brings up a profile manager. hitting the "Next" button does not bring up the next dialog. the console says: "JavaScript Error: ReferenceError: onNext is not defined" this prevents users without prior profiles from using and testing mozilla.

This happens on Mac OS as well.

marking blocker.

Patrick tried changing the deferCompile argument passed to AddScriptEventListener to false in all cases, and that abated the bug symptom. I'm reviewing vidur's changes, giving this bug to him in the mean time in case he's around this weekend. /be

Here's the workaround patch: Index: mozilla/rdf/content/src/nsXULElement.cpp =================================================================== RCS file: /cvsroot/mozilla/rdf/content/src/nsXULElement.cpp,v retrieving revision 1.165 diff -r1.165 nsXULElement.cpp 1326c1326 < rv = manager->AddScriptEventListener(context, this, aName, aValue, aIID, PR_TRUE); --- > rv = manager->AddScriptEventListener(context, this, aName, aValue, aIID, PR_FALSE);

what's the status on this bug? Do we have a fix? Are we close? As a blocker, this will keep the tree closed until we know we have a handle on it.

More info that might track this down: the line of JavaScript that "causes" the problem is, from "createProfileWizard.js": backButton = document.getElementById("back"); and the analogous line for the Next button. To put it another way, if you add the statement: document.getElementById("cancel"); to SetButtons(), you can disable the Cancel button in an analogous manner.

Turns out a latent bug, dynamic scoping via the script-context's global object instead of the xul-document's parent in nsXULElement::GetScriptObject, combined with vidur's fine lazy event handler compilation to bite the profile wizard. Waterson, vidur: should XUL element JS objects be parented (scoped) by their window, or that window's document? I thot HTML element objects were scoped by document. If so, the fix is even easier than the one waterson and I were just discussing on the phone (getting the XUL doc's window): just use the XUL doc's JS object. /be

Brendan's on the right track. XUL elements weren't being scoped correctly - their JS parent was set to the global object of the calling context (which changed when script compilation was defered). The patch below sets it up so that XUL elements are parented by their document and the document by its containing window (similar to layout elements and document). Waterson, could you review and send me mail to check in? Index: nsXULDocument.cpp =================================================================== RCS file: /cvsroot/mozilla/rdf/content/src/nsXULDocument.cpp,v retrieving revision 1.204 diff -r1.204 nsXULDocument.cpp 3051c3051 < nsIScriptGlobalObject *global = aContext->GetGlobalObject(); --- > nsCOMPtr<nsIScriptGlobalObject> global; 3054c3054,3082 < res = NS_NewScriptXULDocument(aContext, NS_STATIC_CAST(nsISupports *, NS_STATIC_CAST(nsIDOMXULDocument *, this)), global, (void**)&mScriptObject); --- > // XXX We make the (possibly erroneous) assumption that the first > // presentation shell represents the "primary view" of the document > // and that the JS parent chain should incorporate just that view. > // This is done for lack of a better model when we have multiple > // views. > nsIPresShell* shell = (nsIPresShell*) mPresShells.ElementAt(0); > if (shell) { > nsCOMPtr<nsIPresContext> cx; > shell->GetPresContext(getter_AddRefs(cx)); > nsCOMPtr<nsISupports> container; > > res = cx->GetContainer(getter_AddRefs(container)); > if (NS_SUCCEEDED(res) && container) { > nsCOMPtr<nsIScriptContextOwner> sco = do_QueryInterface(contai ner); > if (sco) { > res = sco->GetScriptGlobalObject(getter_AddRefs(global)); > } > } > } > // XXX If we can't find a view, parent to the calling context's > // global object. This may not be right either, but we need > // something. > else { > global = getter_AddRefs(aContext->GetGlobalObject()); > } > > if (NS_SUCCEEDED(res)) { > res = NS_NewScriptXULDocument(aContext, NS_STATIC_CAST(nsISupports *, NS_STATIC_CAST(nsIDOMXULDocument *, this)), global, (void**)&mScriptObject); > } 3056d3083 < *aScriptObject = mScriptObject; 3058c3085,3086 < NS_RELEASE(global); --- > *aScriptObject = mScriptObject; > Index: nsXULElement.cpp =================================================================== RCS file: /cvsroot/mozilla/rdf/content/src/nsXULElement.cpp,v retrieving revision 1.165 diff -r1.165 nsXULElement.cpp 1446,1447d1445 < nsIScriptGlobalObject *global = aContext->GetGlobalObject(); < 1460,1462c1458 < rv = fn(aContext, (nsIDOMXULElement*) this, global, (void**) &mScriptO bject); < < NS_RELEASE(global); --- > rv = fn(aContext, (nsIDOMXULElement*) this, mDocument, (void**) &mScri ptObject);

ok, i'm testing the fix we discussed. I ensure that an nsXULElement uses its nsXULDocument's global object as the parent, and that nsXULDocument uses its mScriptContextOwner (should be its window) as the parent.

Vidur: do you really need to grovel through view instead of model to find the widow? I think XULDocument knows all, in this case, and the window is part of the model, as well as partly first among N views. Don't imbibe too much of that w3c model/views hootch! Waterson: "its nsXULDocument's global object as the parent" -- shouldn't that be "script object" rather than "global object"? be

I had to go through the view for (layout's) nsDocument. Didn't realize that nsXULDocument already had a reference to a nsIScriptContextOwner. Good thing waterson's buddying.

brendan, vidur: could you take a quick look at the proposed fix and give me an "r="? thanks...

oops, looks like brendan & vidur weren't cc-ed on that one. brendan, vidur: could you r= my proposed fix? thanks.

I think waterson's patch to nsXULDocument.cpp and vidur's patch to nsXULElement are the right pair of patches: waterson's cuz he gets the xul doc's one true script-global-object (i.e., its window object), and vidur's cuz he scopes each xul element by its document, not the doc's window. /be

Waterson: looks good, Tag change at bottom looked good before (shoulda said so last time; sorry). If all is well with the profile wizard, go for it! /be

fix checked in.

put on pdt+ radar...though fixed :-)

Verified, watched it work under the debugger. /be

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

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

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

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

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

Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.