Re: Proposal: High resolution (and otherwise improved) timer API
Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 2:11 PM, Robert Sayre wrote: On Thu, Oct 2, 2008 at 11:43 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: A number of WebKit developers (including from the Chrome team and the Safari team) have been discussing ideas for a new and improved timer API. We would like to serve the following use cases which we feel are not well served by the de facto standard (and now HTML5 standard) interfaces of setTimeout and setInterval: I don't see anything in the HTML5 document that requires the 10-15.6ms delay. Is HTML5 going to add that as a conformance requirement? I don't know. I would recommend to the HTML5 editor to require some reasonable minimum because it seems to be de facto required for Web compatibility. I cannot state with certainty that nothing lower than 10ms is safe. Chrome shipped with a 1ms delay and that was found to create problems on a number of sites, including nytimes. They are planning to try 4ms next. We would consider using a lower limit in the official webkit.org version of WebKit, not not as low as 1ms. Isn't the problem more that it'll depend on the code being run on the timer and whether the UA's hardware can cope with running everything fast enough? We've had trouble with some sites on slow boxes because their interval timers are constantly wanting to fire before the page has finished reacting to the previous timer fire. Our solution has also been to enforce a minimum frequency for interval timers just to give a fighting chance for the site to work at all (and to not allow the timer to fire again whilst the previous instance is still executing) -- Stewart Brodie Software Engineer ANT Software Limited
[XHR2] XMLHttpRequest Level 2 WD Published
Somehow I missed that it actually happened, but a few days ago the WebApps WG pushed out another draft of XMLHttpRequest Level 2: http://www.w3.org/TR/2008/WD-XMLHttpRequest2-20080930/ Since we're still working on nailing down the details of Access Control for Cross-Site Requests this draft is in flux, but it has one important feature that a previous version of this draft didn't have, namely a link to the Latest Editor Version, right at the top. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[XHR2] Drop ByteArray?
I'm considering dropping ByteArray support. That is, removing support for it from send() and removing responseBody for now. At this point it's not really clear what the future of ByteArray is and it seems nobody is driving that work or implementing this feature from XMLHttpRequest Level 2. It would be nice to have access to the raw byte stream, as authors currently use ugly hacks to get to it, but higher level support for byte streams is somewhat of a prerequisite. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] non same-origin to same-origin redirect
On Fri, 03 Oct 2008 14:10:43 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: Since Jonas didn't e-mail about this I thought I would. Say http://x.example/x does a request to http://y.example/y. http://y.example/y redirects to http://x.example/y. If this request were to use the Access Control specification the algorithm would have a status return flag set to same-origin and a url return flag set to http://x.example/y. XMLHttpRequest Level 2 would then attempt a same origin request to http://x.example/y. For simplicity and to err on the side of security it has been suggested to remove the status return flag same-origin and simply keep following the normal rules. This would mean that if that request were to be successful http://x.example/y would need to include Access-Control-Allow-Origin: http://x.example (or a value * would also be ok if the credentials flag is false). I'm planning on making this change in the next few days. I updated both Access Control and XMLHttpRequest Level 2 to no longer special case the scenario where during a non same origin request you're redirected to a same origin URL. Both specifications use the status flag (previously known as the status return flag) and the url return flag is gone. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [XHR2] Drop ByteArray?
On Oct 6, 2008, at 5:52 AM, Anne van Kesteren wrote: I'm considering dropping ByteArray support. That is, removing support for it from send() and removing responseBody for now. At this point it's not really clear what the future of ByteArray is and it seems nobody is driving that work or implementing this feature from XMLHttpRequest Level 2. It would be nice to have access to the raw byte stream, as authors currently use ugly hacks to get to it, but higher level support for byte streams is somewhat of a prerequisite. I will ask the ECMAScript committee what the plans are. I think we could just invent our own ByteArray or BinaryData interface, it would work better integrated into the language, but ImageData as a custom type works ok in practice. Regards, Maciej
Re: [access-control] non same-origin to same-origin redirect
Anne van Kesteren wrote: On Fri, 03 Oct 2008 14:10:43 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: Since Jonas didn't e-mail about this I thought I would. Say http://x.example/x does a request to http://y.example/y. http://y.example/y redirects to http://x.example/y. If this request were to use the Access Control specification the algorithm would have a status return flag set to same-origin and a url return flag set to http://x.example/y. XMLHttpRequest Level 2 would then attempt a same origin request to http://x.example/y. For simplicity and to err on the side of security it has been suggested to remove the status return flag same-origin and simply keep following the normal rules. This would mean that if that request were to be successful http://x.example/y would need to include Access-Control-Allow-Origin: http://x.example (or a value * would also be ok if the credentials flag is false). I'm planning on making this change in the next few days. I updated both Access Control and XMLHttpRequest Level 2 to no longer special case the scenario where during a non same origin request you're redirected to a same origin URL. Both specifications use the status flag (previously known as the status return flag) and the url return flag is gone. I think this the is better of the two alternatives. The scenario that I am worried about is a page on server sensitive.com reads public data from evil.com. However if evil.com redirects back to a private resource on sensitive.com sensitive.com might be dealing with sensitive user-private data without being aware of it. This seems scary and could lead to the data being stored or published somewhere unsafe. Things still aren't perfect since it's strange that a site has to trust itself. And that if it does it'd be back in the somewhat scary situation described above, but it's at least somewhat better IMHO. / Jonas
Re: [XHR2] Drop ByteArray?
On Mon, 06 Oct 2008 20:06:24 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: I will ask the ECMAScript committee what the plans are. I think we could just invent our own ByteArray or BinaryData interface, it would work better integrated into the language, but ImageData as a custom type works ok in practice. Yeah, some collegues suggested it could indeed be as simple as CanvasPixelArray. Would be good to hear what the ECMAScript guys think. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Implementation comments (credentials flag)
On Tue, 30 Sep 2008 00:36:10 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Jonas Sicking wrote: Yes, I think it would be helpful to add that information. It wasn't clear that the credentials flag wasn't part of the key until you put it this way (though the spec already clearly says so, just easy to miss). I added a note that says what the primary key is now. (The credentials flag is also part of it now.) [...] So in this case the credentials flag is actually part of the primary key. I.e. the spec says to not update an existing entry if a request is made with the credentials flag set to true, but the cache contains an entry with the credentials flag set to false. Instead a new entry should be created which will only differ in the value of the credentials flag (and possibly in the value of the expiry time). I suspect the simplest solution is to actually make the credentials flag part of the primary key everywhere. Indeed. It didn't seem to be worth the trouble to optimize for public non credentialed requests for URLs that already have a credentialed cache entry. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Call for Consensus: a new WD of the File Upload spec
Sam, I don't think we should include synchronous access to File data provided by: DOMString getDataAsText(in DOMString encoding) raises(FileException); DOMString getDataAsBase64() raises(FileException); DOMString getDataAsBinary() raises(FileException); DOMString getAsDataURL() raises(FileException); The only real change I made to the text from the old text of the spec. was to add in requirements [1] to which I didn't get much feedback ;-) but that's ok. Mozilla's nsIDOMFile behaves synchronously, so I kept in the section with such methods. I'm not *super* opinionated on this and am not sure that this should *prevent* publishing -- could we publish what we have and then discuss? I'll keep making changes before the moratorium so we have something more substantive to discuss, but FWIW: I would propose an asynchronous API, perhaps like the one proposed for Blobs http://code.google.com/p/gears/wiki/BlobWebAPIPropsal#Reading_Blob_Data, instead. I agree and will add this (and have been meaning to). -- A* [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml#requirements
