From a0731377443e91efb3835ef0eb3efd2f56d8595e Mon Sep 17 00:00:00 2001 From: "mscott%netscape.com" Date: Tue, 27 Nov 2001 21:45:41 +0000 Subject: [PATCH] Bug #112220 avoid an extra firing of the on select outliner handler when deleting a message. Supress command updating when selecting the next message after a delete r=bienvenu rs=sspitzer git-svn-id: svn://10.0.0.236/trunk@109032 18797224-902f-48f8-a5cc-f745e15eee43 --- .../base/resources/content/msgMail3PaneWindow.js | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/mozilla/mailnews/base/resources/content/msgMail3PaneWindow.js b/mozilla/mailnews/base/resources/content/msgMail3PaneWindow.js index fcd7a32c8da..8f5a435aa13 100644 --- a/mozilla/mailnews/base/resources/content/msgMail3PaneWindow.js +++ b/mozilla/mailnews/base/resources/content/msgMail3PaneWindow.js @@ -269,14 +269,14 @@ function HandleDeleteOrMoveMsgCompleted(folder) // optimize away. if (gNextMessageViewIndexAfterDelete != -1) { + // when deleting a message we don't update the commands when the selection goes 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 + // have the right update state... + gDBView.suppressCommandUpdating = true; outlinerSelection.select(gNextMessageViewIndexAfterDelete); - // since gNextMessageViewIndexAfterDelete probably has the same value - // as the last index we had selected, the outliner isn't generating a new - // selectionChanged notification for the outliner view. So we aren't loading the - // next message. to fix this, force the selection changed update. - if (outlinerView) - outlinerView.selectionChanged(); EnsureRowInThreadOutlinerIsVisible(gNextMessageViewIndexAfterDelete); + gDBView.suppressCommandUpdating = false; } else {