Re: Privileged context features and JavaScript
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 can be changed in about:config and there are some instructions for how to change that preference in about:rights on some Firefox platforms (e.g. Firefox on Android). If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. -Boris
Re: Privileged context features and JavaScript
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
Re: Privileged context features and JavaScript
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 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? Either way, expressing the constraint via IDL seems totally reasonable. -mike On Apr 17, 2015 07:19, Anne van Kesteren ann...@annevk.nl wrote: 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 worker API everywhere, it just happens to reject. Should we change this and simply not expose the API in unprivileged contexts? E.g. through IDL syntax? That way we don't have to carefully secure all access points. -- https://annevankesteren.nl/
Re: Privileged context features and JavaScript
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 bzbar...@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
Re: JSON imports?
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com wrote:
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
{ foo: bar }
/script
```
```js
document.getElementById(foo).json // or whatever
document.getElementById(bar).json
```
Re: JSON imports?
Basic feature like this shouldn't rely on a custom solution. However, it does
mean that if browsers implement this, it's easily polyfillable.
On Apr 17, 2015, at 9:23 PM, Wilson Page wilsonp...@me.com wrote:
Sounds like something you could write yourself with a custom-elements. Yay
extensible web :)
On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com
mailto:matthewwr...@gmail.com wrote:
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
{ foo: bar }
/script
```
```js
document.getElementById(foo).json // or whatever
document.getElementById(bar).json
```
Re: JSON imports?
Sounds like something you could write yourself with a custom-elements. Yay
extensible web :)
On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com wrote:
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
{ foo: bar }
/script
```
```js
document.getElementById(foo).json // or whatever
document.getElementById(bar).json
```
Re: Privileged context features and JavaScript
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 espr...@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 bzbar...@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
Re: Privileged context features and JavaScript
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 espr...@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 bzbar...@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
Re: Privileged context features and JavaScript
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 ash...@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 espr...@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 bzbar...@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
Re: Privileged context features and JavaScript
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 just have two different snapshots and pick the right one. I agree this uses more memory; there are all sorts of tradeoffs here. But yes, this is an argument against having any sort of dynamic behavior. In the case of Gecko, we have to have _something_ somewhat dynamic anyway, since we expose APIs to extensions that we don't expose to web pages... which I'm sure you do too. -Boris
Re: Privileged context features and JavaScript
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 best you can do in this situation is an IDL annotation that has no actual behavior implications of its own but serves as a warning to the spec reader to carefully read the prose for what the behavior implications are, right? 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 such an annotation could do? -Boris
Re: Privileged context features and JavaScript
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
Re: Privileged context features and JavaScript
On Fri, Apr 17, 2015 at 4:09 PM, Boris Zbarsky bzbar...@mit.edu 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 such an annotation could do? 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 something work for all possible APIs (unless we do the hiding thing). -- https://annevankesteren.nl/
Re: Privileged context features and JavaScript
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 something work for all possible APIs (unless we do the hiding thing). OK, so the annotation could be defined as something like adding the following to the operation (and maybe attribute getter?) steps in WebIDL: 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. -Boris
Re: Privileged context features and JavaScript
On Fri, Apr 17, 2015 at 7:06 AM, Boris Zbarsky bzbar...@mit.edu 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 are only two possibilities (privileged or not) it seems like you can just have two different snapshots and pick the right one. I agree this uses more memory; there are all sorts of tradeoffs here. But yes, this is an argument against having any sort of dynamic behavior. In the case of Gecko, we have to have _something_ somewhat dynamic anyway, since we expose APIs to extensions that we don't expose to web pages... which I'm sure you do too. In Blink, we don't include host objects in our snapshot anyway, so this point is probably moot for web APIs. Or at least it's moot until more things are self-hosted. - Adam
[Bug 28505] New: Synchronous XHR removal makes patching Error.prepareStackTrace impossible
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28505 Bug ID: 28505 Summary: Synchronous XHR removal makes patching Error.prepareStackTrace impossible Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XHR Assignee: ann...@annevk.nl Reporter: evan@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org I've got a library that fixes Error.prototype.stack in V8 to work with source maps because Google refuses to fix this themselves (http://crbug.com/376409). However, it's recently come to my attention (https://github.com/evanw/node-source-map-support/issues/49) that this is about to break due to removal of synchronous XHR (https://xhr.spec.whatwg.org/#sync-warning). Because of the way the API Error.prepareStackTrace API works, I need to fetch the source map before returning from the callback. I can't know what the URLs will be ahead of time and fetch them because 1) errors may happen before the source map download completes and 2) new code with the //# sourceMappingURL pragma can be created with eval at any time. I understand the goals of removing synchronous XHR but my library legitimately needs this feature. Breaking this feature will greatly harm debugging for languages that are cross-compiled to JavaScript. The slowness of synchronous XHR doesn't matter here because it's just for debugging, not for production environments. What are people's thoughts on this? Is there maybe some way to add a way in the spec to still allow synchronous XHR in certain circumstances? -- You are receiving this mail because: You are on the CC list for the bug.
Re: Privileged context features and JavaScript
On 17 April 2015 at 08:16, Boris Zbarsky bzbar...@mit.edu 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 [SecureContext] that causes the API to disappear as though not implemented.
Re: JSON imports?
One benefit is that browsers can start downloading it asap, instead of waiting
util the fetch code is executed (which could itself be in a separate file).
On Apr 18, 2015, at 8:41 AM, Elliott Sprehn espr...@chromium.org wrote:
On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Basic feature like this shouldn't rely on a custom solution. However, it does
mean that if browsers implement this, it's easily polyfillable.
What does this get you over fetch() ? Imports run scripts and enforce
ordering an deduplication. Importing JSON doesn't really make much sense.
On Apr 17, 2015, at 9:23 PM, Wilson Page wilsonp...@me.com
mailto:wilsonp...@me.com wrote:
Sounds like something you could write yourself with a custom-elements. Yay
extensible web :)
On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com
mailto:matthewwr...@gmail.com wrote:
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
{ foo: bar }
/script
```
```js
document.getElementById(foo).json // or whatever
document.getElementById(bar).json
```
Re: JSON imports?
link rel=prefetch does that for you.
On Apr 17, 2015 7:08 PM, Glen Huang curvedm...@gmail.com wrote:
One benefit is that browsers can start downloading it asap, instead of
waiting util the fetch code is executed (which could itself be in a
separate file).
On Apr 18, 2015, at 8:41 AM, Elliott Sprehn espr...@chromium.org wrote:
On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm...@gmail.com wrote:
Basic feature like this shouldn't rely on a custom solution. However, it
does mean that if browsers implement this, it's easily polyfillable.
What does this get you over fetch() ? Imports run scripts and enforce
ordering an deduplication. Importing JSON doesn't really make much sense.
On Apr 17, 2015, at 9:23 PM, Wilson Page wilsonp...@me.com wrote:
Sounds like something you could write yourself with a custom-elements.
Yay extensible web :)
On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com wrote:
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
{ foo: bar }
/script
```
```js
document.getElementById(foo).json // or whatever
document.getElementById(bar).json
```
Re: JSON imports?
On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm...@gmail.com wrote:
Basic feature like this shouldn't rely on a custom solution. However, it
does mean that if browsers implement this, it's easily polyfillable.
What does this get you over fetch() ? Imports run scripts and enforce
ordering an deduplication. Importing JSON doesn't really make much sense.
On Apr 17, 2015, at 9:23 PM, Wilson Page wilsonp...@me.com wrote:
Sounds like something you could write yourself with a custom-elements. Yay
extensible web :)
On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com wrote:
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
{ foo: bar }
/script
```
```js
document.getElementById(foo).json // or whatever
document.getElementById(bar).json
```
