115841 - clueless error when sending message with an invalid attachment - deleting attached file results in "There was a problem including the file ..."

Status: RESOLVED DUPLICATE of bug 516373

(MailNews Core :: Composition, defect)

Description

[Jean-Francois Ducarroz]

On MacOS X only, when you send a message with an attachment that doesn't exist
(attach a file then delete or rename it on your hardrive), Mozilla crash with
the  folowing stack trace:

Date/Time:  2001-12-18 08:54:43 -0800
OS Version: 10.1.1 (Build 5M28)
Host:       h-198-93-95-246.mcom.com

Command:    Netscape 6
PID:        545

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x001a2ff8

Thread 0 Crashed:
 #0   0x0054c8c8 in Block_link
 #1   0x0011663c in 0x11663c
 #2   0x0054d0b8 in deallocate_from_var_pools
 #3   0x0054d6f8 in _pool_free
 #4   0x0054d9e0 in free
 #5   0x004ff698 in 0x4ff698
 #6   0x0481f704 in FetcherURLDoneCallback(unsigned int, char const *, char
const *, int, wchar_t const *, void *)
 #7   0x04848ef8 in nsURLFetcher::OnStopRequest(nsIRequest *, nsISupports *,
unsigned int)
 #8   0x0484992c in nsURLFetcher::OnStateChange(nsIWebProgress *, nsIRequest *,
int, unsigned)
 #9   0x01f3a920 in FireOnStateChange__15nsDocLoaderImplFP14nsIWebProgressP10nsIRe
 #10  0x01f396d4 in nsDocLoaderImpl::doStopURLLoad(nsIRequest *, unsigned int)
 #11  0x01f39224 in nsDocLoaderImpl::OnStopRequest(nsIRequest *, nsISupports *,
unsigned int)
 #12  0x01b6d324 in nsLoadGroup::RemoveRequest(nsIRequest *, nsISupports *,
unsigned int)
 #13  0x01ba3eec in nsFileChannel::OnStopRequest(nsIRequest *, nsISupports *,
unsigned int)
 #14  0x01bc31d0 in nsOnStopRequestEvent::HandleEvent(void)
 #15  0x01bc25d0 in nsARequestObserverEvent::HandlePLEvent(PLEvent *)
 #16  0x005f28e0 in PL_HandleEvent
 #17  0x005f274c in PL_ProcessPendingEvents
 #18  0x0059a6dc in nsEventQueueImpl::ProcessPendingEvents(void)
 #19  0x01dae32c in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void)
 #20  0x01dae0f0 in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &)
 #21  0x0086ab14 in Repeater::DoRepeaters(EventRecord const &)
 #22  0x01dc1338 in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #23  0x01dc0f10 in nsMacMessagePump::DoMessagePump(void)
 #24  0x01dc084c in nsAppShell::Run(void)
 #25  0x01d79cec in nsAppShellService::Run(void)
 #26  0x004c9464 in main1(int, char **, nsISupports *)
 #27  0x004c9f6c in main

Comment 1

[Jean-Francois Ducarroz]

nominating nsbeta1 as this is a dataloss

Comment 2

[Jean-Francois Ducarroz]

I don't see the crash anymore using today's debug build. However, the error
alert is kind of clueless!

Comment 3

[Jean-Francois Ducarroz]

moving to 1.1. It's not a frequent scenario to attach a file and then delete it...

Comment 4

[scottputterman]

What's the error message that you don't like?

Comment 5

[esther]

I tested this scenario with build 2002011608 on mac osx.  The error message I
receive is "There was a problem including the file java_85.gif in the message. 
Would you like ot continue sending the message without this file?"   Cancel or OK
I OK'd and the message sent without the attachment.  Is this the message you
don't like or are you seeing something different?

Comment 6

[R.K.Aa.]

similar: bug 161745

Comment 7

[Wayne Mery (:wsmwk)]

stefan, do you see this? I don't think this can happen anymore because attachments are copied to a temp folder - the original file shouldn't be needed to send.

Comment 8

[Stefan [:stefanh]]

(In reply to comment #7)
> stefan, do you see this? I don't think this can happen anymore because
> attachments are copied to a temp folder - the original file shouldn't be needed
> to send.
> 
(SM trunk cvs build, recent source, Mac OS 10.5.2)

I attached a .txt file, then renamed it. When I hit "send" I get this message:

'Sending of message failed.
Unable to open the temporary file path/to/file.txt Check your "Temporary Directory" setting'

Clueless or not? :-)

Comment 10

[Thomas D. (:thomas8)]

1 This bug has been quite radically morphed since it's inception, original problem of comment 0 has been solved. Having descriptions that don't apply to the current summary of the bug is confusing.
2 This bug is reported against mailnews core (includes seamonkey). My impression is that mailnews core bugs seem to have come out of fashion somewhat (they are also harder to find).
3 Same bug (concerning the useless error message, not the crash) has been reported against Thunderbird:
Bug 516373 - TB: Sending a message with an attachment referring to a deleted file, throws non-descriptive error
That bug has a much better description / STR and proposed solution that are all spot-on.

-> I propose forward-duplicating this bug to bug 516373.

---------------------------
(In reply to comment #7)
> stefan, do you see this? I don't think this can happen anymore because
> attachments are copied to a temp folder - the original file shouldn't be
> needed to send.

Unfortunately (in TB at least), we only copy immediate snapshots of attachments to the temp folder when they are added via MAPI (Explorer-Send to). In the remainder of cases (adding from within TB), we just link to the original file, which causes this bug. However, just to make the confusion perfect, we always take a snapshot in case the draft is saved. This inconsistency is the bone of contention in Bug 378046, with the proposed solution of always taking the snapshot immediately when attaching.

Comment 11

[Thomas D. (:thomas8)]

Per comment 10 which didn't get any objections
-> forward-duplicate of bug 516373