Re: XHR.responseBlob and BlobWriter [nee FileWriter]
On Tue, 29 Jun 2010 03:58:24 +0200, Eric Uhrhane er...@google.com wrote: XHR will have a responseBlob property. Indeed: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responseblob-attribute :-) (I also fixed the issue of not resetting the credentials flag and the request timeout when invoking open().) -- Anne van Kesteren http://annevankesteren.nl/
[Bug 10453] [IndexedDB] IDBIndex.openObjectCursor should return an IDBRequest
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10453 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrei Popescu andr...@google.com 2010-08-27 08:42:02 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/520369bc9835 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10165] [IndexedDB] IDBRequest.abort() should be removed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10165 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andrei Popescu andr...@google.com 2010-08-27 09:38:51 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/b7ae74e39c82 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10307] [indexedDB] The default version string is not specified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10307 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrei Popescu andr...@google.com 2010-08-27 10:00:20 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/c40387bbaa4d -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10400] [IndexedDB] IDBCursor.continue should not return anything
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10400 Andrei Popescu andr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Andrei Popescu andr...@google.com 2010-08-27 10:17:42 --- Fixed in http://dvcs.w3.org/hg/IndexedDB/rev/22fea0337d0b -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [cors] Protecting benign but buggy client side code
On Sat, 21 Aug 2010 03:59:09 +0200, Devdatta Akhawe dev.akh...@gmail.com wrote: It seems that over here facebook is a benign server that some time in the past assumed that XHR can only be same origin, and with the introduction of cross origin XHR is suddenly vulnerable to XSS. In general, a client needs to 'add' stuff to its js to be safe after the introduction of XHR. This isn't ideal. Yeah, this was discussed some time ago on this list already. We decided this risk was minor enough, especially now lots of shipping clients expose this already. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR] Redirects
On Fri, 13 Aug 2010 00:13:16 +0200, João Eiras joao.ei...@gmail.com wrote: Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill. I went for a boolean followRedirects attribute as that gives sufficient low-level control that people can implement whatever behavior they want on top of that. (Including every use case mentioned in this thread.) This is an XMLHttpRequest Level 2 feature now: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ -- Anne van Kesteren http://annevankesteren.nl/
CfC: publish a new WD of XHR Level 2; deadline September 3
Anne proposes WebApps publish a new WD of XHR Level 2 and this is a Call for Consensus to do so: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ If you have any comments or concerns about this proposal, please send them to public-webapps by September 3 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. -Art Barstow
CfC: to publish a Last Call Working Draft of DOM 3 Events; deadline September 3
Doug and the folks working on the DOM 3 Events spec believe the spec is now feature-complete and would like to publish a Last Call Working Draft of the spec. As such, this is a Call for Consensus to publish the following document as the LCWD: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note that as specified in the Process Document [PD], a Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; As with all of WebApps' CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is September 3. Please send all comments to the DOM list (www-...@w3.org). -Art Barstow [PD] http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Re: [IndexedDB] Constants and interfaces
On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org wrote: Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) I believe we had decided that all the objects with constants would have an interface object hanging off of window so it's possible to simply say IDBKeyRange.LEFT_BOUND within JavaScript. What happens when someone tries something like the following JS: |IDBCursor.continue()|? Given that we're using an interface object, I'd assume we throw some sort of exception or something? I tried to figure out the answer in the WebIDL spec (I imagine it's somewhere around here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but it's a lot to wade through. Any advice would be great. I definitely think we should handle this the same way that all other interfaces does it. I.e. the same way that window.Node.appendChild(...) does it. In the Firefox implementation we just fall back to using our generic code for all this stuff, so nothing special goes on in the IndexedDB implementation. And yes, I think WebIDL should be the one defining what should happen. If it doesn't already someone should file a bug :) Ok, I figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other languages the same factory methods are exposed as static methods in a way that is appropriate for that language. If the language doesn't support static methods, the methods are exposed on the IDBFactory interface. * Make a special note that in javascript, the factory methods are *not* exposed on the IDBFactory interface. Does that sound workable? / Jonas
Re: CfC: publish a new WD of XHR Level 2; deadline September 3
I support this. On Fri, Aug 27, 2010 at 9:04 AM, Arthur Barstow art.bars...@nokia.com wrote: Anne proposes WebApps publish a new WD of XHR Level 2 and this is a Call for Consensus to do so: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ If you have any comments or concerns about this proposal, please send them to public-webapps by September 3 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. -Art Barstow
[Bug 9823] Add maxExecutionContexts property with number of hardware execution contexts
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9823 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||LATER --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2010-08-27 18:26:46 --- I think this is something that deserves closer investigation, based on implementation experience. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Using FileWriter.truncate() to extend the length of a file?
On Thu, Aug 26, 2010 at 2:04 PM, Darin Fisher da...@chromium.org wrote:
I noticed that FileWriter.truncate() can only be used to shorten a file, and
there does not seem to be a good way to grow a file using FileWriter without
appending data to it. By contrast, the POSIX ftruncate function can be used
to grow a file (zero padding it):
From ftruncate(2):
If the file previously was larger than this size, the extra data is lost.
If the file previously
was shorter, it is extended, and the extended part reads as null bytes
('\0').
I see no reason we can't add this; I just left it off for simplicity,
but your use case makes sense.
I think there are use cases for wanting to grow a file in advance of writing
data to it. For example, you might implement a system that downloads chunks
of a file in parallel using multiple XMLHttpRequest objects. The chunks may
arrive out-of-order.
A possible alternative API would be to support seeking beyond the end of the
file or writing to a starting offset that is beyond the length fo the file.
It may also be reasonable to support all of those in addition to truncating
to an offset greater than the length of the file.
I think this may be a little messier, and there's no reason to make up
a new paradigm when the POSIX one is well-known and sufficient.
If nobody objects, I'll just add it.
Eric
