mcgreevy - this is the first bug I was talking about. I can walk you through what's needed.

I notice that hasAndroidLocationPermission (here: https://cs.chromium.org/chromium/src/components/location/android/java/src/org/chromium/components/location/LocationUtils.java?rcl=d39d1cfa0ac52ed36acfb9ab3ae66e33ff61e20a&l=66 ) returns whether permission has been granted to access COARSE or FINE location.

In contrast, canPromptForAndroidLocationPermission (here: https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/preferences/LocationSettings.java?rcl=f15f52293342a5d3dfa6fd3be727b2058711c2d3&l=56 ) returns whether FINE location can be requested.

Using the previous two methods, GeolocationPermissionContextAndroid::IsLocationAccessPossible (here: https://cs.chromium.org/chromium/src/chrome/browser/geolocation/geolocation_permission_context_android.cc?rcl=7553e311e032564e696c962c1896b07cc19b226f&l=387 ) decides whether location access is possible based on whether the user (has COARSE || FINE location) OR (can request FINE location).

This seems inconsistent.  Shouldn't canPromptForAndroidLocationPermission also check for whether COARSE location can be requested?


In general it looks like COARSE locations are considered sufficient as a reponse to geolocation.getCurrentPosition calls:

* the geolocation API treats the enableHighAccuracy parmeter as a hint only (https://dev.w3.org/geo/api/spec-source.html#high-accuracy).
* the geolocation permission (https://w3c.github.io/permissions/#geolocation) does not distinguish between COARSE and FINE locations.

Interesting. The FINE and COARSE permissions are asked for in one prompt currently. That is, you get both for the price of one question to the user. I expect if you can request FINE you can request COARSE.

But it is weird that we accept COARSE as having location access. I'd put all this into a separate bug and include dft@, tedchoc@ and myself.

@benwells can you give me the URL of your test site with the prompt/status buttons?

Sure! I just moved it. It now lives at https://benfredwells.github.io/

I've tried to do this plumbing mechanically, without a full understanding of what a RenderFrameHost actually is, but I've hit a snag.

The only call of GeolocationPermissionContextAndroid::UpdatePermissionStatusWithDeviceStatus is from

PermissionStatus PermissionManager::GetPermissionStatus(
    PermissionType permission,
    const GURL& requesting_origin,
    const GURL& embedding_origin) 

(call is here https://cs.chromium.org/chromium/src/chrome/browser/permissions/permission_manager.cc?rcl=79f092fc8747729c369adc0ba85d6a124eba0d06&l=461)

This GetPermissionStatus method is an override of content::PermissionManager::GetPermissionStatus, which has the comment: "This is not taking a RenderFrameHost because the call might happen outside of a frame context":

https://cs.chromium.org/chromium/src/content/public/browser/permission_manager.h?rcl=79f092fc8747729c369adc0ba85d6a124eba0d06&l=69

It sounds like it will be difficult to obtain a RenderFrameHost to pass into GetPermissionStatus, because sometimes there simply isn't one.

@benwells: Is there anything sensible that we can do in GeolocationPermissionContextAndroid::UpdatePermissionStatusWithDeviceStatus if the call "happens outside of a frame context"?  e.g. can we assume in this case that we can't prompt for location?  Should there be a version of GetPermissionStatus that takes a RenderFrameHost, for when it's available?

+raymes

Interesting .... the PermissionManager function is used for many types of permissions, including Notifications. I'm guessing the notifications calls can come from ServiceWorkers, which I'm (also) guessing don't have RenderFrames associated with them (and thus no RenderFrameHosts, which are the browser process representation of this).

For geolocation there should always be a RenderFrame, and if not we could treat it as not being able to prompt for location.

It looks like Raymes has started adding this plumbing: there is already a GetPermissionStatusForFrame, but it doesn't appear to be called from anywhere.

Raymes - what is your plan for GetPermissionStatusForFrame? Is it meant to replace GetPermissionStatus somehow?

Reassigning to raymes; I'm not sure if this is obsolete or not.

Raymes, are you still planning to work on it in the near future, or should we mark this as `Available`?

Marked as available :)