143140 - Crash when reply to msg in a certain GB2312 char folder IMAP

Status: VERIFIED DUPLICATE of bug 133861

(MailNews Core :: Internationalization, defect)

Description

[Jeesun Cho]

Crash when reply to msg in a certain GB2312 char folder
Build: 0508 branch
OS: Chinese windows 98

Steps:
1.In an Imap account, create these three folders;
A. ╟и╦адц
B. ╟и╦а
C. дц
2. Move any messages to these folders.
3. Go to folder A and highlight any message in it. Click on Reply button. The
browser will either crash or display an error message (error occurred when
opening a compose window)
4. Do the samething with folder B and C. There's no problem.

So both "╟и╦а" and "дц" work fine. But when I used these together (╟и╦адц), it
could crash the browser.

Talkback ID : 6079476

Comment 1

[Jeesun Cho]

View this bug using GB2312

Comment 2

[Jeesun Cho]

Attachment: screenshot of folders used in the test

Any folder which has "╟и╦адц" in its name has the same problem

Comment 3

[nhottanscp]

talkback call stack:

nsXPCWrappedJSClass::GetInterfaceName
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1587]
nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1242]
nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsMsgComposeService::OpenWindow
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgComposeService.cpp, line 268]
nsMsgComposeService::OpenComposeWindow
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgComposeService.cpp, line 486]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027]
XPC_WN_CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2744]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881]
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3426]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 182]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
2210]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3461]
PresShell::HandleDOMEventWithTarget
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6153]
nsButtonBoxFrame::MouseClicked
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 195]
nsButtonBoxFrame::HandleEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 142]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6122]
PresShell::HandleEventWithTarget
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6073]
nsEventStateManager::CheckForAndDispatchClick
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 2624]
nsEventStateManager::PostHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 1705]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6126]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6028]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2076]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1887]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4713]
ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4968]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3630]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x24737 (0xbff94737)
0x00688bfa

Comment 4

[nhottanscp]

Is this IMAP only? Can anybody reproduce this?

Comment 5

[ji]

I can reproduce the problem on Simplified Chinese XP and Mac OS X with an IMAP
account.

Comment 6

[ji]

And I don't see the problem with the same foldername in Local Folders. 

Comment 7

[nhottanscp]

Xianglan, do you have talkback id for your crash. I want to see if that is the
same one as jeesun.

Comment 8

[ji]

Mine is 6080626, it looks same as Jeesun's.

Comment 9

[nhottanscp]

This doesn't look to be related to i18n by the call stack.
It seems like something to do with recycling message compose window.

http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgComposeService
.cpp#268

256       for (i = 0; i < mMaxRecycledWindows; i ++)
257       {
258         if (mCachedWindows[i].window && (mCachedWindows[i].htmlCompose == 
composeHTML) && mCachedWindows[i].listener)
259         {
260           /* We need to save the window pointer as OnReopen will call 
nsMsgComposeService::InitCompose which will
261              clear the cache entry if everything goes well
262           */
263           nsCOMPtr<nsIDOMWindowInternal> 
domWindow(mCachedWindows[i].window);
264           rv = ShowCachedComposeWindow(domWindow, PR_TRUE);
265           if (NS_SUCCEEDED(rv))
266           {
267             mCachedWindows[i].listener->OnReopen(params);
268             return NS_OK;
269           }
270         }
271       }
272     }
273   }


Reassign to ducarroz.
IQA, is this really specific to the Chinese folder name?
If so, please provide a reproducible environment to Jean-Francois (e.g. iqa test 
account info with that Chinese folder already created).

Comment 10

[Frank Tang]

crash bug. 

Comment 11

[Jeesun Cho]

Crash only  happens in certain folders mentioned earlier. Other than foler name,
I don't see any difference between the folders where the problem occurs and the
others.
I'll give Jean-Francois test account information via email.

Comment 12

[nhottanscp]

Cannot reproduce using 5/12 commercial branch (win32).
I copied a couple of messages to that folder. Is that supposed to happen always?

Comment 13

[nhottanscp]

Adding "IMAP" to the summary.
What is special about the characters which caused the crash? Are those generic
GB2312 characters?

Comment 14

[ji]

They are gb2312 characters. As Jeesun mentioned, it doesn't happen to all the
gb2312 characters, and it also doesn't happpen for a folder using one of the
three  characters seperately.

Comment 15

[Jean-Francois Ducarroz]

accepting

Comment 16

[Jean-Francois Ducarroz]

I can reproduce the error (not the crash) with a commercial build from 05/09
(branch) on Windows or Mac but cannot with a recent trunk debug build!

Comment 17

[Jean-Francois Ducarroz]

Works fine for me using a Trunk Commercial build ID 2002051308 on Windows 2000

Comment 18

[Jean-Francois Ducarroz]

doesn't for me using a Branch Commercial build ID 2002051308 on Windows 2000.
Looks like only a branch problem!

Comment 19

[Jean-Francois Ducarroz]

When the japanese name of the folder get converted to utf8, the name contains a
comma which chock message compose. This is a dup of bug 133861 which as been
fixed on the trunk on 2002-04-24 13:11.
I have requested that fix be checked in on the branch for rtm.

*** This bug has been marked as a duplicate of 133861 ***

Comment 20

[Jeesun Cho]

The bug 133861 also applies to Chinese folder name?

Comment 21

[Jean-Francois Ducarroz]

it apply as well to any multibyte language.

Comment 22

[marina]

verifying as such