diff --git a/mozilla/widget/src/cocoa/nsAppShell.h b/mozilla/widget/src/cocoa/nsAppShell.h
index 61c49ddba22..a0e96698eeb 100644
--- a/mozilla/widget/src/cocoa/nsAppShell.h
+++ b/mozilla/widget/src/cocoa/nsAppShell.h
@@ -90,6 +90,11 @@ protected:
   // mHadMoreEventsCount and kHadMoreEventsCountMax are used in
   // ProcessNextNativeEvent().
   PRUint32               mHadMoreEventsCount;
+  // Setting kHadMoreEventsCountMax to '10' contributed to a fairly large
+  // (about 10%) increase in the number of calls to malloc (though without
+  // effecting the total amount of memory used).  Cutting it to '3'
+  // reduced the number of calls by 6%-7% (reducing the original regression
+  // to 3%-4%).  See bmo bug 395397.
   static const PRUint32  kHadMoreEventsCountMax = 3;
 };
 
diff --git a/mozilla/widget/src/cocoa/nsAppShell.mm b/mozilla/widget/src/cocoa/nsAppShell.mm
index 3a34fd7c2f4..1733ca4b8e3 100644
--- a/mozilla/widget/src/cocoa/nsAppShell.mm
+++ b/mozilla/widget/src/cocoa/nsAppShell.mm
@@ -414,22 +414,20 @@ nsAppShell::ProcessNextNativeEvent(PRBool aMayWait)
     // combining [NSRunLoop runMode:beforeDate] with [NSApp
     // nextEventMatchingMask:...].
 
-    // We need to special-case timer events (events of type NSPeriodic),
-    // otherwise we will starve them.  (Which can have strange results --
-    // among other things it causes a ~10% increase in the number of calls
-    // to malloc and a ~2% Tdhtml regression.  See bmo bug 396796.)  Apple's
-    // documentation is very scanty, and it's now more scanty than it used to
-    // be.  But it appears that [NSRunLoop acceptInputForMode:beforeDate:]
-    // doesn't process timer events at all, that it is called from
-    // [NSRunLoop runMode:beforeDate:], and that [NSRunLoop runMode:beforeDate:],
-    // though it does process timer events, doesn't return after doing so.
-    // To get around this, when aWait is PR_FALSE we check for timer events
-    // and process them using [NSApp sendEvent:].  When aWait is PR_TRUE
-    // [NSRunLoop runMode:beforeDate:] will only return on a "real" event.
-    // But there's code in ProcessGeckoEvents() that should (when need be)
-    // wake us up by sending a "fake" "real" event.  (See Apple's current doc
-    // on [NSRunLoop runMode:beforeDate:] and a quote from what appears to be
-    // an older version of this doc at
+    // We special-case timer events (events of type NSPeriodic) to avoid
+    // starving them.  Apple's documentation is very scanty, and it's now
+    // more scanty than it used to be.  But it appears that [NSRunLoop
+    // acceptInputForMode:beforeDate:] doesn't process timer events at all,
+    // that it is called from [NSRunLoop runMode:beforeDate:], and that
+    // [NSRunLoop runMode:beforeDate:], though it does process timer events,
+    // doesn't return after doing so.  To get around this, when aWait is
+    // PR_FALSE we check for timer events and process them using [NSApp
+    // sendEvent:].  When aWait is PR_TRUE [NSRunLoop runMode:beforeDate:]
+    // will only return on a "real" event.  But there's code in
+    // ProcessGeckoEvents() that should (when need be) wake us up by sending
+    // a "fake" "real" event.  (See Apple's current doc on [NSRunLoop
+    // runMode:beforeDate:] and a quote from what appears to be an older
+    // version of this doc at
     // http://lists.apple.com/archives/cocoa-dev/2001/May/msg00559.html.)
 
     // If the current mode is something else than NSDefaultRunLoopMode, look