Implement getting notifications up to the browser process.

content/child/notifications/notification_dispatcher.cc

Index: content/child/notifications/notification_dispatcher.cc
diff --git a/content/child/notifications/notification_dispatcher.cc b/content/child/notifications/notification_dispatcher.cc
index 5949972019f8e01f46f31136a38b3e7730de56fe..4441a2cf95073626c9ef142fd0cc18bffa1efe7c 100644
--- a/content/child/notifications/notification_dispatcher.cc
+++ b/content/child/notifications/notification_dispatcher.cc
@@ -5,19 +5,20 @@
 #include "content/child/notifications/notification_dispatcher.h"
 
 #include "content/child/notifications/notification_manager.h"
-#include "content/common/platform_notification_messages.h"
 
 namespace content {
 
 NotificationDispatcher::NotificationDispatcher(
     ThreadSafeSender* thread_safe_sender)
-    : WorkerThreadMessageFilter(thread_safe_sender), next_notification_id_(0) {
+    : WorkerThreadMessageFilter(thread_safe_sender) {
 }
 
 NotificationDispatcher::~NotificationDispatcher() {}
 
 int NotificationDispatcher::GenerateNotificationId(int thread_id) {
   base::AutoLock lock(notification_id_map_lock_);
+  CHECK_GE(next_notification_id_, 0);

[johnme, 2015/03/19 16:26:59]

If a legit website polls at 60 FPS for just over 1 year, it might overflow this.
But I guess at least it would only crash the renderer.

[Tom Sepez, 2015/03/19 18:10:18]

Just wondering why this is a signed type in the first place?

[Peter Beverloo, 2015/03/19 18:17:00]

I initially introduced it as such for consistency with other features, which
already did what I'm introducing with this patch - the key type for base's IDMap
(base/id_map.h) is an int32, so changing this to either uint32_t or int64_t
would cause problems there.

Perhaps we should consider making an IDMap's KeyType an optional template
argument?

+
   notification_id_map_[next_notification_id_] = thread_id;
   return next_notification_id_++;
 }