I'm hearing general agreement that we think turning this off is the
right thing to do; that maintaining compatibility with Chrome's behavior
is important (since that's what existing code will presumably be tested
against); and -- as bz points out -- we don't want to throw an exception
here for spec compliance purposes. I propose that we move forward with a
plan to immediately deny permission in non-secure contexts. Kan-Ru's
proposal that we put this behind a pref seems like a good one -- that
way, if we discover that something unexpected happens in deployment,
it's a very simple fix to go back to our current behavior.
I would be hesitant to over-analyze additional complications, such as
https-everywhere or user education on this topic. We are, after all,
simply coming into alignment with the rest of the web ecosystem here.
/a
On 10/22/16 12:05, Ehsan Akhgari wrote:
On 2016-10-22 10:16 AM, Boris Zbarsky wrote:
On 10/22/16 9:38 AM, Richard Barnes wrote:
I'm not picky about how exactly we turn this off, as long as the
functionality goes away. Chrome and Safari both immediately call the
error
handler with the same error as if the user had denied permission. We
could
do that too, it would just be a little more code.
Uh... What does the spec say to do?
It seems like the geolocation spec just says the failure callback needs
to be called when permission is defined, with the PERMISSION_DENIED
code, but doesn't mention anything about non-secure contexts. The
permissions spec explicitly says that geolocation *is* allowed in
non-secure contexts <https://w3c.github.io/permissions/#geolocation>.
The most relevant thing I can find is
<https://w3c.github.io/webappsec-secure-contexts/#legacy-example>, which
is an implementation consideration. But as far as I can tell, this is
not spec'ed.
Your intent, and the whole "sites that would break are already broken"
thing sounded like we were going to match Chrome and Safari behavior; if
that was not the plan you really needed to explicitly say so!
Yes, indeed. It seems that making Navigator.geolocation [SecureContext]
is incompatible with their implementation.
We certainly should not be shipping anything that will change behavior
here to something _different_ from what Chrome and Safari are shipping,
assuming they are shipping compatible things. Again, what does the spec
say to do?
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Adam Roach
Principal Engineer, Mozilla
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
