63186 - Crash when pulling Subscribe dialog scrollbar handle down-up

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Michael Kolmodin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; m18) Gecko/20001206
BuildID:    [Mozilla]
Mozilla M18
Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; m18) Gecko/20001206

Crash when pulling Subscribe dialog scrollbar handle down-up after
filling the dialogue box with a lot of folders. Overall, the UI
seems unstable under the conditions described below. Classic skin.

Reproducible: Always
Steps to Reproduce:
This is a lot of steps. They are partly bound to my server
environment. Basically, I *think* it boils down to "Fill the
dialog with a lot of folders, pull the handle and watch a crash".


1. Open Mozilla
2. Open Mail/Composer window
3. Edit | Mail/News Account settings
4. Select 'Server' in  your user account.
5. Push button Advanced
6. Clear 'IMAP server directory'.
7. Uncheck the two check-boxes for
   "Show only subscribed folders" and
   "Server supports folders that contain sub-folders and messages"
   This means in my case that a *lot* of files are visible, most
   of which are not really mail folders. Click OK.
8. Restart Mozilla
9. Tasks | Mail
10. Enter password, watch a lot of folders...
11. Select a folder (crashes occasionally, at least on folders that
    are normal files and not messages.).
12. Right-click -> pop-up menu
13. Select Subscribe
14. Wait until folders are displayed

15. Pull the scrollbar handle down - up - down -> crash.


Actual Results:  Crash

Expected Results:  No crash ;-)

IMAP server using my UNIX home dir as base dir.
Imap server welcome message (version hint):
* OK mafalda.lule.frontec.se IMAP4rev1 v12.261 server ready.

I would say that it's not so normal to come into this situation.
However, if you are uncertain about the settings and experiment
a little, this might happen. I know ;-). And I suppose any crash
is worth taking care of.

Comment 1

[Michael Kolmodin]

Same crash  on Windows build m18/gecko 20001111; Win2K
On Solaris, same crash occurs with the modern UI (although i *think* had to
move te handle a few more times up-down before it crashed). 

Comment 2

[Michael Kolmodin]

Oops, just another thing... The windows crash created a Full-circle dump
which I sent back with my email address as sender and a reference to bug
63186 in the description field. This was just half less than an hour ago.
Should be possible to find?!

--m

Comment 3

[Michael Kolmodin]

Same bug on Windows build 20001218, though a little different symptoms:
When the handle is pulled up-down, the name of the mailboxes disappears -
the window becomes all white. Crash occuurs if/when exiting the Subscribe
dialogue.

Since this is affecting at least two platforms and several builds I'm
changing the 'platform' and OS to 'All' - don't be to hard with me if
this is wrong ;-)

--m

Comment 4

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

 Call Stack:     (Signature = Compare f6712ff0)
     Compare [..\..\..\dist\include\nsAReadableString.h, line 1325]
     Rule::LookupSymbol
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 732]
     nsXULTemplateBuilder::SubstituteTextReplaceVariable
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 5105]
     nsXULTemplateBuilder::ParseAttribute
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 5025]
     nsXULTemplateBuilder::SubstituteText
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 5073]
     nsXULTemplateBuilder::BuildContentFromTemplate
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 5582]
     nsXULTemplateBuilder::CreateTemplateContents
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 6358]
     nsXULTemplateBuilder::CreateTemplateAndContainerContents
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 6169]
     nsXULTemplateBuilder::CreateContents
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULTemplateBuilder.cpp, line 4317]
     nsXULDocument::CreateContents
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULDocument.cpp, line 2113]
     nsXULElement::EnsureContentsGenerated
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 3581]
     nsXULElement::ChildCount
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 2299]
     nsCSSFrameConstructor::ProcessChildren
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp,
line 11389]
     nsCSSFrameConstructor::ConstructXULFrame
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp,
line 6242]
     nsCSSFrameConstructor::ConstructFrameInternal
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp,
line 7618]
     nsCSSFrameConstructor::CreateTreeWidgetContent
[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp,
line 12420]
     nsXULTreeGroupFrame::GetFirstTreeBox
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeGroupFrame.cpp, line 287]
     nsTreeLayout::LazyRowCreator
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeLayout.cpp, line 308]
     nsTreeLayout::LazyRowCreator
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsTreeLayout.cpp, line 319]
     nsXULTreeOuterGroupFrame::ReflowFinished
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp,
line 1253]
     PresShell::HandlePostedReflowCallbacks
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4093]
     PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5184]
     PresShell::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4184]
     nsXULTreeOuterGroupFrame::InternalPositionChanged
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp,
line 716]
     nsXULTreeOuterGroupFrame::PositionChanged
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsXULTreeOuterGroupFrame.cpp,
line 577]
     nsSliderFrame::SetCurrentPosition
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp, line 703]
     nsSliderFrame::HandleEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsSliderFrame.cpp, line 479]
     PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4895]
     PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4813]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 379]
     nsViewManager2::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager2.cpp, line 1439]
     HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68]
     nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 690]
     nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 707]
     nsWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3940]
     ChildWindow::DispatchMouseEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4148]
     nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2999]
     nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 963]
     USER32.DLL + 0x3eb0 (0x77e13eb0)
     USER32.DLL + 0x401a (0x77e1401a)
     USER32.DLL + 0x92da (0x77e192da)
     nsWebShellWindow::ShowModal
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1111]
     nsContentTreeOwner::ShowModal
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsContentTreeOwner.cpp, line 184]
     GlobalWindowImpl::OpenInternal
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3124]
     GlobalWindowImpl::OpenDialog
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 2070]
     WindowInternalOpenDialog
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSWindow.cpp, line 4237]
     js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 792]
     js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2604]
     js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 808]
     js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 880]
     JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3195]
     nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 919]
     nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 155]
     nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line 789]
     nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\layout\events\src\nsEventListenerManager.cpp, line
1677]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\rdf\content\src\nsXULElement.cpp, line 3304]
     PresShell::HandleDOMEventWithTarget
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4926]
     nsMenuFrame::Execute
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 1505]
     nsMenuFrame::HandleEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsMenuFrame.cpp, line 351]
     PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4895]
     PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 4813]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 379]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 352]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 352]

CVS blame shows waterson and scc to be the contributors to the top two call stacks.

Comment 5

[scottputterman]

reassigning to sspitzer

Comment 6

[Håkan Waara]

Is this still happening in the latest nightly?

Comment 7

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

Okay, I'm trying to reproduce this on Windows 2000.  How many folders do you
have on your IMAP server? Excellently filed bug report!  I'll try to get this
nailed down today.

Comment 8

[Michael Kolmodin]

Same bug on Win2K/20010102. A talkback dump was sent less than an hour ago with
a reference to bug 63186 in the description field. I will do testing later on
more recent builds, this is what I can do right now.

Comment 9

[Michael Kolmodin]

Bug is still here on 20010121/Solaris (sorry, no PC here right now).

In my top-level directory there is 109 items, which are presented as "folders"
by the IMAP server. 19 of those items are directories. These directories
contains about 3200 files - I presume that mozilla is (happily) unaware of
those, though.

Once again I stress that the items presented as folders by the IMAP server
just are ordinary files in my home dir.

Comment 10

[Michael Kolmodin]

Bug still here in Win32 build 20010131.

I've found it! The problem is not related to the number of mailboxes, it's
about folders/filenames containing odd characters.

I have an environment where my home dir lives on a Solaris machine. 
Below this, in ¨/Mail all the mail folders exist.

In order to test I've created a new dir ~/hugo. After putting the IMAP
server directory to 'hugo', the contents of this dir is presented as 
folders by Mozilla when starting Mozilla Mail.

I have a really odd file created by FrameMaker. The name of this, as
shown by od -c is

diana.mk > ls Ny^ÚppnadeFMFiler  | od -c
0000000   N   y 232   p   p   n   a   d   e   F   M   F   i   l   e   r
0000020  \n

If this file exists in the ~/hugo folder, and thus Mozilla tries to present
this as a folder the the user, the crash occurs; otherwise not

The content of this file is
--/home/mk/proj/fsg/ISA/fw-kravspec
/home/mk/proj/fsg/EPNS/sammanställning
/home/mk/proj/fsg/lule-kommun/offert-epost
/home/mk/proj/fsg/norrlandsfonden/avtal
/home/mk/proj/NAB/offert-epost
--

There are no odd control characters embedded:
diana.mk > cat Ny^ÚppnadeFMFiler 
/home/mk/proj/fsg/ISA/fw-kravspec
/home/mk/proj/fsg/EPNS/sammanställning
/home/mk/proj/fsg/lule-kommun/offert-epost
/home/mk/proj/fsg/norrlandsfonden/avtal
/home/mk/proj/NAB/offert-epost
diana.mk >
----

So i guess it's the strange name.

Several dumps sent. All has my email address as sender, the last one a reference
to bug 63186 in the description field.

--m

Comment 11

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

Attachment: Stack trace of crash.

Comment 12

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

Seth, David - sounds like it's not a news problem, after all.  Any idea where 
this should go?

Comment 13

[Michael Kolmodin]

Attachment: Imap log

Comment 14

[Michael Kolmodin]

Just to make myself clear: the crash still occurs in the Subscribe dialogue like
I described. This might (should?) imply that the crash is still a News thing?!

Comment 15

[(not reading, please use [e-mail] instead)]

ok, I think I understand.  

Michael has a folder on his imap server that has a special character, which is
causing us to crash.  

I've got folders with special characters, but I don't get the crash.  (see
#67859 for a related bug, though)

I'll try to recreate the same folder (Ny~ZppnadeFMFiler) to reproduce the crash.

for now, accepting this bug.

Comment 16

[(not reading, please use [e-mail] instead)]

ok, I can reproduce this.

uwtest (password uwtest) on sspitzer.mcom.com

tomorrow, I'll debug and fix.

Comment 17

[(not reading, please use [e-mail] instead)]

this might be a bug with the server.  (it's just like a client guy to say that)

The server doesn't seem to be giving me the folder name in utf7.

while this doesn't crash 4.x, I'm unable to subscribe to that folder in 4.x

I'm working on a fix for the crash now.

Comment 18

[(not reading, please use [e-mail] instead)]

ok, maybe it isn't a server bug.

In my imap log, I see

* LIST (\NoInferiors \UnMarked) "/" {15}
bugtestbugtest

somewhere, I'm deciding that's UTF7.  working on a fix.

Comment 19

[(not reading, please use [e-mail] instead)]

well, I've got a fix for the crash.  but I'm going to hand off the problem I'm
having with literals to naving or bienvenu.

patching coming soon.

Comment 20

[(not reading, please use [e-mail] instead)]

Attachment: fix for the crash: ignore any folders not in utf7.

Comment 21

[David :Bienvenu]

John, is it valid for the server to return folder names that aren't mod
utf7-encoded?

Comment 22

[David :Bienvenu]

so, instead of ignoring it, would it work to convert it to modified utf7 if it
wasn't already utf7?

CreateUtf7ConvertedStringFromUnicode(PRUnichar aFolderName) will return a
modified utf7 string. so,you'd just need to convert the foldername to unicode
first, then convert it to utf7.

Comment 23

[John G. Myers]

It is not legal for the server to return folder names that aren't in Modified 
UTF7.

Converting the folder name to MUTF7 is problematic for two reasons:

1) You don't know what charset the server is using.
2) You would need to convert the folder name back before using it in subsequent 
IMAP commands.

Comment 24

[David :Bienvenu]

OK, then I guess your changes are the way to go, Seth. sr=bienvenu. Thanks for
the help, John.

Comment 25

[(not reading, please use [e-mail] instead)]

marking for 0.8.

Comment 26

[Brendan Eich [:brendan]]

Nits on the patch:

+            break;
+        }
+        else {

else after break is a non-sequitur, just say no.

+    }
 	return mInner->AddTo(aName, addAsSubscribed, changeIfExists);

make me happy, change that tab before the return into four spaces.  Can you get
an official r= from jgmyers?

/be

Comment 27

[John G. Myers]

I don't think I'm authorized to r=.  Assuming Brendan's comments are 
addressed, the patch is ok by me.

Comment 28

[Brendan Eich [:brendan]]

Anyone can r= -- mozilla.org asks for an r= from module owner or peer (peer if
owner originated the patch) before sr=.  You're peering, so your r= is fine.

Seth, fix my nits and get this in.  Thanks,

/be

Comment 29

[(not reading, please use [e-mail] instead)]

Attachment: revised patch, thanks to brendan for the nits.

Comment 30

[Brendan Eich [:brendan]]

One last thought: don't NS_ASSERTION(0, ...) if you find a folder name that's
not utf7 -- do NS_ERROR and return.

/be

Comment 31

[(not reading, please use [e-mail] instead)]

no help wanted, critical for 0.8

brendan, do you mean:

NS_ASSERTION(nameIsClean, "folder path was not in UTF7, ignore it");
if (!nameIsClean) return NS_OK;

I'm fine with that.

Comment 32

[Brendan Eich [:brendan]]

sspitzer: even better (if you don't mind testing nameIsClean twice on debug
builds, and what's to mind?)!

/be

Comment 33

[(not reading, please use [e-mail] instead)]

fix is in.

Comment 34

[Michael Kolmodin]

You're doing a great job! Mozilla rules :-)

--michael

Comment 35

[Michael Kolmodin]

Tested on Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; 0.8) Gecko/20010214
OK, no crash.

One remark: Ignoring non-UTF folders is basically fine with me. However,
it's a Strange Thing which think should be logged, at least on debug
builds. 

Will do a PC test tomorrow or Saturday.

--m

Comment 36

[Michael Kolmodin]

Tested on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8) Gecko/20010215
OK, no crash. 

--m

Comment 37

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

Marking VERIFIED, per reporter's comments (Thanks, Michael.)