Closed Bug 503798 Opened 15 years ago Closed 13 years ago

programmatically setting fcc to nocopy:// breaks thunderbird

Categories

(Thunderbird :: Message Compose Window, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 257735

People

(Reporter: G.Gersdorf, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.1) Gecko/20090616 Firefox/3.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.1.1pre) Gecko/20090710 Shredder/3.0b3pre

On of the features of my add-on 'copysent2current' is to set the fcc of a message to 'nocopy://' to prevent storing the message. This used to work with TB2 but fails at least since TB3b1. Thunderbird crashes completely. It seems, that the ComposeProcessDone callback in MsgComposeCommands.js is called more than once. On the second and later calls some global variable (like gMsgCompose) no longer exist.

This bug is not related to my add-on, as it is reproducible without it.

Reproducible: Always

Steps to Reproduce:
1. In MsgComposeCommands.js add the command
    gMsgCompose.compFields.fcc="nocopy://";
just after dispatching the 'compose-send-message' event (~ line 1780)
2. Send a message
3.
Actual Results:  
Message is sent than Thunderbird crashes
please post the crash report id 
 https://support.mozilla.com/en-US/kb/Mozilla+Crash+Reporter
Severity: normal → critical
Keywords: crash, stackwanted
(In reply to comment #1)
As i wrote: Thunderbird completely crashes. There are no crash reports.

If the error console (or any other window) is open, thunderbird does not crash immediately. But as soon as you close this additional window, all thunderbird window closes. So its probably not a crash but some kind of app shutdown?

(vtw, the line number mentioned in step 1 of the steps to reproduce has to be line 1904)
can you put it in debugger and get the stack at the point where the only thing left is console?
try installing venkman and debugging chrome? it sounds like something is asking something to quit..., if so you should be able to use venkman to find out what

typically i'd suggest:
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
(changing "firefox" to "thunderbid"), but i don't think it's crashing at all.

if it's really a quit request, you could also use windbg to breakpoint things involved in the quit request process. you're going to want to visit irc and ask for help with this.
Günter any luck with the tips in coment #4 to figure out what your issue is ?
Keywords: crash, stackwanted
Sorry, no.
I didn't even know where to start searching.
Günter perhaps someone can walk you through on IRC
http://www.mibbit.com/chat/?server=irc.mozilla.org&channel=%23tb-qa,%23qa
Keywords: crash, qawanted
Version: unspecified → 3.0
Keywords: qawanted
Whiteboard: [waiting on reporter]
Version: 3.0 → unspecified
GÜnter can you try to give us a stack trace please ?
Sorry, no.
Its not a crash. It seems to be a normal app shutdown at an unexpected time.
i think you're going to either have to spend time w/ venkman or find an engineer (probably on irc) and walk them through the problem.

given that this isn't something that can happen in thunderbird out of the box, this isn't going to be a top priority. but if you find a friendly engineer w/ a bit of time, it might be quickly analyzed and resolved.
Severity: critical → normal
Keywords: crash
Summary: Setting fcc to nocopy:// crashes thunderbird → programmatically setting fcc to nocopy:// breaks thunderbird
I strongly support fixing of this bug and can confirm it occurs on OS X with 3.0.0-3.0.5. It's especially annoying when you're on the road with mobile internet, and having to send out each message twice: One time for SMTP, the other one sending to trash.

I am no developer, but if I can help somehow, let me know!
I strongly support the request to fix this bug.
It is very annoying to have to wait while TB is saving an email which the user explicitly has marked as 'not to be saved' or 'nocopy'. 
Josef Wildburger
It seems, that this bug has been fixed in TB3.3a2
I'm not quite sure, but i think that a fix to bug 257735 also fixed this bug.
Günter, thanks for checking the alpha. Duping per reporter.
If anyone finds this is not fixed in 3.3, please comment.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Whiteboard: [waiting on reporter]
You need to log in before you can comment on or make changes to this bug.