Open
Bug 440641
Opened 17 years ago
Updated 9 years ago
Sending longish plaintext message hangs Thunderbird
Categories
(MailNews Core :: Composition, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: bzbarsky, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: perf, regression, testcase)
Attachments
(2 files)
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.
Flags: blocking-thunderbird3?
Comment 1•17 years ago
|
||
It would be interesting to know if this happens on trunk builds.
Keywords: qawanted
Reporter | ||
Comment 2•17 years ago
|
||
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.
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•16 years ago
|
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Comment 3•16 years ago
|
||
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?
Reporter | ||
Comment 4•16 years ago
|
||
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•16 years ago
|
||
Setting wanted- for now; feel free to renominate if we can come up with steps to reproduce...
Flags: wanted-thunderbird3+ → wanted-thunderbird3-
Comment 6•16 years ago
|
||
I think I can somehow reproduce this with an arbitrary 500+kb text email.
Stack coming up.
Comment 7•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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
Reporter | ||
Comment 10•16 years ago
|
||
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•16 years ago
|
||
GIven the rarity of the use case, I don't think this is blocking. (especially given that it depends on a gecko bug, etc).
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Updated•15 years ago
|
OS: Mac OS X → All
You need to log in
before you can comment on or make changes to this bug.
Description
•