102710 - Cannot compose new message - Unhandled Exception nsIMsgComposeService.OpenComposeWindow

Status: VERIFIED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[WD]

BuildID:    2001100203

The buttons for composing a new message, reply, forward, etc... all do nothing.

Reproducible: Always
Steps to Reproduce:
1.Go to MailNews
2.Click the New Msg button
3.

Actual Results:  Nothing happens

Expected Results:  New Message window comes up.

Javascript Console shows:

Error: uncaught exception: [Exception... "Not enough arguments
[nsIMsgComposeService.OpenComposeWindow]"  nsresult: "0x80570001
(NS_ERROR_XPC_NOT_ENOUGH_ARGS)"  location: "JS frame ::
chrome://messenger/content/mailCommands.js :: ComposeMessage :: line 186"  data: no]

Comment 1

[(not reading, please use [e-mail] instead)]

this sounds like me, since I recently changed that interface.

but this is working for me in a 20011002 build.  I'll investigate.

Comment 2

[(not reading, please use [e-mail] instead)]

I see this too in my win2k build at work (I checked in from home)

I'm nervous that I didn't check in my whole patch or something.

investigating.

twalker, do you see this?

Comment 3

[Tracy Walker [:tracy]]

I did not see this with todays smoketests.  However my windows machine is win98.

Comment 4

[(not reading, please use [e-mail] instead)]

I clobbered and rebuilt mozilla/mailnews and it went away.

I'm not sure what was wrong.

reporter, was this your own build or a build from ftp.mozilla.org?

Comment 5

[WD]

It is this build:
ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-10-02-06-trunk/mozilla-win32-talkback.zip

Comment 6

[(not reading, please use [e-mail] instead)]

if I touch mailCommands.js / .xul, and rebuild chrome, it works.

but if I rebuild again, sometimes it fails the next time I run!  this sucks.

Comment 7

[John Bandhauer]

reporter: did you unzip over a previous installation or into a fresh directory?

sspitzer: Do you have any additional clues beyond randomness? It the interface 
changed then a controlling factor is the interface info that is read from the 
xpt files. If the interface info got *moved* from one xpt file to another then 
you can get some really ugly things to happen if the old file is still in your 
tree. Or, does this look more like a problem with using out of date js code? 
Could cached compiled JS code be a factor?

Comment 8

[WD]

Initially I did unzip it over a previous installation, but I figured that may
have been the cause of the trouble.   So I deleted the directory totally and
unzipped it again.  Same problem.

Comment 9

[WD]

Note:   Deleting my XUL.mfl file fixed the problem!

Comment 10

[John Bandhauer]

brendan: fastload not detecting changed js files in jars even after 
whacking and installing a new version of the software?

Comment 11

[WD]

Also, I did not notice this problem on my home machine.  (Win98SE)
Is it possible that because I originally unzipped the mozilla zipfile overtop of
a pre-existing installation, this created a problem?  (I believe it was the
latest branch build which I overwrote directly with the latest trunk)

Since I have XUL cacheing enabled, this picked up and cached the problem state?
  So even after that when I totally deleted the mozilla directory and
re-installed, the XUL cache was still holding the goobered up info.

Just an idea....

Comment 12

[Brendan Eich [:brendan]]

Maybe the dependency tracking stuff is busted
(http://lxr.mozilla.org/mozilla/source/rdf/chrome/src/nsChromeProtocolHandler.cpp#670).
I'll test.  However, the FastLoad dependencies are only on files.  If you update
a member of a .jar file, I'm ass-u-ming that the .jar file's mtime gets set to
the current time.  Maybe unzipping is not bumping mtimes?

WD, the XUL cache is not persistent -- it goes away when you quit the app.  Just
to be clear, are you running with or without jars?

/be

Comment 13

[(not reading, please use [e-mail] instead)]

> sspitzer: Do you have any additional clues beyond randomness? It the interface 
> changed then a controlling factor is the interface info that is read from the 
> xpt files. If the interface info got *moved* from one xpt file to another then 
> you can get some really ugly things to happen if the old file is still in your 
> tree. Or, does this look more like a problem with using out of date js code? 
> Could cached compiled JS code be a factor?

no additional clues yet.  I can invesigate something, if you still need me too.  

all that happened recently was that the interface changed, but it didn't move
from one xpt to another.

Comment 14

[(not reading, please use [e-mail] instead)]

data point, I'm running with jars (in my local build)

Comment 15

[(not reading, please use [e-mail] instead)]

I haven't seen this in a while.

marking wfm.

Comment 16

[Tracy Walker [:tracy]]

same here...verified