On Mon, Oct 24, 2016 at 6:29 PM, Adam Roach <a...@mozilla.com> wrote:
> 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. > This plan sounds fine to me. Thanks for summarizing, Adam. > 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. > +1 --Richard > > /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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
