programmatically setting fcc to nocopy:// breaks thunderbird

RESOLVED DUPLICATE of bug 257735

Status

RESOLVED DUPLICATE of bug 257735
9 years ago
8 years ago

People

(Reporter: G.Gersdorf, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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

Comment 1

9 years ago
please post the crash report id 
 https://support.mozilla.com/en-US/kb/Mozilla+Crash+Reporter
Severity: normal → critical
Keywords: crash, stackwanted
(Reporter)

Comment 2

9 years ago
(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)

Comment 3

9 years ago
can you put it in debugger and get the stack at the point where the only thing left is console?

Comment 4

9 years ago
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
(Reporter)

Comment 6

9 years ago
Sorry, no.
I didn't even know where to start searching.

Comment 7

9 years ago
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

Updated

9 years ago
Keywords: qawanted
Whiteboard: [waiting on reporter]
Version: 3.0 → unspecified
GÜnter can you try to give us a stack trace please ?
(Reporter)

Comment 9

9 years ago
Sorry, no.
Its not a crash. It seems to be a normal app shutdown at an unexpected time.

Comment 10

9 years ago
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

Comment 11

8 years ago
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!

Comment 12

8 years ago
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
(Reporter)

Comment 13

8 years ago
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.

Comment 14

8 years ago
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
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Whiteboard: [waiting on reporter]
Duplicate of bug: 257735
You need to log in before you can comment on or make changes to this bug.