From 52d1d09ad753e93ce9b4b0f8406748c123909e85 Mon Sep 17 00:00:00 2001 From: "mscott%netscape.com" Date: Tue, 4 Dec 2001 04:02:02 +0000 Subject: [PATCH] Bug #112661 --> back out my removal of the firing of selection changed because it stopped us from selecting the next message when you delete the top of a collapsed thread. r/sr=bienvenu --- .../base/resources/content/msgMail3PaneWindow.js | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/mailnews/base/resources/content/msgMail3PaneWindow.js b/mailnews/base/resources/content/msgMail3PaneWindow.js index 4749f32d68b0..c42c0d0823e1 100644 --- a/mailnews/base/resources/content/msgMail3PaneWindow.js +++ b/mailnews/base/resources/content/msgMail3PaneWindow.js @@ -269,12 +269,21 @@ function HandleDeleteOrMoveMsgCompleted(folder) // optimize away. if (gNextMessageViewIndexAfterDelete != -1) { - // when deleting a message we don't update the commands when the selection goes 0 + // when deleting a message we don't update the commands when the selection goes to 0 // (we have a hack in nsMsgDBView which prevents that update) so there is no need to - // update commands when we select the next message after the delete the commands already + // update commands when we select the next message after the delete; the commands already // have the right update state... gDBView.suppressCommandUpdating = true; outlinerSelection.select(gNextMessageViewIndexAfterDelete); + + // if gNextMessageViewIndexAfterDelete has the same value + // as the last index we had selected, the outliner won't generate a + // selectionChanged notification for the outliner view. So force a manual + // selection changed call. (don't worry it's cheap if we end up calling it twice). + if (outlinerView) + outlinerView.selectionChanged(); + + EnsureRowInThreadOutlinerIsVisible(gNextMessageViewIndexAfterDelete); gDBView.suppressCommandUpdating = false; }