Take 2 at implementing activeTab.

chrome/common/extensions/extension_messages.h

Index: chrome/common/extensions/extension_messages.h
diff --git a/chrome/common/extensions/extension_messages.h b/chrome/common/extensions/extension_messages.h
index 42aab16e12d5cfcbfb4ef791c42cb26a612add36..1573c602534155bc3c45d57c9e256af7dde79ec8 100644
--- a/chrome/common/extensions/extension_messages.h
+++ b/chrome/common/extensions/extension_messages.h
@@ -125,6 +125,9 @@ struct ExtensionMsg_Loaded_Params {
   URLPatternSet explicit_hosts;
   URLPatternSet scriptable_hosts;
 
+  // The extension's tab-specific host permissions.
+  std::map<int, URLPatternSet> tab_specific_host_permissions;

[Aaron Boodman, 2012/06/08 05:31:30]

I'm curious how this part is going to work when you take out the cross-origin
XHR support. Only two renderers are going to care about this information then.
Are you just going to leave the member in the message, but only populate it for
certain renderers?

[not at google - send to devlin, 2012/06/12 20:40:51]

Yeah, good point.

Actually, in the world of not caring about XHR, I'm not sure that anybody cares
about it.  As in, the tab cares about it, but if this is the tab being created
then presumably nothing has clicked on it yet, so.... yeah.

And the background page cares as much as any other renderer that isn't the
tab's, which is to say, not at all.

+
   // We keep this separate so that it can be used in logging.
   std::string id;
 
@@ -238,6 +241,10 @@ IPC_MESSAGE_ROUTED1(ExtensionMsg_GetApplicationInfo,
 IPC_MESSAGE_ROUTED1(ExtensionMsg_UpdateBrowserWindowId,
                     int /* id of browser window */)
 
+// Tell the renderer what its tab ID is.

[Aaron Boodman, 2012/06/08 05:31:30]

Technically its the render *view* that has a tab ID. The comment for the message
above is also wrong.

[not at google - send to devlin, 2012/06/12 20:40:51]

Done.

+IPC_MESSAGE_ROUTED1(ExtensionMsg_SetTabId,
+                    int /* id of tab */)
+
 // Tell the renderer to update an extension's permission set.
 IPC_MESSAGE_CONTROL5(ExtensionMsg_UpdatePermissions,
                      int /* UpdateExtensionPermissionsInfo::REASON */,
@@ -246,6 +253,18 @@ IPC_MESSAGE_CONTROL5(ExtensionMsg_UpdatePermissions,
                      URLPatternSet /* explicit_hosts */,
                      URLPatternSet /* scriptable_hosts */)
 
+// Tell the renderer about new tab-specific permissions for an extension.

[Aaron Boodman, 2012/06/08 05:31:30]

It seems like this duplicates the functionality of the new member in
ExtensionMsg_ExtensionsLoaded. Can you use this for both cases? I don't think an
extra IPC at renderer startup is a big deal.

[not at google - send to devlin, 2012/06/12 20:40:51]

It would be a bit awkward to re-use it, but it's moot anyway because I removed
it from Loading.

I'm going to rename this "Update" by the way, to match the other IPC.

+IPC_MESSAGE_CONTROL4(ExtensionMsg_SetTabSpecificPermissions,
+                     int32 /* page_id (only relevant for the target tab) */,
+                     int /* tab_id */,
+                     std::string /* extension_id */,
+                     URLPatternSet /* host */)
+
+// Tell the renderer to clear tab-specific permissions for some extensions.
+IPC_MESSAGE_CONTROL2(ExtensionMsg_ClearTabSpecificPermissions,
+                     int /* tab_id */,
+                     std::vector<std::string> /* extension_ids */)
+
 // Tell the renderer which type this view is.
 IPC_MESSAGE_ROUTED1(ExtensionMsg_NotifyRenderViewType,
                     chrome::ViewType /* view_type */)