- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 13 May 2013 11:16:24 -0700
- To: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
- Cc: public-webapps <public-webapps@w3.org>
On Mon, May 13, 2013 at 11:05 AM, Hallvord Reiar Michaelsen Steen <hallvord@opera.com> wrote: > Firstly, the test tests a race condition - it is unlikely to cause problems in practice though (the result of the request *might* just come quickly enough that it has changed to for example readyState 2 and fired another readystatechange event before the second open() call, but it's unlikely). It's not a race condition. Task queues make sure of that. > Secondly, by reading the spec I'd expect the second open() call to fire another event. The open() method, steps 15 and 16: > > 15 Change the state to OPENED. > 16 Fire an event named readystatechange. > > Doesn't imply that if the state is already OPENED, no new event is expected to fire. Does any other part of the spec indicate this? Yeah, it seems two events should dispatch per current text. If browsers do not do that maybe there should be a state check there and those steps should become substeps. > PS: http://xhr.spec.whatwg.org/#event-xhr-readystatechange - is this description still true? It doesn't really give much information and I thought the messy parts were cleaned up anyway. Right. -- http://annevankesteren.nl/
Received on Monday, 13 May 2013 18:16:50 UTC