Fix use-after-free of Profile after it's been destroyed.

chrome/browser/ui/views/accessibility/accessibility_event_router_views.h

Index: chrome/browser/ui/views/accessibility/accessibility_event_router_views.h
diff --git a/chrome/browser/ui/views/accessibility/accessibility_event_router_views.h b/chrome/browser/ui/views/accessibility/accessibility_event_router_views.h
index 954ba950f2db20598caf815bcb1592d0bd618f93..2488a64d7276cf6a9d08025fae4b66b5eee73609 100644
--- a/chrome/browser/ui/views/accessibility/accessibility_event_router_views.h
+++ b/chrome/browser/ui/views/accessibility/accessibility_event_router_views.h
@@ -9,14 +9,20 @@
 
 #include "base/basictypes.h"
 #include "base/gtest_prod_util.h"
+#include "base/memory/scoped_ptr.h"
 #include "base/string16.h"
 #include "chrome/browser/accessibility/accessibility_events.h"
+#include "content/public/browser/notification_observer.h"
 #include "ui/base/accessibility/accessibility_types.h"
 
 class Profile;
 
 template <typename T> struct DefaultSingletonTraits;
 
+namespace content {
+class NotificationRegistrar;
+}
+
 namespace views {
 class View;
 }
@@ -36,7 +42,7 @@ class View;
 //
 // You can use Profile::PauseAccessibilityEvents to prevent a flurry
 // of accessibility events when a window is being created or initialized.
-class AccessibilityEventRouterViews {
+class AccessibilityEventRouterViews : public content::NotificationObserver {
  public:
   // Internal information about a particular view to override the
   // information we get directly from the view.
@@ -65,6 +71,11 @@ class AccessibilityEventRouterViews {
                              int item_count,
                              bool has_submenu);
 
+  // NotificationObserver implementation.
+  virtual void Observe(int type,
+                       const content::NotificationSource& source,
+                       const content::NotificationDetails& details) OVERRIDE;
+
  private:
   friend struct DefaultSingletonTraits<AccessibilityEventRouterViews>;
 
@@ -152,6 +163,10 @@ class AccessibilityEventRouterViews {
   // figure out where to route a few events that can't be directly traced
   // to a window with a profile (like menu events).
   Profile* most_recent_profile_;
+
+  // Notification registrar so we can clear most_recent_profile_ when a
+  // profile is destroyed.
+  scoped_ptr<content::NotificationRegistrar> registrar_;

[Lei Zhang, 2013/04/03 21:56:49]

Any particular reason for making it a scoper? Most code I have read just
declares it as: <content::NotificationRegistrar registrar_;

[dmazzoni, 2013/04/03 22:02:29]

One less include in a header file?

I have no strong preference, I got rid of the scoped_ptr.

 };
 
 #endif  // CHROME_BROWSER_UI_VIEWS_ACCESSIBILITY_ACCESSIBILITY_EVENT_ROUTER_VIEWS_H_