Make geolocation API and X-Geo header access consistent

chrome/android/java/src/org/chromium/chrome/browser/preferences/website/Website.java

Index: chrome/android/java/src/org/chromium/chrome/browser/preferences/website/Website.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/preferences/website/Website.java b/chrome/android/java/src/org/chromium/chrome/browser/preferences/website/Website.java
index 1d7ad795cce15f3ceaf164b492cb19ccc00cf2bb..030df00a4aa5440e725c0645138aa5b1e37c314f 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/preferences/website/Website.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/preferences/website/Website.java
@@ -206,8 +206,13 @@ public class Website implements Serializable {
      * Configure geolocation access setting for this site.
      */
     public void setGeolocationPermission(ContentSetting value) {
-        if (mGeolocationInfo != null) {
-            mGeolocationInfo.setContentSetting(value);
+        if (WebsitePreferenceBridge.nativeShouldUseDSEGeolocationSetting(
+                    mOrigin.getOrigin(), false)) {
+            WebsitePreferenceBridge.nativeSetDSEGeolocationSetting(value != ContentSetting.BLOCK);

[raymes, 2017/01/09 05:47:26]

hmm could the value passed in here ever be ASK? I guess not but it might be
worth having value == ContentSetting.ALLOW instead to be safe?

[benwells, 2017/01/09 21:02:21]

Yes, it can be ASK - when the user presses the 'reset site' button. My thinking
was that in that case the site should be set back to it's default value, and the
default for the DSE CCTLD is on, hence the != BLOCK.

We should check with the privacy team that the reset button should do this -
I'll email them about it. Maybe it should reset to enable but show the banner
again...

[raymes, 2017/01/10 03:19:32]

Sounds good.

+        } else {
+            if (mGeolocationInfo != null) {
+                mGeolocationInfo.setContentSetting(value);
+            }
         }
     }