On Thu, Sep 22, 2011 at 5:19 AM, Anne van Kesteren ann...@opera.com wrote:
I just tried this in FF6, and the behavior is inconsistent. If the TCP
connection has been established, then it follows your interpretation, and
you get onloadstart, onabort, onloadstart, onloadend, onloadend [1][3].
On Tue, Sep 20, 2011 at 8:40 PM, Eric U er...@google.com wrote:
Indeed--however, from a quick skim of XHR and XHR2, that's not what
they do. They let open() terminate abort(), however far along it's
gotten. If we did that, then an abort killed by a read might lead to
the aborted read never
On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Sep 20, 2011 at 8:40 PM, Eric U er...@google.com wrote:
Indeed--however, from a quick skim of XHR and XHR2, that's not what
they do. They let open() terminate abort(), however far along it's
gotten. If we did
On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Sep 20, 2011 at 8:40 PM, Eric U er...@google.com wrote:
Indeed--however, from a quick skim of XHR and XHR2, that's not what
they do. They let
On Wed, Sep 21, 2011 at 2:44 PM, Eric U er...@google.com wrote:
On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Sep 20, 2011 at 8:40 PM, Eric U er...@google.com wrote:
Indeed--however, from a
On Wed, Sep 21, 2011 at 5:44 PM, Eric U er...@google.com wrote:
If we want the file specs to match the XHR spec, then we can just
leave this as it is in File Reader, and I'll match it in File Writer.
Recursion depth limit is up to the UA to set. But I look forward to
hearing what Anne has to
On Wed, Sep 21, 2011 at 3:09 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 21, 2011 at 5:44 PM, Eric U er...@google.com wrote:
If we want the file specs to match the XHR spec, then we can just
leave this as it is in File Reader, and I'll match it in File Writer.
Recursion depth limit is
On Wed, Sep 21, 2011 at 6:14 PM, Eric U er...@google.com wrote:
If we eliminate it entirely, then you can't ever start a new read on
the same object from the abort handler. That seems like a reasonable
use case.
It's trivial to stuff it into a zero-second timeout to knock it out of the
On Wed, Sep 21, 2011 at 3:29 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 21, 2011 at 6:14 PM, Eric U er...@google.com wrote:
If we eliminate it entirely, then you can't ever start a new read on
the same object from the abort handler. That seems like a reasonable
use case.
It's
On Wed, Sep 21, 2011 at 6:51 PM, Eric U er...@google.com wrote:
While it's certainly not hard to work around, as you say, it seems
more complex and less likely to be obvious than the
counter-for-activity example, which feels like the classic push-pop
paradigm.
The *need* to have counters to
On Wed, Sep 21, 2011 at 7:51 PM, Eric U er...@google.com wrote:
Again, that's not what the XHR2 spec says. See my summary up-thread
about the actual behavior, and Anne can correct my interpretation if
I'm wrong.
I don't know what you mean by again; this is the first time I've described
this
On Wed, Sep 21, 2011 at 5:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 21, 2011 at 7:51 PM, Eric U er...@google.com wrote:
Again, that's not what the XHR2 spec says. See my summary up-thread
about the actual behavior, and Anne can correct my interpretation if
I'm wrong.
I don't
On Wed, Sep 21, 2011 at 8:32 PM, Eric U er...@google.com wrote:
5.6.3 is a substep, not a step; all of 5's substeps are referred
to as such in step 5: Otherwise run these substeps:. However, I
believe we were actually discussing 5.5, loadend on the XHR itself.
Either way, the below applies
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/23/11 6:14 PM, Arun Ranganathan wrote:
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here.
On Tue, Sep 20, 2011 at 3:36 PM, Eric U er...@google.com wrote:
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/23/11 6:14 PM, Arun Ranganathan wrote:
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change to
On Tue, Sep 20, 2011 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 20, 2011 at 4:28 PM, Eric U er...@google.com wrote:
On Tue, Sep 20, 2011 at 3:36 PM, Eric U er...@google.com wrote:
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/23/11 6:14 PM,
On Tue, Sep 20, 2011 at 8:01 PM, Eric U er...@google.com wrote:
I have a read running, and at some point I abort it--it could be in
onprogress or elsewhere. In onabort I start another read. In
onloadstart I abort again. Repeat as many times as you like, then let
a read complete. I believe
On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Sep 20, 2011 at 8:01 PM, Eric U er...@google.com wrote:
I have a read running, and at some point I abort it--it could be in
onprogress or elsewhere. In onabort I start another read. In
onloadstart I abort again.
On Tue, Sep 20, 2011 at 5:32 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Sep 20, 2011 at 8:01 PM, Eric U er...@google.com wrote:
I have a read running, and at some point I abort it--it could be in
onprogress or
On Thursday, July 07, 2011 10:21 PM, Arun Ranganathan wrote:
On 7/6/11 10:13 PM, Cameron McCormack wrote:
There was a recent change in Web IDL which made interface types (like
the readAsXXX argument types) not include null by default, and if you
want to allow null, to write it as “Type?”.
On Tue, Jun 21, 2011 at 10:17 AM, Arun Ranganathan a...@mozilla.com wrote:
Sorry if these have all been discussed before. I just read the File API for
the first time and 2 random questions popped in my head.
1) If I'm using readAsText with a particular encoding and the data in the
file is not
On 7/6/11 10:13 PM, Cameron McCormack wrote:
Hi Arun,
Adrian Bateman:
The spec doesn't seem to state this explicitly and I can't tell if
there is supposed to be an implicit requirement from WebIDL. Perhaps
the expectation is that this falls into the error condition and
should set readyState to
On 7/6/11 7:54 PM, Adrian Bateman wrote:
http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file
What is the expected behaviour for FileReader.readAsXXX(null)? Currently
I think both IE10 and Chrome fail silently and there are no events fired
whereas Firefox appears to throw an internal
On 6/30/11 6:01 PM, Gregg Tavares (wrk) wrote:
On Tue, Jun 21, 2011 at 10:17 AM, Arun Ranganathan a...@mozilla.com
mailto:a...@mozilla.com wrote:
Sorry if these have all been discussed before. I just read the
File API for the first time and 2 random questions popped in my
head.
Hi Arun,
Adrian Bateman:
The spec doesn't seem to state this explicitly and I can't tell if
there is supposed to be an implicit requirement from WebIDL. Perhaps
the expectation is that this falls into the error condition and
should set readyState to DONE, result to null, and process the
On Tue, Jun 21, 2011 at 10:17 AM, Arun Ranganathan a...@mozilla.com wrote:
**
Sorry if these have all been discussed before. I just read the File API for
the first time and 2 random questions popped in my head.
1) If I'm using readAsText with a particular encoding and the data in the
file
On 6/7/11 5:04 PM, Jonas Sicking wrote:
On Tue, Jun 7, 2011 at 11:51 AM, Jian Lijia...@chromium.org wrote:
On Tue, Jun 7, 2011 at 11:23 AM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 7, 2011 at 10:43 AM, Jian Lijia...@chromium.org wrote:
I have a couple questions regarding abort
On 6/7/11 1:43 PM, Jian Li wrote:
I have a couple questions regarding abort behavior.
* If the reading is completed and the loadend event has been
fired, do we want to fire loadend event again when abort()
method is called?
Right now, if reading is completed (with loadend
Sorry if these have all been discussed before. I just read the File API for
the first time and 2 random questions popped in my head.
1) If I'm using readAsText with a particular encoding and the data in the
file is not actually in that encoding such that code points in the file can
not be mapped
On May 12, 2011, at 00:49 , Arun Ranganathan wrote:
2. The read methods on FileReader raise a new exception --
OperationNotAllowedException -- if multiple concurrent reads are invoked. I
talked this over with Jonas; we think that rather than reuse DOMException
error codes (like
On Wed, Jun 8, 2011 at 8:16 AM, Robin Berjon ro...@berjon.com wrote:
On May 12, 2011, at 00:49 , Arun Ranganathan wrote:
2. The read methods on FileReader raise a new exception --
OperationNotAllowedException -- if multiple concurrent reads are invoked. I
talked this over with Jonas; we
I have a couple questions regarding abort behavior.
- If the reading is completed and the loadend event has been fired, do we
want to fire loadend event again when abort() method is called?
- Do we want to reset error to null or leave it intact when abort()
method is called?
Thanks,
On Tue, Jun 7, 2011 at 10:43 AM, Jian Li jia...@chromium.org wrote:
I have a couple questions regarding abort behavior.
If the reading is completed and the loadend event has been fired, do we want
to fire loadend event again when abort() method is called?
No
Do we want to reset error to
On Tue, Jun 7, 2011 at 11:23 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jun 7, 2011 at 10:43 AM, Jian Li jia...@chromium.org wrote:
I have a couple questions regarding abort behavior.
If the reading is completed and the loadend event has been fired, do we
want
to fire loadend
On Tue, Jun 7, 2011 at 11:51 AM, Jian Li jia...@chromium.org wrote:
On Tue, Jun 7, 2011 at 11:23 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jun 7, 2011 at 10:43 AM, Jian Li jia...@chromium.org wrote:
I have a couple questions regarding abort behavior.
If the reading is completed
To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here. (
https://bugzilla.mozilla.org/show_bug.cgi?id=657964)
We have not changed the timing of the events, which are still dispatched
synchronously.
- Kyle
On Tue, May 17, 2011 at
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here.
(https://bugzilla.mozilla.org/show_bug.cgi?id=657964)
We have not changed the timing of the events, which are still
dispatched
On 5/23/11 6:14 PM, Arun Ranganathan wrote:
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here.
(https://bugzilla.mozilla.org/show_bug.cgi?id=657964)
We have not changed the timing of
On Tue, May 17, 2011 at 2:35 PM, Kyle Huey m...@kylehuey.com wrote:
The abort behaviors of FileReader and File[Saver|Writer] differ. The
writing objects throw if the abort method is called when a write is not
currently under way, while the reading object does not throw.
The behaviors should
On Tue, May 17, 2011 at 2:41 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, May 17, 2011 at 2:35 PM, Kyle Huey m...@kylehuey.com wrote:
The abort behaviors of FileReader and File[Saver|Writer] differ. The
writing objects throw if the abort method is called when a write is not
currently
On Tue, May 17, 2011 at 2:42 PM, Eric U er...@google.com wrote:
It was likely just an oversight on my part that they differ.
It does seem a bit odd to dispatch error/abort/loadend if aborting
with no write in progress, so I favor the FileWriter/FileSaver
behavior, but as long as they match,
It was likely just an oversight on my part that they differ.
It does seem a bit odd to dispatch error/abort/loadend if aborting
with no write in progress, so I favor the FileWriter/FileSaver
behavior, but as long as they match, I'm not too bothered.
On Tue, May 17, 2011 at 2:35 PM, Kyle Huey
On Tue, May 17, 2011 at 2:48 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, May 17, 2011 at 2:42 PM, Eric U er...@google.com wrote:
It was likely just an oversight on my part that they differ.
It does seem a bit odd to dispatch error/abort/loadend if aborting
with no write in progress, so I
There is actually another difference, the writing API sets the error,
readystate value, and dispatches events off of a queued task, while the
reading API does that synchronously.
I'm inclined to think the synchronous version is the way to go here, since
then the FileReader or FileWriter is
On 4/14/11 5:22 AM, Jonas Sicking wrote:
On Thu, Apr 14, 2011 at 2:16 AM, James Grahamjgra...@opera.com wrote:
On 04/14/2011 03:04 AM, Jonas Sicking wrote:
It would be nice to hear from someone at Opera about their willingness to
commit to this change
as well.
As a general point we think
On Mon, Apr 18, 2011 at 8:48 PM, Eric Uhrhane er...@google.com wrote:
Apologies for the slow response. I wanted to go back and reread the
relevant specs before I said anything more. Having done so, I found
that XHR and FileReader were more similar than I had remembered.
However, I believe I
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman adria...@microsoft.com
wrote:
Yes, we could live with it but the semantics are more complex. Is this the
same as calling abort() then readAsXXX()?
Yes. I.e. the semantics of readAsX is
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman adria...@microsoft.com wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman adria...@microsoft.com
wrote:
Yes, we could live with it but the semantics are more complex. Is this the
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman adria...@microsoft.com
wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInProgress)
On Mon, Apr 18, 2011 at 12:55 PM, Adrian Bateman adria...@microsoft.com wrote:
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman adria...@microsoft.com
wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
Yes. I.e. the
On 4/18/11 3:55 PM, Adrian Bateman wrote:
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Batemanadria...@microsoft.com
wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
Yes. I.e. the semantics of readAsX is basically:
On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote:
FileReader is extremely similar to XMLHttpRequest. The main difference
is in how you initiate the request (.open/.send vs. .readAsX). This
similarity is even getting stronger now that XHR gets .result.
So I think there are good
On 4/15/11 2:57 PM, Adrian Bateman wrote:
On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote:
FileReader is extremely similar to XMLHttpRequest. The main difference
is in how you initiate the request (.open/.send vs. .readAsX). This
similarity is even getting stronger now that XHR gets
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote:
On 4/15/11 2:57 PM, Adrian Bateman wrote:
With this in mind, I don't personally have a strong feeling either way
between having to call abort() explicitly or having readAsXXX implicitly
call abort(). I've discussed it with others
On Fri, Apr 15, 2011 at 12:53 PM, Adrian Bateman adria...@microsoft.com wrote:
On Friday, April 15, 2011 12:16 PM, Arun Ranganathan wrote:
On 4/15/11 2:57 PM, Adrian Bateman wrote:
With this in mind, I don't personally have a strong feeling either way
between having to call abort()
On 04/14/2011 03:04 AM, Jonas Sicking wrote:
It would be nice to hear from someone at Opera about their willingness to
commit to this change
as well.
As a general point we think that making breaking changes to APIs with
multiple compatible implementations that are already shipping is a
On Thu, Apr 14, 2011 at 2:16 AM, James Graham jgra...@opera.com wrote:
On 04/14/2011 03:04 AM, Jonas Sicking wrote:
It would be nice to hear from someone at Opera about their willingness to
commit to this change
as well.
As a general point we think that making breaking changes to APIs with
On Tue, Apr 12, 2011 at 5:33 PM, Eric Uhrhane er...@google.com wrote:
On Tue, Apr 12, 2011 at 3:38 PM, Kyle Huey m...@kylehuey.com wrote:
Hello All,
In the current FileAPI Writer spec a BlobBuilder can be used to build a
series of blobs like so:
var bb = BlobBuilder();
bb.append(foo);
On Tue, Apr 12, 2011 at 10:01 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 12, 2011 at 5:59 PM, Brendan Eich bren...@mozilla.org wrote:
Darin's position is leaning toward not breaking compatibility with what
Chrome has shipped for a while. That's one consideration. It can't be the
On Wed, Apr 13, 2011 at 2:46 AM, Jonas Sicking jo...@sicking.cc wrote:
Another advantage of dropping the memory automatically is that you
don't need to copy any data into the Blob. Instead you can just make
the Blob take ownership of whatever memory buffers you've built up
during the various
On Apr 13, 2011, at 7:01 AM, Darin Fisher wrote:
Agreed. I certainly don't assert that whatever Chrome ships first should be
regarded as standard. Our rapid release schedule depends on platform
features beginning life with a vendor prefix. I believe that we goofed in
this case by not
On Tue, Apr 12, 2011 at 11:50 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 12, 2011 at 10:01 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 12, 2011 at 5:59 PM, Brendan Eich bren...@mozilla.org
wrote:
Darin's position is leaning toward not breaking compatibility with
On 4/12/11 2:24 PM, Jonas Sicking wrote:
Hi All,
It was recently (yesterday) pointed out to me that we let a bad
spec-bug slip through for File.slice. It doesn't match the argument
semantics of Array.slice which can be very confusing for developers.
In Array.slice the second argument is the
On 4/11/11 1:39 PM, Adrian Bateman wrote:
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathana...@mozilla.com wrote:
In general, I'm averse to throwing, since I think it puts an additional
burden on the developer (to catch, for example).
On Tue, Apr 12, 2011 at 11:44 AM, Arun Ranganathan a...@mozilla.com wrote:
On 4/11/11 1:39 PM, Adrian Bateman wrote:
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathana...@mozilla.com
wrote:
In general, I'm averse to throwing, since I
On Mon, Apr 11, 2011 at 10:39 AM, Adrian Bateman adria...@microsoft.com wrote:
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan a...@mozilla.com wrote:
In general, I'm averse to throwing, since I think it puts an additional
burden on
File.slice was first supported in Firefox 4.
- Kyle
On Tue, Apr 12, 2011 at 1:08 PM, Jian Li jia...@chromium.org wrote:
The biggest concern is that this is a breaking change and quite a few web
applications have already been using it. As far as I know, File.slice(start,
length) has been
On Tue, Apr 12, 2011 at 1:08 PM, Jian Li jia...@chromium.org wrote:
The biggest concern is that this is a breaking change and quite a few web
applications have already been using it. As far as I know, File.slice(start,
length) has been supported as early as Chrome 6 and Safari 5. Also Firefox 3
We're using ArrayBuffer... It's been through a few changes of its own relating
to slice.
I think they just went the route of renaming the method.
-Charles
On Apr 12, 2011, at 1:36 PM, Dmitry Titov dim...@chromium.org wrote:
Indeed, it appeared in FF 4 which was shipped end of March, so if
Taking back the claim about Safari :-) It doesn't have File.slice indeed.
Sorry about that.
On Tue, Apr 12, 2011 at 1:36 PM, Dmitry Titov dim...@chromium.org wrote:
Indeed, it appeared in FF 4 which was shipped end of March, so if it was
only FF API, it would be fine to change it since it's
On Tue, Apr 12, 2011 at 1:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 12, 2011 at 1:36 PM, Dmitry Titov dim...@chromium.org wrote:
Indeed, it appeared in FF 4 which was shipped end of March, so if it was
only FF API, it would be fine to change it since it's only been official for
On Tue, Apr 12, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
File.slice is currently shipped by Chrome and Firefox 4. I would be
fine with fixing this in Firefox 4.0.1, however that only makes sense
if the chrome folks are fine with fixing it in their implementation.
bb = new
On 4/12/11 5:27 PM, Glenn Maynard wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
File.slice is currently shipped by Chrome and Firefox 4. I would be
fine with fixing this in Firefox 4.0.1, however that only makes sense
if the chrome folks are fine with
On Tue, Apr 12, 2011 at 2:27 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote:
File.slice is currently shipped by Chrome and Firefox 4. I would be
fine with fixing this in Firefox 4.0.1, however that only makes sense
if the chrome
On 4/12/11 4:45 PM, Charles Pritchard wrote:
We're using ArrayBuffer... It's been through a few changes of its own
relating to slice.
I think they just went the route of renaming the method.
To be clear, here you're referring to the *.subarray method of TypedArray:
On 4/12/11 2:05 PM, Jonas Sicking wrote:
It appears that Opera too implements File.slice. Would be great to
know for how long it's been implemented.
The first public build [1] with File.slice was made available last week.
It's only been officially supported as of today, however, with the
On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor miketa...@gmail.com wrote:
On 4/12/11 2:05 PM, Jonas Sicking wrote:
It appears that Opera too implements File.slice. Would be great to
know for how long it's been implemented.
The first public build [1] with File.slice was made available last
On Tue, Apr 12, 2011 at 4:25 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor miketa...@gmail.com wrote:
On 4/12/11 2:05 PM, Jonas Sicking wrote:
It appears that Opera too implements File.slice. Would be great to
know for how long it's been implemented.
On Tue, Apr 12, 2011 at 3:38 PM, Kyle Huey m...@kylehuey.com wrote:
Hello All,
In the current FileAPI Writer spec a BlobBuilder can be used to build a
series of blobs like so:
var bb = BlobBuilder();
bb.append(foo);
var foo = bb.getBlob();
bb.append(bar);
var bar =
Darin's position is leaning toward not breaking compatibility with what
Chrome has shipped for a while. That's one consideration. It can't be the only
consideration, or there's no point having a discussion and whatever Chrome
ships first is an instant standard.
When we talked to Kenneth Arnold
It can be more then it looks though - if site detects File.slice and then
uses it, it will automatically pick up FF and Opera now because the method
now is defined. But the code is assuming the 'length' semantics of the
second parameter. So if the site is using recommended method of detection,
the
I just realized that string.slice also follows the pattern of Array.slice.
I really think we need to fix this to not cause a very unfortunate
inconsistency. I'd rather take some short term pain rather than foist
this upon developers forever. We're also all guilty of releasing
unprefixed code for
Dmitry Titov dim...@chromium.org wrote:
It can be more then it looks though - if site detects File.slice and then
uses it, it will automatically pick up FF and Opera now because the method
now is defined.
FF and Opera just added File slice support, IIUC. For Firefox at least we are
willing to
I strongly prefer a rename as done with subarray in the typed arrays spec. It's
straightforward on feature detection, as it's just an if [exists] statement.
On Apr 12, 2011, at 7:03 PM, Jonas Sicking jo...@sicking.cc wrote:
I just realized that string.slice also follows the pattern of
On 04/12/2011 05:33 PM, Eric Uhrhane wrote:
On Tue, Apr 12, 2011 at 3:38 PM, Kyle Hueym...@kylehuey.com wrote:
Hello All,
In the current FileAPI Writer spec a BlobBuilder can be used to build a
series of blobs like so:
var bb = BlobBuilder();
bb.append(foo);
var foo = bb.getBlob();
On Tue, Apr 12, 2011 at 5:59 PM, Brendan Eich bren...@mozilla.org wrote:
Darin's position is leaning toward not breaking compatibility with what
Chrome has shipped for a while. That's one consideration. It can't be the
only consideration, or there's no point having a discussion and whatever
On 4/11/11 9:38 AM, Arthur Barstow wrote:
Hi Arun, Jonas - what is the status/plan for the File API spec?
What remains to be done before the spec is LC ready?
Art:
A few things need to be done:
1. There continue to be a few spec. nits about multiple read calls;
these have to be addressed.
On 3/31/11 6:12 PM, Eric Uhrhane wrote:
On Thu, Mar 31, 2011 at 2:55 PM, Adrian Batemanadria...@microsoft.com wrote:
On Thursday, March 31, 2011 10:19 AM, Arun Ranganathan wrote:
On 3/30/11 2:01 PM, Eric Uhrhane wrote:
On Mon, Mar 28, 2011 at 5:37 PM, Adrian Batemanadria...@microsoft.com
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote:
On 3/31/11 6:12 PM, Eric Uhrhane wrote:
I think it's cleaner and simpler just to throw. FileReader and XHR
are already different enough that a bit more, as long as it's a
usability improvement, isn't a big deal. The efficiency
On Apr/11/2011 11:20 AM, ext Arun Ranganathan wrote:
On 4/11/11 9:38 AM, Arthur Barstow wrote:
Hi Arun, Jonas - what is the status/plan for the File API spec?
What remains to be done before the spec is LC ready?
Art:
A few things need to be done:
1. There continue to be a few spec. nits
On 4/11/11 12:05 PM, Adrian Bateman wrote:
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote:
On 3/31/11 6:12 PM, Eric Uhrhane wrote:
I think it's cleaner and simpler just to throw. FileReader and XHR
are already different enough that a bit more, as long as it's a
usability
On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan a...@mozilla.com wrote:
In general, I'm averse to throwing, since I think it puts an additional
burden on the developer (to catch, for example).
Only if the developer is trying to catch all exceptions, which you usually
don't. Most
On Mon, Apr 11, 2011 at 9:05 AM, Adrian Bateman adria...@microsoft.com wrote:
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote:
On 3/31/11 6:12 PM, Eric Uhrhane wrote:
I think it's cleaner and simpler just to throw. FileReader and XHR
are already different enough that a bit more,
On 4/11/11 1:04 PM, Glenn Maynard wrote:
On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan a...@mozilla.com
mailto:a...@mozilla.com wrote:
In general, I'm averse to throwing, since I think it puts an
additional burden on the developer (to catch, for example).
Only if the developer
On Mon, Apr 11, 2011 at 1:28 PM, Arun Ranganathan a...@mozilla.com wrote:
On the main thread, with your proposal, all reads will stop since an
exception has been raised.
That's odd--why would that happen? Normally one expects an API call that
throws an exception to have no effect. It'd
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan a...@mozilla.com wrote:
In general, I'm averse to throwing, since I think it puts an additional
burden on the developer (to catch, for example).
I don't think so. I think that calling
On Mon, Apr 11, 2011 at 12:16 PM, Glenn Maynard gl...@zewt.org wrote:
File objects should have a readOnly property, indicating whether write
permission is granted by the user. Files returned from input elements
should, by default, set it. Constructing a FileWriter using a File with its
On Mon, Apr 11, 2011 at 4:22 PM, Eric Uhrhane er...@google.com wrote:
Are you thinking of FileEntry? File objects are always immutable, and
there's currently no way to get from a File to a FileWriter.
I'm thinking of File, but I didn't notice that there's no FileWriter(File)
constructor.
I
On Mon, 11 Apr 2011, Glenn Maynard wrote:
createWriter method to the objects in the HTMLInputElement.files array
(a new subclass of File), to create a writer for the underlying file.
That would violate the user expectation that files provided using a file
upload control on a form can't be
On Mon, Apr 11, 2011 at 5:32 PM, Ian Hickson i...@hixie.ch wrote:
createWriter method to the objects in the HTMLInputElement.files array
(a new subclass of File), to create a writer for the underlying file.
That would violate the user expectation that files provided using a file
upload
201 - 300 of 449 matches
Mail list logo
