Fixed a possible memory leak and support null pointers in AutomationEventObservers' NotifyEvent.

chrome/browser/automation/automation_event_observers.cc

Index: chrome/browser/automation/automation_event_observers.cc
diff --git a/chrome/browser/automation/automation_event_observers.cc b/chrome/browser/automation/automation_event_observers.cc
index a2e05d326f6bb19eba2c0bbc6ab3c3c6d5d14366..8f2f5acd6d5245aed075e2003d0f3668bc13a650 100644
--- a/chrome/browser/automation/automation_event_observers.cc
+++ b/chrome/browser/automation/automation_event_observers.cc
@@ -29,10 +29,15 @@ AutomationEventObserver::~AutomationEventObserver() {}
 
 void AutomationEventObserver::NotifyEvent(DictionaryValue* value) {
   if (event_queue_) {

[dennis_jeffrey, 2012/05/16 16:55:42]

Will "value" get deleted on the "true" branch of this condition?

[craigdh, 2012/05/16 17:00:55]

Yes. On "true" the AutomationEventQueue takes ownership.

+    if (!value)
+      value = new DictionaryValue;

[dennis_jeffrey, 2012/05/16 16:55:42]

Is this check needed?  It looks like both callers affected by this CL always
create a new DictionaryValue before invoking this function.  What about issuing
an error if the value isn't set by the caller?

[craigdh, 2012/05/16 17:00:55]

Right now NULL is not being passed, but is because both current uses have
additional information to return. In general that seemed like an unnecessary
limitation and now the usage will be more similar to SendSuccess().

+    value->SetInteger("observer_id", GetId());
     event_queue_->NotifyEvent(
         new AutomationEventQueue::AutomationEvent(
             GetId(), value));
     event_count_++;
+  } else if (value) {
+    delete value;
   }
 }
 
@@ -92,7 +97,6 @@ void DomEventObserver::Observe(
       DictionaryValue* dict = new DictionaryValue;
       dict->SetString("type", "raised_event");
       dict->SetString("name", dom_op_details->json);
-      dict->SetInteger("observer_id", GetId());
       NotifyEvent(dict);
     }
   }