Okay, maybe it makes more sense for it to be 1, based on the MDN description, but the behavior still is inconsistent with Safari.

I'm not sure who is wrong here. It would be great if both behaved the same though.

Reporter@ - Thanks for filing the issue...!!

Could you please provide a sample URL(insecure http origin) or consistent manual repro steps to test this issue.

This will help us in triaging the issue further.

Thanks...!!

Somehow my comments are getting auto deleted...

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please use the URL in the images. I tried putting it in a comment, but they are all getting auto deleted.

Deleted: Screen Shot 2017-03-19 at 1.52.07 PM.png 29.8 KB

	Screen Shot 2017-03-19 at 1.52.07 PM.png 29.8 KB View Download

Deleted: Screen Shot 2017-03-19 at 1.52.18 PM.png 36.3 KB

	Screen Shot 2017-03-19 at 1.52.18 PM.png 36.3 KB View Download

For context, iOS 10 and Safari 10 on desktop have restricted geolocation to secure contexts (see https://trac.webkit.org/changeset/200686). The error codes in question are:

error code 1: the page doesn't have permission to access geolocation

error code 2: unspecified internal error

Strictly speaking, I think error code 1 is correct, and a conscious decision was made when geolocation was restricted to secure origins that trying to access it from HTTP would be treated exactly like the user denying permission. Semantically, error code 1 is correct, because HTTP pages are not allowed to access location.

+other permissions folks for their thoughts. Perhaps someone should follow up with WebKit to see what their reasoning is for using error code 2, but I lean towards keeping error code 1 here (and asking if WebKit wants to move to 1 as well).

I agree with #10.

To the OP - is this causing any practical problems i.e. making it hard to do something in particular?

Also, we'll try and find out what's happening with the comments being auto-deleted. Was it just comments containing URLs?

I don't really like choosing between two bad error codes. I think we should be using "SecurityError" if one existed on PositionError.

Should we mark this as WontFix given analysis in #10, or is someone (dougt or jyasskin) still looking into this?

The right thing to do is figure out a way to update the specification and return a better error code that accurately reflect the failure type. jyasskin, what do you think?

I want to standardize with Safari and update the spec to describe what happens here, but I don't think we should add a new error code that existing uses of geolocation aren't expecting.

We're talking about how to update abandoned specs in the standards-team meeting next Thursday.

Next step: Find a place to create a specification issue to address this unspecified behavior.

The Spec says [1]:

> PERMISSION_DENIED (numeric value 1)
> The location acquisition process failed because the document does not have permission to use the Geolocation API.
> POSITION_UNAVAILABLE (numeric value 2)
> The position of the device could not be determined. For instance, one or more of the location providers used 
> in the location acquisition process reported an internal error that caused the process to fail entirely.

So, to me Cr response is the correct one.  I filed an issue [2] on the Spec to
make this more evident (that PERMISSION_DENIED is expected when trying to
access Geolocation from an insecure origin), but otherwise this sounds like
an interop issue.  Is there an external/wpt test for this?


[1] http://w3c.github.io/geolocation-api/spec-source.html#position_error_interface
[2] https://github.com/w3c/geolocation-api/issues/12