[XHR2] responseType and response properties

Hi All,

Firefox 6 is going to add support for the the new responseType and
response properties. We would have liked to release these as
moz-prefixed properties, but it appears that webkit has already
shipped them unprefixed, thus there's not much point in prefixing.
Both because we likely can't fix bugs in them anyway, and because
sites have already started depending on them.

I'd really like to reiterate that we need to be careful about
releasing newly minted APIs unprefixed. Even in the case where we here
on the list agree on the desired behavior. The Blob.slice mess (which
we fortunately managed to save last minute) is a good example of why
we should give API time to mature before unprefixing.

So in that spirit, I have a questions about the actual behavior of XHR.response:

First, should it return a new ArrayBuffer every time the property is
accessed (This is how the mozResponseArrayBuffer property in FF4
behaves), or should it return the same buffer every time? Since
arraybuffers are mutable, there's a risk that one consumer will modify
the response such that all other consumers see a modified result. On
the other hand creating a new buffer every time can be quite expensive
(at least without complex/slow copy-on-write implementations). It also
would result in the surprising property that xhr.response !=
xhr.response.

In FF6 we're aiming to return the same buffer every time. The
other-consumers-will-see-a-modified-result behavior is unfortunate,
but similar to how responseXML behaves and hasn't seemed to cause a
problem there.

Second, what should .response return before the download finishes? It
would be nice if you could access partial results. However
ArrayBuffers are fixed size and we won't know the total size until the
whole download is finished. We could return a copy on each access, but
again that would be somewhat expensive.

For now we're going to return null during loading in FF6 when
.responseType is set to "arraybuffer".

/ Jonas

Received on Saturday, 21 May 2011 07:37:48 UTC