[Mac] Inform reference counted objects that hold a weak Browser* when the Browser is being destroye…

chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.h

Index: chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.h
diff --git a/chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.h b/chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.h
index 897c4a8929fb582a3fc4007b746f0396d3b0ed8e..da7670f348c7031ddbd979f64964f49960201e60 100644
--- a/chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.h
+++ b/chrome/browser/ui/cocoa/find_bar/find_bar_cocoa_controller.h
@@ -62,6 +62,9 @@ class FindNotificationDetails;
 // Initializes a new FindBarCocoaController.
 - (id)initWithBrowser:(Browser*)browser;
 
+// Called by BrowserWindowController when the Browser is being destroyed.
+- (void)browserWillBeDestroyed;

[tapted, 2015/07/07 04:25:59]

Hm - I think this is OK to be consistent. But the lifetime is different.

FindBarCocoaController is owned by FindBarBridge which is owned by (wait for
it..) FindBarController, which is plonked into a scoped_ptr held by Browser.

FindBarBridge::~FindBarBridge() will be called reliably. It currently does
`[cocoa_controller_ release];`. It *could* be responsible for the
browserWillBeDestroyed call instead of browser_window_controller.mm. But
actually FindBarBridge and BrowserWindowController each have their own
reference. The one in browser_window_controller.mm will happen first, so I think
that's the way to go. But perhaps it needs a note to say FindBarBridge also has
a reference which will be released later.

I don't think it will make a difference, but only because
Browser::find_bar_controller_ is never destroyed once it is (lazily) created.

[jackhou1, 2015/07/07 08:33:05]

Added note in BrowserWindowController::dealloc

+
 - (void)setFindBarBridge:(FindBarBridge*)findBar;
 
 - (IBAction)close:(id)sender;