Introduce runtime.onSuspendCanceled() event.

chrome/browser/extensions/extension_event_router.cc

Index: chrome/browser/extensions/extension_event_router.cc
diff --git a/chrome/browser/extensions/extension_event_router.cc b/chrome/browser/extensions/extension_event_router.cc
index 89df410adebcb0fe29bad3c8df95d869da556085..ec1af019b23eb7ca65aa5da95800770777bce9cc 100644
--- a/chrome/browser/extensions/extension_event_router.cc
+++ b/chrome/browser/extensions/extension_event_router.cc
@@ -436,6 +436,8 @@ void ExtensionEventRouter::DispatchEventToProcess(
     return;
   }
 
+  CancelSuspend(listener_profile, extension);

[koz (OOO until 15th September), 2012/07/19 06:52:12]

mpcomplete@: I'm assuming that this is the only place I need to cancel
suspension here, because this is the only place where IncrementInFlightEvents()
is called in this class, ie: any other events that get dispatched through this
class aren't participating in this keepalive scheme and so wouldn't cause an
onSuspendCancel(). Is that a valid assumption?

[Matt Perry, 2012/07/19 21:36:22]

It depends on what we want to cancel a suspend. Just events? Then this is good.
Should we include a message sent by a content script (probably)? Then you need
to add it to the MessageService. Should we include a user inspecting the event
page (probably)?

The central location for all of these is
LazyBackgroundTaskQueue::AddPendingTask. I haven't vetted every call site, so
I'm not sure if we want to include everything as something that can cancel a
suspend event.

Things that definitely should *not* cancel a suspend (but would otherwise modify
the keepalive count) are things like any API calls or network requests made by
the extension.

[koz (OOO until 15th September), 2012/07/20 06:08:09]

My reading of ExtensionMessageService indicates that creating a channel
increments the lazy keepalive count, but sending messages through a channel
doesn't; they don't need to because the channel they're going over is already
pinning the background page as active. So I've made the calls there to
IncrementLazyKeepaliveCount() be of the "suspend canceling" variety, which
should give us the right behaviour.

As for the dev tools, it seems that that logic is handled in
ExtensionProcessManager's Observe() function, so to make the dev tools behave
correctly here we just need to make their Increment a suspend canceling one,
too.

[Matt Perry, 2012/07/20 18:04:17]

After thinking about it some more, I think it makes the most sense to cancel the
suspend within LazyBackgroundTaskQueue::AddPendingTask. Logically, anything that
would normally restart the event page should also prevent it from closing. Stuff
that merely keeps it alive (like network requests and extension API calls) does
not fall in that category.

Sorry for not thinking this through earlier. I think it will be cleaner and
easier to reason about this way, though.

+
   DispatchEvent(process, extension_id,
                 event->event_name, *event_args,
                 event->event_url, event->user_gesture,
@@ -443,6 +445,15 @@ void ExtensionEventRouter::DispatchEventToProcess(
   IncrementInFlightEvents(listener_profile, extension);
 }
 
+void ExtensionEventRouter::CancelSuspend(Profile* profile,
+                                         const Extension* extension) {
+  if (extension->has_lazy_background_page()) {
+    ExtensionProcessManager* pm =
+        extensions::ExtensionSystem::Get(profile)->process_manager();
+    pm->CancelSuspend(extension);
+  }
+}
+
 bool ExtensionEventRouter::CanDispatchEventToProfile(
     Profile* profile,
     const Extension* extension,