On 4/17/15 7:58 AM, Ashley Gullen wrote:
I think the existence of the API functions should indicate the browser
has the capability, and then the API returns an error if it's not
allowed to be used in the current context. I think this would improve
the quality of messages seen by users, since for example removing the
Geolocation API entirely could result in a web page message like "sorry,
your browser does not support Geolocation, try updating your browser" -
which is incorrect, it really should say something like "geolocation
permission denied".
If the page has a codepath for the denied condition, yes.
This is somewhat more likely for geolocation (which involves explicit
user permission, and the site author may at least consider not being
granted) than for something like webcrypto (where the site author is
likely to just not check for rejection at all).
But even for geolocation, you'd end up with a we page message like
"sorry, you didn't grant permission to use Geolocation, reload the page
and grant it" which is _also_ incorrect: the correct remediation step is
to use HTTPS to load the page. And I bet if the page didn't already
redirect to an SSL version of itself this step is not available to the
user anyway...
I would love it if there were a way here to message to the user that the
page is the thing that's broken (trying to use a privileged feature in a
non-privileged context), but clearly doing that via messaging the _page_
controls is not viable. The browser _could_ put up an infobar, I
suppose, in the case that the API is left in place but triggers
automatic failure if called...
-Boris
