Have ExtensionHost use TabContents instead of RenderViewHost. Try #3.

chrome/browser/geolocation/chrome_geolocation_permission_context.cc

Index: chrome/browser/geolocation/chrome_geolocation_permission_context.cc
diff --git a/chrome/browser/geolocation/chrome_geolocation_permission_context.cc b/chrome/browser/geolocation/chrome_geolocation_permission_context.cc
index 0328da96f26692af8389ef391a65eff445410b25..dfe6bf0576ca5dc19f8c4579be0b320d2f5aa7ac 100644
--- a/chrome/browser/geolocation/chrome_geolocation_permission_context.cc
+++ b/chrome/browser/geolocation/chrome_geolocation_permission_context.cc
@@ -541,8 +541,12 @@ void ChromeGeolocationPermissionContext::RequestGeolocationPermission(
 
   TabContents* tab_contents =
       tab_util::GetTabContentsByID(render_process_id, render_view_id);
-  if (!tab_contents) {
+  if (!tab_contents ||
+      tab_contents->GetRenderViewType() != content::VIEW_TYPE_TAB_CONTENTS) {

[Matt Perry, 2011/11/16 21:44:10]

This fixes the geolocation bug I mentioned.

[Aaron Boodman, 2011/11/16 23:29:24]

This seems like it could be a breaking change. I vaguely recall that it is
possible to dynamically request geolocation this way from an extension
background page today.

[Matt Perry, 2011/11/16 23:36:32]

That's handled by the block above - we only reach here if the extension doesn't
have permission (or it's not an extension).

[Aaron Boodman, 2011/11/16 23:42:23]

Right, what I mean is that I worry that before it may have been possible to have
an extension that does _not_ have geolocation API permission in the manifest,
and call whatever the JS function is to request permission, and you'd get the
infobar and everything would work.

[Matt Perry, 2011/11/16 23:46:06]

I see. There was a test that broke without this change (marked flaky so I didn't
catch it), but that suite is now happy.

Also, just based on the code, I'm pretty sure this is equivalent to the behavior
before my refactor. There was no associated tab for a BG page or popup before,
which are the only cases where the tab's view_type is not TAB_CONTENTS.

     // The tab may have gone away, or the request may not be from a tab at all.
+    // TODO(mpcomplete): the request could be from a background page or
+    // extension popup (tab_contents will have a different ViewType). But why do
+    // we care? Shouldn't we still put an infobar up in the current tab?

[joth, 2011/11/17 08:58:33]

I don't quite understand this last question: are you suggesting that an
extension background page should cause whatever tab happens to be focused to get
an info bar? In the current focused window or all windows? What if I change or
close tab?

My understanding was extensions either request (and get) permission at install
time or they don't and that's it. No runtime popups permitted.
The geolocation UI is very much targetted to the tab it is in requesting
permission, and is already complicated by the corner case of an embedded frame
(from differing origin) requesting permission. I wouldn't want to complicate it
further with non-tab related things unless the UX team really intend it to.

[Matt Perry, 2011/11/17 20:08:04]

Thanks, your explanation answers my question.

On 2011/11/17 08:58:33, joth wrote:

     LOG(WARNING) << "Attempt to use geolocation tabless renderer: "
                  << render_process_id << "," << render_view_id << ","
                  << bridge_id << " (can't prompt user without a visible tab)";

[joth, 2011/11/17 08:58:33]

assuming this warning is useful, it would be as well to include (tab_contents ?
tab_contents->GetRenderViewType() : -1) in it too.