On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
1. Make loadend not fire in case a new load is started from
onabort/onload/onerror.
On Wed, Nov 2, 2011 at 9:56 AM, Eric U er...@google.com wrote:
On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
1. Make loadend not
On Wed, Nov 2, 2011 at 3:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Nov 2, 2011 at 9:56 AM, Eric U er...@google.com wrote:
On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U er...@google.com wrote:
I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a loadend.
Now that Anne's
On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U er...@google.com wrote:
I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a
On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking jo...@sicking.cc wrote:
Unfortunately I suspect wanting to call open from event handlers is a
pretty common use case. Here are two use cases:
1. In case of a network error, let the onerror handler retry the request.
2. Implementing a
On Mon, Oct 3, 2011 at 4:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking jo...@sicking.cc wrote:
Unfortunately I suspect wanting to call open from event handlers is a
pretty common use case. Here are two use cases:
1. In case of a network error, let
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
1. Make loadend not fire in case a new load is started from
onabort/onload/onerror. Thus loadend and loadstart isn't always
paired up. Though there is
On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking jo...@sicking.cc wrote:
So what exactly are you proposing we do for XHR and for
FileReader/FileWriter?
For APIs other than XHR, don't allow calling read* or abort during events
fired on the object from its own algorithms. This should give the
On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking jo...@sicking.cc wrote:
So what exactly are you proposing we do for XHR and for
FileReader/FileWriter?
For APIs other than XHR, don't allow calling read* or abort during events
On Fri, 30 Sep 2011 19:15:17 +0200, Arun Ranganathan a...@mozilla.com
wrote:
Anne: I think simplifying the model like this makes sense, although
previous discussions seemed to suggest that previous implementation
history made these kinds of changes hard. I'd be happy to match this in
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U er...@google.com wrote:
I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a loadend.
Now that Anne's explained XHR2's model, it seems that an open can
On Thu, Sep 29, 2011 at 12:22 PM, Arun Ranganathan a...@mozilla.com wrote:
On 9/21/11 8:07 PM, Eric U wrote:
Update: I have made the changes to FileWriter/FileSaver's event
sequences; they now match FileReader.
That's not to say it won't change pending discussion, but FileWriter
should
On 9/21/11 8:07 PM, Eric U wrote:
Update: I have made the changes to FileWriter/FileSaver's event
sequences; they now match FileReader.
That's not to say it won't change pending discussion, but FileWriter
should continue to match FileReader whatever else happens.
Eric
Eric:
After
On Wed, 21 Sep 2011 20:12:17 +0200, Glenn Maynard gl...@zewt.org wrote:
Yuck. I agree that's not a good thing to mimic for the sake of
consistency. Anne, is this intentional, or just something XHR is just
stuck with for compatibility? It looks like a new problem in XHR2--this
couldn't
On Thu, 22 Sep 2011 04:01:40 +0200, Glenn Maynard gl...@zewt.org wrote:
To my reading, a substep is a type of step. The after finishing...
sounds like it's saying not to terminate the currently-executing step;
that is, the event dispatch isn't stopped in the middle. Maybe steps
vs.
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
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
44 matches
Mail list logo
