Intent to ship: Restrict geolocation.watchPosition to secure contexts

[Richard Barnes]

This is clearly a powerful feature, so it's a natural candidate for
restriction. Chromium is restricting all of navigator.geolocation as of 50:

https://codereview.chromium.org/1530403002/

Our telemetry shows that only ~0.1% of the usage of watchPosition() is in
non-secure contexts.

http://mzl.la/1VEBbZq

That's low enough that we should go ahead and turn it off.

I have filed Bug 1266494 to track this issue.

[Chris Peterson]

On 4/21/16 11:00 AM, Richard Barnes wrote:
> This is clearly a powerful feature, so it's a natural candidate for
> restriction. Chromium is restricting all of navigator.geolocation as of 50:
>
> https://codereview.chromium.org/1530403002/

Just to be clear, Firefox will still allow getCurrentPosition() in
non-secure contexts?

> Our telemetry shows that only ~0.1% of the usage of watchPosition() is in
> non-secure contexts.
>
> http://mzl.la/1VEBbZq
>
> That's low enough that we should go ahead and turn it off.

Curiously, getCurrentPosition() is called in non-secure contexts 77% of
the time, compared to watchPosition()'s 0.12%.

I would have assumed that getCurrentPosition() is used much more often
than watchPosition(), as most map sites only need a one-shot location.
However, telemetry shows getCurrentPosition() has sample count 10M with
metric count ~1M compared to watchPosition() has sample count 39M and
metric count 488K. Why the disparity? Why does watchPosition() have 4x
sample count but only half the metric count? I wondered whether
watchPosition() was incorrectly recording telemetry on every watch
callback, but the code looks like it is doing the right thing.