154734 - Unable to forward inline from folder w/a space in name - get error msg.[@ nsXPCWrappedJSClass::GetInterfaceName]

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[lchiang]

This bug report's comments was taken from 
http://bugzilla.mozilla.org/show_bug.cgi?id=131384.  I had originally seen the 
symptoms which was the same as 131384.  After further analysis, I believe that 
the cause is different than 131384 since the problem I'm seeing is a newly 
introduced problem in the 6-25 branch build.  

1.  Forward inline a message
2.  I get a compose window which didn't have any content in the body of the 
compose window.  So, I close the compose window and choose to forward again.  3. 
 Then, I get an error msg: "An error occurred while creating a message compose 
window.  Please try again."

Here are the comments pasted from 131384:
---- begin pasted comments ----


------- Additional Comment #23 From [e-mail] 2002-06-27 13:24 
------- 

I have started seeing this recently on forwarding inline on various messages. 
Forwarding these same messages as attachments is successful.

The first time I encounter this problem,  I get a compose window which didn't
have any content in the body of the compose window.  So, I close the compose
window and choose to forward again.  Then, I get an error msg: "An error
occurred while creating a message compose window.  Please try again."

Win2k branch 1.0.1 build.  I started experiencing this in yesterday and today's
build.


------- Additional Comment #24 From [e-mail] 2002-06-27 13:29 
------- 

Removing the .msf file from the folder containing this message didn't help.


------- Additional Comment #25 From [e-mail] 2002-06-27 13:36 
------- 

My compose window is set up so that:

1.  it automatically bcc's me
2.  I have a reply-to set
3.  I have a signature

When I first see a blank window, I see three TO: headings in the recipient list
and nothing else.  So I close the compose window after a few minutes.  Then, I
get the error msg.


------- Additional Comment #26 From [e-mail] 2002-06-27 13:44 
------- 

May be getting closer to steps... 

I had mentioned to putterman that I saw this problem today after I undeleted a
message and tried to forward it.   He tried something similar and saw the
problem.  In his case, he had a crash prior to seeing the problem, but I didn't.

from putterman: just reproduced!
from putterman: I undeleted a message.
from putterman: then I forward it and crashed
from putterman: When I started up, I tried forwarding the message again and got
the error.
from putterman:  Both times it's happened to me I've crashed prior to seeing 
this.
from lchiang:   my steps were not exactly the same since I didn't crash, but
still it may be a key.


------- Additional Comment #27 From [e-mail] 2002-06-27 17:41 
------- 

Jean-Francois mentioned he was looking into some of the forwarding bugs. Varada,
can you help look into this, too?


------- Additional Comment #28 From [e-mail] 2002-06-27 19:40 
------- 

I have narrowed this down.
Branch (commercial) build 2002-06-24  does NOT have this problem on the messages 
I tried.
Branch (commerical) build 2002-06-25  has the problem on the same messages I 
tried above.

I haven't yet narrowed down how I get into this state. 

Some more observations:
1. Copied one of the messages that I had a problem with to a new folder on the 
same mail account.   Able to forward that message in the new folder w/out any 
problems.
2. Tried some things with ducarroz.  Recycle compose window doesn't have 
anything to do with this bug.


------- Additional Comment #29 From [e-mail] 2002-06-27 19:46 
------- 

Here are the changes between that time:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_
1_0_%280_%29%3FBRANCH&branchtype=regexp&dir=&file=&filetype=match&who=&whotype=m
atch&hours=2&date=explicit&mindate=06%2F24%2F2002&maxdate=06%2F25%2F2002+04%3A00
&cvsroot=%2Fcvsroot&sortby=File


------- Additional Comment #30 From [e-mail] 2002-06-27 19:57 
------- 

(I apologize for taking over this bug report.  It may turn out that I may be 
running into a different cause for the bug even though the symptoms are the same 
as originally reported in this bug.)

--- end pasted comments ----

Comment 1

[lchiang]

I believe that the fix to http://bugzilla.mozilla.org/show_bug.cgi?id=137071 
caused this bug.

I narrowed it down to the build dates on my system:

Branch build:  2002-06-24 - no problem seen
Branch build:  2002-06-25 - problem seen

Looked at the checkins for those dates.
Saw that bug 137071 had to do with forwarding.  The fix for that bug was checked 
into the trunk between 6-20 and 6-21.

Trunk build:  2002-06-20-08 - no problem seen
Trunk build:  2002-06-21-09 - problem seen

Comment 2

[lchiang]

Details: IMAP

I'd suggest trying to forward inline various types of messages.  I've seen this 
on messages with attachments, messages with various formatting in the body, 
messages forwarded to me that had attachments or were a bit long.

Comment 3

[lchiang]

Setting user_pref("javascript.options.showInConsole", true) to see the 
application JS errors yields: 

Error: redeclaration of const MOZ_HELP_URI
Source File: chrome://help/content/contextHelp.js Line: 1

This is probably not useful in providing info.

---

With stephend's help, I tried different logging mechanism for msgcompose:5.  Not 
much info except for this:

0[2f4080]: 
[process]: [totalTime][deltaTime]
--------------------
0[2f4080]: [0.01][0.01] - Start opening the window
0[2f4080]: [1.28][1.28] - Start initializing the compose window (ComposeLoad)

Comment 4

[scottputterman]

adding ssaux and kaie.

Comment 5

[lchiang]

I went ahead to try to capture more info since I'm unable to install a debug 
environment.

I set the debug prefs to use strict warnings to dump to the console window.  On 
the trunk 6-21 build (which has the debug item in prefs dialog), here is what I 
see from the console window when I choose to forward the message to when I 
cancel out of the error msg.  Do not know if this will be useful, but here it 
is:

Net2Phone.js has been interpreted...
[nsIMsgIdentity: id2],[nsIMsgIdentity: id3],[nsIMsgIdentity: id4],[nsIMsgIdentit
y: id5],[nsIMsgIdentity: id1],[nsIMsgIdentity: id6],[nsIMsgIdentity: id7],[nsIMs
gIdentity: id8],[nsIMsgIdentity: id9],[nsIMsgIdentity: id10],[nsIMsgIdentity: id
11],[nsIMsgIdentity: id12]

ComposeUnload from XUL

Comment 6

[lchiang]

more details:

I have my default to always sign messages.  I don't know if this makes a 
difference.

However, once I did encounter the problem, I turned off the pref to sign 
messages.  I still see the problem w/those messages.  I'm not sure if I am now 
in a strange state, but thought I'd provide this piece of info.

Comment 7

[lchiang]

Once I see this problem on one message in a folder, I see it for all the 
messages in the same folder.  Even after an application restart.
This is really bad!

Comment 8

[Jean-Francois Ducarroz]

Using a commercial trunk release build from yesterday on MacOS X, I was able to
reproduce the crash when forwarding inline a spam message from a imap folder
named  "probably spam", here is the stack trace:

Date/Time:  2002-06-28 09:03:42 -0700
OS Version: 10.1.5 (Build 5S66)
Host:       h-198-93-95-203.mcom.com

Command:    Netscape
PID:        311

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

Thread 0 Crashed:
 #0   0x01da60c8 in nsXPCWrappedJSClass::GetInterfaceName(void)
 #1   0x01da4e78 in 0x1da4e78
 #2   0x01da0fb4 in CallMethod__14nsXPCWrappedJSFUsPC15nsXPTMethodInfoP17nsXPTCMin
 #3   0x005ba38c in PrepareAndDispatch
 #4   0x005be37c in nsProcessConstructor(nsISupports *, nsID const &, void **)
 #5   0x0794e32c in nsMsgComposeService::OpenWindow(char const *,
nsIMsgComposeParams *)
 #6   0x07950424 in OpenComposeWindowWithParams__19nsMsgComposeServiceFPCcP19nsIMs
 #7   0x076662f8 in CreateTheComposeWindow__FP16nsIMsgCompFieldsP19nsMsgAttachment
 #8   0x0766a14c in mime_parse_stream_complete(_nsMIMESession *)
 #9   0x07665518 in nsStreamConverter::OnStopRequest(nsIRequest *, nsISupports *)
 #10  0x07a13204 in OnStopRequest__25nsImapCacheStreamListenerFP10nsIRequestP11nsI
 #11  0x01e3fd64 in OnStopRequest__Q218nsStorageTransport13nsReadRequestFP10nsIReq
 #12  0x005b9f0c in XPTC_InvokeByIndex
 #13  0x005b9e00 in XPTC_InvokeByIndex
 #14  0x005c271c in EventHandler(PLEvent *)
 #15  0x005eff80 in PL_HandleEvent
 #16  0x005efdec in PL_ProcessPendingEvents
 #17  0x00595dcc in nsEventQueueImpl::ProcessPendingEvents(void)
 #18  0x0206fbac in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void)
 #19  0x0206fa50 in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &)
 #20  0x0088eb14 in Repeater::DoRepeaters(EventRecord const &)
 #21  0x020860f8 in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #22  0x02085e20 in nsMacMessagePump::DoMessagePump(void)
 #23  0x0208579c in nsAppShell::Run(void)
 #24  0x01fc8b0c in nsAppShellService::Run(void)
 #25  0x004c9f0c in main1(int, char **, nsISupports *)
 #26  0x004ca94c in main

Thread 1:
 #0   0x70000978 in mach_msg_overwrite_trap
 #1   0x70005a04 in mach_msg
 #2   0x7017bf84 in __CFRunLoopRun
 #3   0x701b70ec in CFRunLoopRunSpecific
 #4   0x7017b8cc in CFRunLoopRunInMode
 #5   0x7061be08 in
XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *)
 #6   0x706141c0 in CAPThread::Entry(CAPThread *)
 #7   0x7002054c in _pthread_body

Thread 2:
 #0   0x7000497c in syscall
 #1   0x70557600 in BSD_waitevent
 #2   0x70554b80 in CarbonSelectThreadFunc
 #3   0x7002054c in _pthread_body

Thread 3:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x705593ec in CarbonOperationThreadFunc
 #3   0x7002054c in _pthread_body

Thread 4:
 #0   0x70044cf8 in semaphore_timedwait_signal_trap
 #1   0x70044cd8 in semaphore_timedwait_signal
 #2   0x70283e9c in TSWaitOnConditionTimedRelative
 #3   0x7027d740 in TSWaitOnSemaphoreCommon
 #4   0x702c2078 in TimerThread
 #5   0x7002054c in _pthread_body

Thread 5:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x70250aa8 in TSWaitOnCondition
 #3   0x7027d728 in TSWaitOnSemaphoreCommon
 #4   0x70243d0c in AsyncFileThread
 #5   0x7002054c in _pthread_body

Thread 6:
 #0   0x7003f4c8 in semaphore_wait_signal_trap
 #1   0x7003f2c8 in _pthread_cond_wait
 #2   0x7055b884 in CarbonInetOperThreadFunc
 #3   0x7002054c in _pthread_body

Thread 7:
 #0   0x70000978 in mach_msg_overwrite_trap
 #1   0x70005a04 in mach_msg
 #2   0x70026a2c in _pthread_become_available
 #3   0x70026724 in pthread_exit
 #4   0x70020550 in _pthread_body

PPC Thread State:
  srr0: 0x01da60c8 srr1: 0x0000f030                vrsave: 0x00000000
   xer: 0x00000018   lr: 0x01da4e78  ctr: 0x006184d0   mq: 0x00000000
    r0: 0x00000000   r1: 0xbfffe4d0   r2: 0x01bdd000   r3: 0x00000000
    r4: 0x0459bff0   r5: 0x05cfdc60   r6: 0x05cfdc50   r7: 0x05cfdc50
    r8: 0x051bfd28   r9: 0x80240e10  r10: 0x00000024  r11: 0x80003710
   r12: 0x000ff7d4  r13: 0xbfffe5f0  r14: 0x00000000  r15: 0x02ea1890
   r16: 0x02ea6da0  r17: 0x00000000  r18: 0x00000000  r19: 0x80004005
   r20: 0x00000001  r21: 0x05cfdc74  r22: 0x00000001  r23: 0xbfffe9a0
   r24: 0x00000000  r25: 0x00000001  r26: 0x00000001  r27: 0x01f11e68
   r28: 0x0459bfe0  r29: 0x00000004  r30: 0x01f11e48  r31: 0x0459bfe0

Comment 9

[Jean-Francois Ducarroz]

Good news, I can reproduce the problem (not the crash) with a mozilla trunk
debug build. This append only when I forward from a subfolder! Here is the
console output:

Time to create the composition window WITH a body!!!!
This is a recycled compose window!
[nsIMsgIdentity: id2],[nsIMsgIdentity: id3],[nsIMsgIdentity: id4]
CREATE nsMsgCompose: 5d964e0
###!!! ASSERTION: morkBool_kFalse: '0', file
s:\mozilla\db\mork\src\morkConfig.cpp, line 57
###!!! ASSERTION: morkBool_kFalse: '0', file
s:\mozilla\db\mork\src\morkConfig.cpp, line 57
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
s:\mozilla\mailnews\imap\src\nsImapService.cpp, line 3979
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
s:\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 1454
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
s:\mozilla\mailnews\compose\src\nsMsgComposeService.cpp, line 631
DISPOSE nsMsgCompose: 5d964e0
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004003
(NS_ERROR_INVALID_POINTER) [nsIMsgComposeService.InitCompose]"  nsresult:
 "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame ::
chrome://messenger/content/messengercompose/MsgComposeCommands.js :
: ComposeStartup :: line 1346"  data: no]
************************************************************
JavaScript error:
chrome://messenger/content/messengercompose/MsgComposeCommands.js line 2098:
gMsgCompose has no properties


ComposeUnload from XUL

Comment 10

[Jean-Francois Ducarroz]

Lisa was right, looks like a regression introduced by the second fix for bug
137071 (I did the patch). This patch seems to have exposed a problem in IMAP.

When forwarding a message, we now setup the original URI in the message compose
parameters in order to make smime work correctly. This URI contains escaped
characters (spaces in my case) and for some reason that make IMAP failed. POP3
does not have that problem. The URI we process during a reply does not contains
escaped characters.

I can unescape the URI in mime but I think we should rather fix IMAP as it's
normal to have escaped spaces characters in a URI.

David & Cavin, any thought about that? 

Comment 11

[lchiang]

I talked with Esther and she is able to reproduce this now when forwarding 
inline in a subfolder.

Thanks for picking up the missing link that it was a subfolder, JF!

Comment 12

[Jean-Francois Ducarroz]

In fact you need a folder with a space character in its name, it could be a top
folder.

Comment 13

[Charles Rosendahl]

Can I have the steps to reproduce this bug consistently?  I've been trying to
reproduce this all morning on the 625 branch builds to no avail.

Also, are these messages by any chance encrypted that are being forwarded, or
are they all not encrypted?  bug 137071 was verified that encrypted messages are
replied to and forwarded in an encrypted state.  I also verified non-encrypted
messages maintained their state as well.

Kaie's fix to bug 137071 touched the following files of interest:
mozilla/mailnews/base/resources/content/messageWindow.js
mozilla/mailnews/base/resources/content/msgHdrViewOverlay.js

mozilla/mailnews/compose/public/nsIMsgCompose.idl
mozilla/mailnews/compose/src/nsMsgCompose.cpp

The following file was changed specifically to fix forwarding encrypted messages
inline as encrypted:
/mozilla/mailnews/mime/src/mimedrft.cpp 

In particular, based on the debug output in comment #9, here is the code that
Kai changed.  Since I'm not familiar with it, a mail guru should make the 'aha!'
if possible.

#ifdef NS_DEBUG
         printf("Time to create the composition window WITH a body!!!!\n");
#endif
           if (mdd->forwardInline)
-          CreateTheComposeWindow(fields, newAttachData,
nsIMsgCompType::ForwardInline, composeFormat, mdd->identity);
+          CreateTheComposeWindow(fields, newAttachData,
nsIMsgCompType::ForwardInline, composeFormat, mdd->identity, mdd->url_name);
         else
...

A new param was added to CreateTheComposeWindow.  Does this help?

Sorry - I can't reporduce it on any of my systems :(

Comment 14

[Jean-Francois Ducarroz]

All you need to reproduce this problem is a trunk or branch build from after 0621:

1) Select an IMAP folder with a space in its name
2) Select any message in that folder
3) Do Forward Inline
4) ==> either the compose window shows an empty body or it shows an error dialog

Comment 15

[Charles Rosendahl]

Thank you sir - works like a champ.

Comment 16

[David :Bienvenu]

my thought is that rewriting the imap uri code is too scary to consider at this
point. Imap Uri's tend to be in imap mod utf-7, if I remember correctly, and
adding another layer of escaping and unescaping is really asking for trouble. We
have enough trouble keeping track of whether a given string is imap utf7 encoded
or not. I could be wrong, but this doesn't sound like a promising direction at
this point.

Comment 17

[Jean-Francois Ducarroz]

Attachment: Proposed fix, v1

IMAP has an hard time to deal with escaped URI (which could apparently lead to
a crash but I wasn't able to debug it). The fix is to unescaped the URL passed
to the message compose in mime when forwarding inline a message. I have tested
the patch with folder name containing 8/16 bits characters.

Comment 18

[lchiang]

Once the fix goes in for this, we should do a bit of testing with international 
folder names as well.  cc: marina

Comment 19

[David :Bienvenu]

Comment on attachment 89585 [details] [diff] [review]
Proposed fix, v1

sr=bienvenu. What user actions does this code change affect? Does it affect
editing Drafts, for example? Have you tried a Drafts folder with 8 and 16 bit
ascii characters?

Comment 20

[Cavin Song]

Comment on attachment 89585 [details] [diff] [review]
Proposed fix, v1

r=cavin.

Comment 21

[Jean-Francois Ducarroz]

>What user actions does this code change affect? Does it affect
>editing Drafts, for example? Have you tried a Drafts folder with 8 and 16 bit
>ascii characters? 

It won't affect draft or template despite the patch in mime is for them too
because the original url is ignored my message compose in that case. But I did
test it just in case and it works fine.

Comment 22

[scottputterman]

raising priority.  You should be able to forward a message from a folder with a
space without crashing or getting an error.

Comment 23

[Jean-Francois Ducarroz]

Fix checked in the trunk. We must fix thais problem on the branch too.

Comment 24

[scottputterman]

Esther, can you verify this on the next trunk build?

Comment 25

[esther]

Do you think there will be another Trunk today 6-28?  All that I see there now
are from the a.m.

Comment 26

[[e-mail] (gone - use [e-mail] instead)]

I have a current trunk build, if anyone needs to use my Win2k machine to test
this on.

Comment 27

[[e-mail] (gone - use [e-mail] instead)]

Okay, I just tested this with my IMAP folder named, 'BFT - Round 1', which
obviously contains a space.

I've tried:

Forwarding inline
Forwarding as attachment

both from top level folders and sub-folders with spaces in them.

Comment 28

[lchiang]

Stephen - can you make sure you were able to see the problem in the first place
on an older build (even branch would be fine)?
Also, try out the fix/cases for bug 137071 with your trunk build.

Comment 29

[[e-mail] (gone - use [e-mail] instead)]

Lisa, sure thing.  In fact, I can still see the problem 100% with my 6-28-2002
branch Linux build, same scenarios.

Re: bug 137071, I can't test that with my own build - as we don't build the
Personal Security Manager by default - so I can't do any S/MIME features.

Let me get a current commercial trunk and I'll see about bug 137071.

Comment 30

[Kai Engert [:KaiE:]]

I just applied this patch to my branch build and tested on IMAP.
The 137071 feature still works for me.
Replying to or forwarding a message stored in a folder named "space f" also
works correctly for me.

Comment 31

[[e-mail] (gone - use [e-mail] instead)]

Assigning myself as QA contact on this bug - I'll take care of verifications
this weekend.  Also, changing PLAT/OS to All, since I've seen this on Mac and Linux.

Comment 32

[[e-mail] (gone - use [e-mail] instead)]

Verified FIXED on the trunk with builds:

Mac OS 9.2.2/OS X 10.1.15 - 2002-06-29-08
Windows 2000 - 2002-06-29-08
RedHat 7.3 - 2002-06-29-04

I've tested top-level and subfolders with both forward as inline and forward as
attachment (the latter, just to ensure no regression).

I'll have to check the security cases in bug 137071 a little later.

Marking VERIFIED for trunk verification.

Comment 33

[Paul Wyskoczka]

Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch.  Please get
drivers approval before checking in. When you check this into the branch, please
change the mozilla1.0.1+ keyword to fixed1.0.1

Comment 34

[greer]

Adding signature to the summmary and topcrash- keyword for talkback tracking to
help verify the fix on the branch and trunk.

Comment 35

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 36

[Jean-Francois Ducarroz]

Fix checked in the branch

Comment 37

[[e-mail] (gone - use [e-mail] instead)]

With the 2002-07-02 branch 1.0 commercial builds on Mac OS X 10.1.5, Mac OS
9.2.2, RedHat Linux 7.3 and Windows 2000, I am able to forward inline and as
attachment messages that exist in folder containing spaces.

Replacing fixed1.0.1 keyword with verified1.0.1

Comment 38

[[e-mail] (gone - use [e-mail] instead)]

I'll also continue to watch Talkback for the
nsXPCWrappedJSClass::GetInterfaceName stacktrace.

Comment 39

[Kai Engert [:KaiE:]]

The workaround used in this bug introduced bug 155476, see comments at
http://bugzilla.mozilla.org/show_bug.cgi?id=155476#c6

Comment 40

[[e-mail] (gone - use [e-mail] instead)]

This is still fine with today's branch builds on OS X, OS 9, Windows 2000 and
Linux, with the patch from bug 155638 checked in (basically, to back out the old
bug).