User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030114 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030114 Composition window is broken. When clicking on compose button (or reply button), the """good old error message""" appears : "An error occured while creating a compose message window. Please try again. [" Errors in JS console : Error: redeclaration of const XUL_NS Source File: chrome://editor/content/editorUtilities.js Line: 1 Error: redeclaration of const MOZ_HELP_URI Source File: chrome://help/content/contextHelp.js Line: 1 Reproducible: Always Steps to Reproduce: 1.Grab a source and CVS patches 2.build mozilla 3.try to open a composition window. Actual Results: Composition window is - again ! - broken :-/ Expected Results: Opening a composition window. I cannot remember previous bug number for this bug. Sorry :-/

fails on Linux too

Backed out aaronl's checkins dated 01/13/2003 20:03 in bonsai, and all works then. Added comment in bug 176296.

Linux trunk 2003011405 has the bug -> smoketest kw.

taking, since I can reproduce this. cc aaronl, since R.K.Aa thinks it was his checkin.

FWIW, XUL_NS is defined as a const in /editor/ui/composer/content/editorUtilities.js, line 27 and a var in /profile/pref-migrator/resources/content/no_space.js, line 39

here's the exception that causes the error EX: = [Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE ) [nsISupports.QueryInterface]" nsresult: "0x80004002 (NS_NOINTERFACE)" locati on: "JS frame :: chrome://editor/content/ComposerCommands.js :: GetComposerComma ndManager :: line 232" data: no]

Seth, what did I do to cause this bug? I admit, I see the assertion in my console, but it still creates the compose window. How does your "hack" patch fix it, is it the right fix?

Can i get some status on this? Seth, if this is the best you think we're going to get for a while, let me know so i can spin some test builds. If you want to work on a fix longer, fine. Aaron, your build is able to open compose windows? Is your tree current?

Leaf, my tree is a couple of days old, except that I also have my patches built into it, which were just checked in last night. The changes I made to mailnews in bug 176296 were extremely minimal -- I added an attribute autofind="false" in 3 places that used the <browser> tag. I didn't touch mail compose or the editor.

I'm not convinced this is caused by my checkin. I still get the XUL_NS assertion in the js console when I back out all my changes I think the XUL_NS has nothing to do with the bug, or my checkin.

After i saw this fail i clobbered and rebuilt - with the same erronous result. I then backed out like this: cvs update -j3.438 -j3.437 mozilla/modules/libpref/src/init/all.js cvs update -j1.26 -j1.25 mozilla/extensions/typeaheadfind/src/nsTypeAheadFind.h cvs update -j1.49 -j1.48 mozilla/extensions/typeaheadfind/src/nsTypeAheadFind.cpp cvs update -j1.4 -j1.3 mozilla/extensions/typeaheadfind/src/Makefile.in cvs update -j1.6 -j1.5 mozilla/extensions/typeaheadfind/resources/locale/en-US/typeaheadfind.properties cvs update -j1.243 -j1.242 mozilla/mailnews/base/resources/content/messenger.xul cvs update -j1.67 -j1.66 mozilla/mailnews/base/resources/content/messageWindow.xul cvs update -j1.92 -j1.91 mozilla/mailnews/base/resources/content/mail3PaneWindowVertLayout.xul cvs update -j1.20 -j1.19 mozilla/content/xbl/builtin/htmlBindings.xml And after a rebuild, mail-compose then again worked. I then deleted all those files and updated to current CVS again - and mail-compose failed yet again. In between the builds I deleted compreg.dat and XUL.mfasl, to avoid possible sources of error there. Using modern theme. Note that current trunk build (Linux) also fails. This shouldn't be too hard to reproduce.

over to aaronl. his plan is to impl nsIInterfaceRequestor and ::GetInterface for the controller he recently added.

I also think that the XUL_NS message is not related to this. However, it is a problem so I'm going to file a new bug on XUL_NS.

Will anyone be able to test a patch if I put one up? I'm not experiencing the error, but I think I know how to fix it.

Needs testing, not sure if it works -- can't test on my machine yet.

no change with patch in attachment 111527 [details] [diff] [review]. Same error msg appears, no compose window.

Comment on attachment 111527 [details] [diff] [review] Support nsIInterfaceRequestor on nsTypeAheadController, have it return null for nsIControllerCommandManager Didn't fix the problem

built with attachment 111540 [details] [diff] [review]: things got back to normal: Mailcompose opens OK.

r/sr=sfraser for the backout.

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

respun with the commented-out code. opening tree.

Official trunk Linux 2003011412 is OK again. Any reason this is not resolved as fixed?

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

fixed, since aaronl checked in his backout.

Using trunk commercial builds 20030115 on mac osx, linux and winxp the Compose window is working OK. verified.

Neil, can I reverse the partial backout now that you fixed bug 189310? That was the problem causing this, right?