- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 31 Jan 2010 18:38:08 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Ian Hickson <ian@hixie.ch>, Alexey Proskuryakov <ap@webkit.org>, WebApps WG <public-webapps@w3.org>
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