440641 - Sending longish plaintext message hangs Thunderbird

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Thunderbird 2.0.0.14

STEPS TO REPRODUCE:

1) Start composing a message
2) Paste in 300KB of text
3) Send

ACTUAL RESULTS: Application is unresponsive for several minutes

EXPECTED RESULTS: No hang-up

I don't recall ever running into this with Thunderbird 1.5, but it's possible I never sent messages this long....

I profiled the hang in Shark, and it looks like all the time is spent calling IndexOf() on nsIContents.  The callstack to the IndexOf call is:

nsMsgMailNewsUrl::SetUrlState(int, unsigned)	
nsUrlListenerManager::BroadcastChange(nsIURI*, nsUrlNotifyType, unsigned)	
nsUrlListenerManager::BroadcastChange(nsIURI*, nsUrlNotifyType, unsigned)	
nsImapMailFolder::DeleteIsMoveToTrash()	
nsImapMailFolder::OnCopyCompleted(nsISupports*, unsigned)	
nsMsgCopyService::FindRequest(nsISupports*, nsIMsgFolder*)	
nsMsgCopyService::ClearRequest(nsCopyRequest*, unsigned)	
nsMsgGroupThread::~nsMsgGroupThread [in-charge deleting]()	
nsMsgComposeAndSend::DoFcc()	
nsMsgComposeSendListener::RemoveCurrentDraftMessage(nsIMsgCompose*, int)	
GetNodeLocation(nsIDOMNode*, nsCOMPtr<nsIDOMNode>*, int*)	
nsHTMLEditor::~nsHTMLEditor [in-charge]()	
nsHTMLEditor::ParseCFHTML(nsCString&, unsigned short**, unsigned short**)	
nsPlaintextEditor::CreateEventListeners()	
nsHTMLEditRules::WillDeleteSelection(nsISelection*, short, int*, int*)	
nsHTMLEditRules::ExpandSelectionForDeletion(nsISelection*)	
nsTypedSelection::AddItem(nsIDOMRange*)	
nsTypedSelection::Clear(nsPresContext*)	
nsTypedSelection::FetchEndParent(nsIDOMRange*)	
nsTypedSelection::StartAutoScrollTimer(nsPresContext*, nsIView*, nsPoint&, unsigned)	
nsBlinkTimer::AddBlinkFrame(nsPresContext*, nsIFrame*)	
nsSelection::BidiLevelFromClick(nsIContent*, unsigned)	
nsTypedSelection::AddItem(nsIDOMRange*)	
nsTypedSelection::MoveIndexToNextMismatch(int*, nsIDOMNode*, int, nsTArray<int> const*, int)	
nsTypedSelection::FindInsertionPoint(nsTArray<int> const*, nsIDOMNode*, int, unsigned (*)(nsIDOMNode*, int, nsIDOMRange*, int*), int*)	
nsTypedSelection::MoveIndexToNextMismatch(int*, nsIDOMNode*, int, nsTArray<int> const*, int)	
nsRange::ComparePoints(nsIDOMNode*, int, nsIDOMNode*, int)	
nsRange::IsIncreasing(nsIDOMNode*, int, nsIDOMNode*, int)	
nsAttrAndChildArray::IndexOfChild(nsIContent*) const	

though this is the mozilla.org release build, so the symbols might be suspect, of course.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

It would be interesting to know if this happens on trunk builds.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I'll try to set up a complete dummy profile to use with trunk builds, but it might be a while before I get to it.

Comment 3

[Magnus Melin [:mkmelin]]

I just tried this on thunderbird linux/trunk, pasted a 300k+ lorem ipsum into thunderbird (the plain text and also html composition) and sent it. Went out in < 10sec, no hang. 

Boris: still see this on trunk?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Not sure.  I can't reproduce on trunk, but neither can I reproduce on branch with the files I've tried.  I guess I should have saved that text file....

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Setting wanted- for now; feel free to renominate if we can come up with steps to reproduce...

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: 500kb sent test file

I think I can somehow reproduce this with an arbitrary 500+kb text email.

Stack coming up.

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Sample

So what happens is that I try sending a long plain text email from one gmail account to another - everything seems ok until the status message hits "sending login info" and then Thunderbird hangs for 5-10 minutes before unfreezing.

If I'm reading the sample correctly, it's spending lots of time at nsAttrAndChildArray::IndexOfChild

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Renominating, please let me know if there's more information to provide.

Also, my 500kb test email was produced by pasting the content from mailWindowOverlay.js file into the Compose area 5 times (5x100 = 500kb).

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I'm on latest comm-central-1.9.1 debug build in Mac Leopard 10.5.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090415 Lightning/1.0pre Shredder/3.0b3pre

Comment 10

[Boris Zbarsky [:bzbarsky]]

Ah, yeah.  That stack matches the one I saw, except it's a lot clearer on what the problem is.  It seems we're trying to select all 500KB of text, and the textframe selection code is being super-slow about it.

And in particular, the HasSelectionOverflowingDecorations call made from nsTextFrame::SetSelected is fairly slow in this case.

Marking dependent on bug 485446.

That said, the IndexOf() slowness is a real issue here.  Jonas, the problem is that we're comparing all sorts of stuff to range endpoints, so we keep making lots and lots of IndexOf() calls in pairs: first on the range endpoint, then on the node being compared.  The two are further and further apart, so the indexof cache just thrashes without being useful...

I wonder whether we can somehow make comparisons to range endpoints faster (e.g. cache the indexes of all ancestors of the start/end parent in the range or some such).  Worth filing a bug on?

Comment 11

[David Ascher (:davida)]

GIven the rarity of the use case, I don't think this is blocking.  (especially given that it depends on a gecko bug, etc).