[XHR]
Spec at http://www.w3.org/TR/XMLHttpRequest/ says that:
1. each change of state must fire an event
2. readyState must always be equal to the current state
it follows that it is possible for eventhandler to be called more than once
with the same value of readyState, in particular the code example [1] which
can be found in the spec is buggy, as it only checks if readyState is 4,
but does not check if this value was already reported before.
This example seems to inspire a vast number of developers, in particular
OpenSocial seems to suffer from it.
Best regards,
Jakub Łopuszański
[1]
Some simple code to do something with data from an XML document fetched
over the network:
function processData(data) {
// taking care of data
}
function handler() {
if(this.readyState == this.DONE) {
if(this.status == 200
this.responseXML != null
this.responseXML.getElementById('test').textContent) {
// success!
processData(this.responseXML.getElementById('test').textContent);
return;
}
// something went wrong
processData(null);
}
}
var client = new XMLHttpRequest();
client.onreadystatechange = handler;
client.open(GET, unicorn.xml);
client.send();
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-08-06 13:25, Lachlan Hunt wrote: On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: (12/07/31 20:06), Arthur Barstow wrote: On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 I think this is a very minor issue, and it has a simple workaround - mark it as undefined. However, if Lachlan doesn't feel like paying extra fee for versionning (what Anne calls make work) or he thinks having undefineds in a spec significantly lowers the quality, I think that's fair enough and I suggest the way to move forward (if we really want to) is to consider my comment as retracted (let's just do so if Lachlan doesn't reply to this). I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. After thinking about this for a while, I'm still not much closer to figuring out exactly what the right solution is, nor how the spec should change. But I think it may be acceptable to leave this issue as undefined in Selectors API 1, so as to not continue to hold up taking that spec to Recommendation status. Then we can figure out how to fix it in Selectors API 2, where I can spend more time and effort more clearly defining the parsing requirements. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [XHR]
On Sat, Oct 6, 2012 at 11:09 AM, Jakub Łopuszański qbo...@gmail.com wrote: Spec at http://www.w3.org/TR/XMLHttpRequest/ says that: TR drafts are typically out of date; the version you're reading is ten months old. Please use the editor's draft: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html 1. each change of state must fire an event 2. readyState must always be equal to the current state it follows that it is possible for eventhandler to be called more than once with the same value of readyState (What text are you reading? It's helpful to quote exact text.) Can you point to where in the spec this can happen? All of the places readystatechange is fired are explicit; search for the text Fire an event named readystatechange. They always happen after Change the state to (new state), and I don't believe there are any places in the spec where change the state to... names a state that it can already be in. -- Glenn Maynard
Re: [XHR]
2012/10/8 Jungkee Song jungkee.s...@samsung.com From: Jakub Łopuszański [mailto:qbo...@gmail.com] Sent: Monday, October 08, 2012 6:07 PM 2012/10/8 Hallvord R. M. Steen hallv...@opera.com Jakub Łopuszański qbo...@gmail.com skreiv Sat, 06 Oct 2012 18:09:16 +0200 Spec at http://www.w3.org/TR/XMLHttpRequest/ says that: 1. each change of state must fire an event 2. readyState must always be equal to the current state it follows that it is possible for eventhandler to be called more than once with the same value of readyState You mean a race condition of sorts where the implementation fires an event for the change from readyState 2 to readyState 3 but when the event gets fired, readyState turns out to be 4 already? An implementation doing that is not likely to be web-compatible, so if the spec text seems to allow this we should probably fix it. (There was however at least one implementation that supported a sort of server-push mode by supporting chunked HTTP and firing a new readyState 3 event every time a new part of the content came in - I think Firefox used to do this but I'm not sure if they still do.) So I don't know if we really want to outlaw firing several events for the same readyState value.. Yes, I mean this race condition. It actually is quite easy to reproduce -- open http://jsfiddle.net/44b3P/ in Chrome with dev tools opened. I've added debugger statement to force a pause long enough for events to accumulate in the queue, so once you press play button to continue debugging, you'll get 3 alerts one for each event. Although we can reproduce this executing *debugger;* statement in Web Inspector, there might not be many such cases in real web programming context. This particular case may represent the situation in that a client wants to *block* the execution until the data transfer completes. I believe block the execution in asynchronous request is not that client implementation normally intends. (I don't think we have any JavaScript function to do so.) If client intentionally needs to be blocked, it should make a synchronous request although it may encounter browser popup to abort the request: client.open(GET, too-big-to-wait-image.png, false); client.send(); I believe the statement in the spec, The XMLHttpRequest object can be in several states. The readyState attribute must return the current state, ..., sounds reasonable assuming non-blocking scenarios. It also supports the use case that Hallvord mentioned above. Regards, Jungkee Jungkee Song Samsung Electronics I used debugger as it was the easiest way for me to show whats wrong with the example presented in the W3C documentation -- I've simply added one line, and viola! In real word scenario consider sending multiple requests to files cached in broswer's cache -- I believe it may happen that they all return almost immediately, firing events faster than JS can execute eventhandlers for them, if eventhandlers perform some complicated blocking actions. I do not know if I understand correctly what you say, but I hope it was not race conditions are rare, so why change the spec. Yes, they are rare, but w3c spec should be the place where developers can find a rock solid example of code. In this case it would suffice to add some boolean guard, or just check if the current status is actually different than the last observed one. I am not arguing to change the behaviour of XHR, but rather to change the example.
Re: [XHR]
On Mon, Oct 8, 2012 at 4:06 AM, Jakub Łopuszański qbo...@gmail.com wrote: Yes, I mean this race condition. It actually is quite easy to reproduce -- open http://jsfiddle.net/44b3P/ in Chrome with dev tools opened. I've added debugger statement to force a pause long enough for events to accumulate in the queue, so once you press play button to continue debugging, you'll get 3 alerts one for each event. Replacing the delay with an alert() dialog, and pointing the fetch at a 1MB file, I can't reproduce this. Each readystatechange has the correct readyState value at the time: only a single event sees each of OPENED, HEADERS_RECEIVED and DONE, and (in my particular case) about 16 LOADING events. This is what the spec requires. (If it happens when the debugger is involved, that's probably a bug in Chrome, but it's not an issue with the spec.) On Mon, Oct 8, 2012 at 9:42 AM, Jakub Łopuszański qbo...@gmail.com wrote: I used debugger as it was the easiest way for me to show whats wrong with the example presented in the W3C documentation -- I've simply added one line, and viola! In real word scenario consider sending multiple requests to files cached in broswer's cache -- I believe it may happen that they all return almost immediately, firing events faster than JS can execute eventhandlers for them, if eventhandlers perform some complicated blocking actions. This can't happen; there's no such thing as firing events too fast. If an event handlers blocks, no other events can be fired until it returns, because the thread is blocked. -- Glenn Maynard
Re: [XHR]
2012/10/8 Glenn Maynard gl...@zewt.org Replacing the delay with an alert() dialog, and pointing the fetch at a 1MB file, I can't reproduce this. Each readystatechange has the correct readyState value at the time: only a single event sees each of OPENED, HEADERS_RECEIVED and DONE, and (in my particular case) about 16 LOADING events. This is what the spec requires. Inspired by you, I reproduced the bug by simply changing debugger to alert(1), but without changing where the url points to, so it still points to something that returns immediately. I hope that an example with alert(1) will be treaded more seriously than the one with debugger. I believe that the reason you could not reproduce it was that 1MB file takes a while to process.
Re: [XHR]
Jakub Łopuszański qbo...@gmail.com skreiv Mon, 08 Oct 2012 17:32:47 +0200 Replacing the delay with an alert() dialog, and pointing the fetch at a 1MB file, I can't reproduce this. Inspired by you, I reproduced the bug by simply changing debugger to alert(1), but without changing where the url points to, so it still points to something that returns immediately. Is this cross-browser or only in Chrome? -- Hallvord R. M. Steen Core tester, Opera Software
Re: [XHR]
Now I am puzzled: http://jsfiddle.net/44b3P/5/ in Chrome, alerts seems to be blocking, and thus I get msg box with 1, then 3 times a msg box with got it. in IE and Firefox though, I get simultanously a msg box with 1, and the one with got it. I think my current example is more obscure than the one with debugger, as alert seems to be nonblocking in some current browsers. 2012/10/8 Hallvord R. M. Steen hallv...@opera.com Jakub Łopuszański qbo...@gmail.com skreiv Mon, 08 Oct 2012 17:32:47 +0200 Replacing the delay with an alert() dialog, and pointing the fetch at a 1MB file, I can't reproduce this. Inspired by you, I reproduced the bug by simply changing debugger to alert(1), but without changing where the url points to, so it still points to something that returns immediately. Is this cross-browser or only in Chrome? -- Hallvord R. M. Steen Core tester, Opera Software
Re: [XHR]
On Mon, Oct 8, 2012 at 10:32 AM, Jakub Łopuszański qbo...@gmail.com wrote: Inspired by you, I reproduced the bug by simply changing debugger to alert(1), but without changing where the url points to, so it still points to something that returns immediately. I hope that an example with alert(1) will be treaded more seriously than the one with debugger. I can't reproduce this (in Chrome 22). What you're describing is definitely a bug in Chrome, and not allowed by the specification. I recommend filing a bug on Chrome. I believe that the reason you could not reproduce it was that 1MB file takes a while to process. I used 1MB of data specifically to make lots of events get fired, after it didn't happen with an empty file. -- Glenn Maynard
