Re: [xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)

On Sun, Jan 31, 2010 at 5:09 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Wed, 16 Dec 2009 20:46:03 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Wed, Dec 16, 2009 at 9:37 AM, Ian Hickson <ian@hixie.ch> wrote:
>>>
>>> On another note, while reading the spec I noticed that no task is queued
>>> to updated responseText. Does that mean that if I check it continually in
>>> a tight loop within a task, I can see it change?
>>
>> I think the spec should say that when data arrives from the network, a
>> task should be queued. When this task runs, it should perform the
>> following steps synchronously:
>>
>> 1. Update .responseText
>> 2. If readystate is not yet 3, set it to 3 and fire readystatechange
>
> This would dispatch readystatechange to often. The specification sides with
> IE/Opera here rather than WebKit/Gecko.

Huh? This would only fire readystatechange for readyState=3 once per
request. That doesn't seem too often.

>> 3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired
>> within the past 50ms
>
> This is already required elsewhere. I suppose I could try to merge the two,
> would that be useful?

The main point of my email was that responseText should never change
other than from the main event loop. I.e. doing xhr.responseText ==
xhr.responseText should always return true.

/ Jonas

Received on Monday, 1 February 2010 02:39:04 UTC