[Mac] Create CrTrackingArea and use it in TabStripController.

chrome/browser/ui/cocoa/chrome_tracking_area.h

Index: chrome/browser/ui/cocoa/chrome_tracking_area.h
diff --git a/chrome/browser/ui/cocoa/chrome_tracking_area.h b/chrome/browser/ui/cocoa/chrome_tracking_area.h
new file mode 100644
index 0000000000000000000000000000000000000000..61bd0c39d6d0288f3cca8d096c45129b05919ad4
--- /dev/null
+++ b/chrome/browser/ui/cocoa/chrome_tracking_area.h
@@ -0,0 +1,37 @@
+// Copyright (c) 2011 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_BROWSER_UI_COCOA_CHROME_TRACKING_AREA_H_
+#define CHROME_BROWSER_UI_COCOA_CHROME_TRACKING_AREA_H_
+
+#import <AppKit/AppKit.h>
+
+#include "base/scoped_nsobject.h"
+
+@class CrTrackingAreaOwnerProxy;
+
+// The CrTrackingArea can be used in place of an NSTrackingArea to shut off
+// messaging to the |owner| at a specific point in time.
+@interface CrTrackingArea : NSTrackingArea {
+ @private
+  scoped_nsobject<CrTrackingAreaOwnerProxy> ownerProxy_;

[Scott Hess - ex-Googler, 2011/02/11 01:17:12]

Rather than using |ownerProxy_|, you can override -owner to return nil after
clear has been called.

[Robert Sesek, 2011/02/11 02:30:50]

I went with this approach because it affords us better debugging options (e.g.,
you mentioned doing backtrace serialization). The proxy approach is also useful
for probing live in the debugger, assuming you can repro. And, NSProxy is cool
;-).

[Robert Sesek, 2011/02/11 19:53:58]

Switched to this approach. Closer examination showed that
|-methodSignatureForSelector:| can still end up messaging a zombie. Which left
me with three options:

1) Retain the owner in ownerProxy_. That diverges from the expectation of
NSTrackingArea, which I don't like.
2) Override |-doesNotRecognizeSelector:| and do nothing if |!alive_|.
3) Ditch the proxy and just wrap |-owner|.

The last option seemed like the sanest. My only concern is if they use the ivar
directly rather than the accessor anywhere.

[Scott Hess - ex-Googler, 2011/02/11 20:08:19]

AFAICT from tracing messages, -mouseMoved: calls -owner a couple times, so I'd
be surprised if it directly uses the iVar.  That said, we could always override
-mouseMoved: itself to short-circuit things.

I'm not so concerned (at this point) about solving the problem of messaging the
zombie object as I am about figuring out if there really are cases where
removing a tracking rect can result in later tracking messages, and trying to
get an angle on how things get to this spot.

+}
+
+// Designated initializer. Forwards all arguments to the superclass, but wraps
+// |owner| in a proxy object.
+- (id)initWithRect:(NSRect)rect
+           options:(NSTrackingAreaOptions)options
+             owner:(id)owner
+          userInfo:(NSDictionary*)userInfo;
+
+// Prevents any future messages from being delivered to the |owner|.
+- (void)clearOwner;
+
+// Watches |window| for its NSWindowWillCloseNotification and calls
+// |-clearOwner| when the notification is observed.
+- (void)clearOwnerWhenWindowWillClose:(NSWindow*)window;
+
+@end
+
+#endif  // CHROME_BROWSER_UI_COCOA_CHROME_TRACKING_AREA_H_