On Wed, Nov 2, 2011 at 3:56 PM, Jonas Sicking wrote:
> On Wed, Nov 2, 2011 at 9:56 AM, Eric U wrote:
>> On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking wrote:
>>> On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote:
On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking wrote:
>
> 1. Make "l
On Wed, Nov 2, 2011 at 9:56 AM, Eric U wrote:
> On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking wrote:
>> On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote:
>>> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking wrote:
1. Make "loadend" not fire in case a new load is started from
onab
On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking wrote:
> On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote:
>> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking wrote:
>>>
>>> 1. Make "loadend" not fire in case a new load is started from
>>> onabort/onload/onerror. Thus "loadend" and "loadstart" isn
On Mon, Oct 3, 2011 at 10:32 PM, Jonas Sicking wrote:
> > (More precisely, no method that starts or finishes a loadstart/loadend
> > sequence can be called from within an algorithm that also starts or
> finishes
> > a sequence. abort() from within onprogress is fine, for example.)
>
> I think th
On Mon, Oct 3, 2011 at 6:39 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking 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 f
On Mon, Oct 3, 2011 at 9:13 PM, Jonas Sicking 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 guarantee
that lo
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking 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 always a "loadend" f
Gmail rather unhelpfully linked to the tests in the text/html version of my
earlier mail with links that didn't match the text. Fixed (hopefully):
[1] https://zewt.org/~glenn/test-open-during-onabort.html#http/onabort (HTTP
timeout)
[2] https://zewt.org/~glenn/test-open-during-onabort.html#tcp/on
On Mon, Oct 3, 2011 at 4:16 PM, Glenn Maynard wrote:
> On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking 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 r
On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking 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 auto-complete UI backed
On Fri, Sep 30, 2011 at 8:14 AM, Anne van Kesteren wrote:
> On Thu, 29 Sep 2011 23:17:21 +0200, Eric U 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
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U 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,
On Fri, 30 Sep 2011 19:15:17 +0200, Arun Ranganathan
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
FileReader if that's
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U 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,
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U 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
cancel the loadend th
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 readin
On Thu, Sep 29, 2011 at 12:22 PM, Arun Ranganathan 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 continue
On Thu, Sep 22, 2011 at 5:19 AM, Anne van Kesteren 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].
>> If the T
On Thu, 22 Sep 2011 04:01:40 +0200, Glenn Maynard 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. "substeps"
are pr
On Wed, 21 Sep 2011 20:12:17 +0200, Glenn Maynard 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 happen in XHR1, be
On Wed, Sep 21, 2011 at 8:32 PM, Eric U 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 to both.
On Wed, Sep 21, 2011 at 5:16 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 7:51 PM, Eric U 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
On Wed, Sep 21, 2011 at 5:16 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 7:51 PM, Eric U 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
On Wed, Sep 21, 2011 at 7:51 PM, Eric U 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 behavior.
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
On Wed, Sep 21, 2011 at 4:45 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 6:51 PM, Eric U 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
On Wed, Sep 21, 2011 at 6:51 PM, Eric U 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 use loadstar
On Wed, Sep 21, 2011 at 3:29 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 6:14 PM, Eric U 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
On Wed, Sep 21, 2011 at 6:14 PM, Eric U 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
event handler. T
On Wed, Sep 21, 2011 at 3:09 PM, Glenn Maynard wrote:
> On Wed, Sep 21, 2011 at 5:44 PM, Eric U 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.
On Wed, Sep 21, 2011 at 5:44 PM, Eric U 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 say about it
On Wed, Sep 21, 2011 at 2:44 PM, Eric U wrote:
> On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking wrote:
>> On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard wrote:
>>> On Tue, Sep 20, 2011 at 8:40 PM, Eric U wrote:
Indeed--however, from a quick skim of XHR and XHR2, that's not what
On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking wrote:
> On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard wrote:
>> On Tue, Sep 20, 2011 at 8:40 PM, Eric U wrote:
>>>
>>> Indeed--however, from a quick skim of XHR and XHR2, that's not what
>>> they do. They let open() terminate abort(), however fa
On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard wrote:
> On Tue, Sep 20, 2011 at 8:40 PM, Eric U 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
On Tue, Sep 20, 2011 at 8:40 PM, Eric U 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 getting an on
On Tue, Sep 20, 2011 at 5:32 PM, Jonas Sicking wrote:
> On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard wrote:
>> On Tue, Sep 20, 2011 at 8:01 PM, Eric U 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 rea
On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard wrote:
> On Tue, Sep 20, 2011 at 8:01 PM, Eric U 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
On Tue, Sep 20, 2011 at 8:01 PM, Eric U 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 we've specce
On Tue, Sep 20, 2011 at 4:43 PM, Jonas Sicking wrote:
> On Tue, Sep 20, 2011 at 4:28 PM, Eric U wrote:
>> On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote:
>>> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan wrote:
On 5/23/11 6:14 PM, Arun Ranganathan wrote:
On 5/23/11 1:20 PM, Ky
On Tue, Sep 20, 2011 at 4:28 PM, Eric U wrote:
> On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote:
>> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan 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
On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote:
> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan 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 throwin
On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote:
> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan 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 throwin
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan 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.
> (https://bugzilla.mozilla
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 th
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 synchro
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
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 totally
On Tue, May 17, 2011 at 2:48 PM, Jonas Sicking wrote:
> On Tue, May 17, 2011 at 2:42 PM, Eric U 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/File
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 wrot
On Tue, May 17, 2011 at 2:42 PM, Eric U 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, I'm not too bot
On Tue, May 17, 2011 at 2:41 PM, Jonas Sicking wrote:
> On Tue, May 17, 2011 at 2:35 PM, Kyle Huey 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 o
On Tue, May 17, 2011 at 2:35 PM, Kyle Huey 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 be consistent
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 be consistent. I don't particularly care either way,
but I believe Jonas
53 matches
Mail list logo
