On the one hand, I like the idea of giving developers and users better information about why things are failing. On the other hand, it seems unpleasant to make every API that is so restricted accommodate a "failing because of non-privileged context" modality, which they will undoubtedly do in different ways. On Fri, Apr 17, 2015 at 7:58 AM, Ashley Gullen <ashley@scirra.com> 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". > > > On 17 April 2015 at 08:38, Elliott Sprehn <esprehn@chromium.org> wrote: > >> It's preferable not to do that for us because you can then create a >> static heap snapshot at compile time and memcpy to start JS contexts faster. >> On Apr 17, 2015 12:03 AM, "Boris Zbarsky" <bzbarsky@mit.edu> wrote: >> >>> On 4/17/15 2:52 AM, Boris Zbarsky wrote: >>> >>>> If that preference is toggled, we in fact remove the API entirely, so >>>> that "'geolocation' in navigator" tests false. >>>> >>> >>> Oh, I meant to mention: this is more web-compatible than having the API >>> entrypoints throw, because it can be object-detected. Of course we could >>> have made the API entrypoints just always reject the request instead, I >>> guess; removing the API altogether was somewhat simpler to do. >>> >>> -Boris >>> >>> >>> >
Received on Friday, 17 April 2015 14:05:20 UTC