On Fri, Apr 17, 2015 at 7:06 AM, Boris Zbarsky wrote:
> On 4/17/15 3:38 AM, Elliott Sprehn 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.
>>
>
> For this specific case, where there
On 17 April 2015 at 08:16, Boris Zbarsky wrote:
>If the API returns a Promise type, return a Promise rejected with
>a TypeError (??). Otherwise, the operation steps MUST fail in some
>way.
>
> Or some such.
SecurityError perhaps. But I still like the idea of an IDL annotation
like [
On 4/17/15 11:13 AM, Anne van Kesteren wrote:
A bunch of the new non-legacy APIs (that is geolocation doesn't count)
have some kind of promise thing you need to get past before things
start working. For those APIs we could have something with normative
language. I don't see how we could make some
On Fri, Apr 17, 2015 at 4:09 PM, Boris Zbarsky wrote:
> I say this because I'm seeing people want to apply this to a variety of
> different APIs which should do a variety of different things in the
> "disabled" state, as far as I can tell.
>
> Am I missing something and there's something more that
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
On 4/17/15 2:44 AM, Mike West wrote:
Either way, expressing the constraint via IDL seems totally reasonable.
OK, so let's say we do the "API is still present but fails somehow"
thing. How would one express that constraint via IDL? What would the
normative language be? It seems like the bes
On 4/17/15 3:38 AM, Elliott Sprehn 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.
For this specific case, where there are only two possibilities
(privileged or not) it seems like you can ju
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 diff
Since we're talking about a binary distinction (privileged vs.
unprivileged), presumably you could just make two snapshots?
On Fri, Apr 17, 2015 at 3:38 AM, Elliott Sprehn
wrote:
> It's preferable not to do that for us because you can then create a static
> heap snapshot at compile time and memc
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
entire
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" wrote:
> On 4/17/15 2:52 AM, Boris Zbarsky wrote:
>
>> If that preference is toggled, we in fact remove the AP
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
On 4/17/15 2:44 AM, Mike West wrote:
Consider Geolocation, for instance: users can disable the API entirely
in Chrome (and, I assume, other browsers). Should we remove the API in
these cases as well?
There's no user-facing UI to disable geolocation in Firefox, but there
is a preference that ca
I'd be fine with this, if it's what folks end up preferring.
That said, throwing/rejecting gives us the opportunity to explain to a
developer _why_ her favorite API isn't available. It's not clear how we'd
help them understand what's going on if we just remove the API entirely.
Consider Geolocati
Soon there will be a number of features that are restricted to
privileged contexts. Most prominent one being service workers.
Within user agents the prevailing pattern is that privileged APIs are
not available in unprivileged contexts. However, both Firefox and
Chrome currently expose the service
15 matches
Mail list logo
