This is an animated GIF. You need to click it to see the animation because of how this issue tracker works.

Please try this in the latest Canary. I can repro this in stable, but in Canary, I see the blocked location icon in the Omnibox right away and no prompt.

This is a bug in the inheritance behavior. It only happens if you have a setting set for the website (in your example you must have allowed geolocation for google.com outside of incognito). The problem is here:
https://cs.chromium.org/chromium/src/components/content_settings/core/browser/host_content_settings_map.cc?rcl=635e85a903f436d4722aa34164b8f7cebb78d8a3&l=139

Inheritance behavior is computed on a per-provider basis. If the setting retrieved from a particular provider is more permissive than the Chrome-default then we will simply return the Chrome-default. That means that we never make it to the default provider in the loop through the providers. I think that may not be what we want because there may be a less-permissive user setting that can be used.

I think the fix here would be to return nullptr if the setting is more permissive, which would go in to the next provider, which may have a less-permissive setting we can use. If we get through all the providers and haven't found one then we would return the Chrome-default.

I don't think this bug is a big privacy risk as the factory defaults are safe, and it will only happen if the user has already granted access outside of incognito.

dullweber/msramek: could you ptal? 

I think there are two possiblities for inheritance:

If the current setting is more permissive than factory default,
 1. ... reduce to factory default (current behavior)
 2. ... reduce to user defined default (suggested)

The user defined behavior is always safe as it can only be less permissive than factory default.

I'm not sure if 2. is really better than 1. because I might have allowed geolocation for maps but blocked  everything else by default.
Now, when I go to maps in incognito, I would probably like to enable geolocation, so getting the permission prompt would be useful. 
On the other hand, we are serving maps on google.com and not on a separate origin, so there are some other services on this origin that don't neccessarily require geolocation permission and still ask for it.

For other websites it probably also depends on whether the origin ist just serving a site that really needs geolocation or whether it is just needed sometimes but the site asks other times as well.

I think this applies across permissions, not just for location. Personally I think 2 is slightly better behavior. 

> I'm not sure if 2. is really better than 1. because I might have allowed geolocation for maps but blocked  everything else by default.
Now, when I go to maps in incognito, I would probably like to enable geolocation, so getting the permission prompt would be useful. 

I would argue that if you have permission disabled by default, you're expecting to have to explicitly whitelist it for each origin you visit in regular mode. So in incognito, I think your expectations would probably be the same - i.e. that you have to whitelist each individual site you visit (rather than getting a prompt).

However I don't think this is particularly high priority. I'm happy to leave it with you to decide on what approach to take.

engedy@,

Would you like to take a look for triaging?
It is expected behavior, but there might be a way to reduce the chance of user confusion.

I close this bug as it's desired behavior, but I will put doing something to reduce user confusion in incognito plans.